我們將云應用視為一系列邏輯階段，從DevTest到開發新的云中應用程序，機會性采用新的SaaS服務，隨著核心企業后端應用程序的重新平臺化或轉型，家庭延伸現在進入視野。但是事后看來，過去一年云應用的標題是針對用例的，這些案例使企業能夠轉向新的常態–在工作和消費日益虛擬化的情況下，更改或開發新服務的需求，以及傳統供應鏈面臨壓力的地方。

負責任的AI和可解釋的AI將并駕齊驅

在過去的幾周中，已經看到了有關人類智能作用的預測；職位招聘中對AI的需求; 在短期影響對AI的COVID大流行，這在長期正在鍛煉的更現實的期望對于AI在軟件市場的影響。

如果您是一名數據科學家，確保AI負責任并盡可能減少偏見就足夠具有挑戰性；當您向技術較少的從業人員敞開大門時，這一挑戰就變得更大。我們沒有辦法倒轉時鐘，關閉所有這些公民數據科學家的大門。因此，技術將必須伸出援手，以幫助使AI處于直線和狹窄狀態。可解釋的AI對于使負責任的AI計劃有效是必不可少的。盡管可解釋的AI不會是萬能藥（需要人類來開發如何建立自我文檔模型的標準），但如果沒有可解釋性，則消除偏見和不公平的努力就等于是輕率的努力。

面臨的挑戰是，在過去的一年中，我們在可解釋的AI方面沒有看到太多進展。一年前，我們在2020年的展望中概述了使AI擺脫黑匣子的挑戰，并猜測在過去一年中，可解釋AI的局限性變化相對較小。

展望未來，負責任的AI不會在2021年成為新趨勢。但是，我們確實希望，由于法規的外部壓力，由于法規的外部壓力，將在解釋性方面進行新的努力。科技公司負責。隨之而來的是，隨著AI越來越普及，以及隨著公眾監督需求的不斷增長，負責任AI的目標將繼續成為目標。

數據庫內機器學習成為復選框項

乍一看，從提供商到Microsoft、SAP、Oracle、Informatica，SAS以及其他提供單獨的計算，存儲和微服務的提供商的第二波云原生DBaaS服務似乎正以另一種趨勢出現：所謂的“將數據密集型流程下推”到數據庫中。在來年，我們將看到更多兩者。

推動下推并不是什么新鮮事。從一個角度來看，可以將其追溯到大型機計算的曙光中，程序和數據是互鎖的，但是更現代的表現形式是數據庫存儲過程和觸發器，它們實際上是Sybase的名片（以及為什么華爾街客戶頑固地存在的關鍵）被一個不穩固的平臺所困，我們希望SAP能夠在1990年代注入新的生命。

隨著數據庫內ML功能的涌現，我們已經看到了這一點。幾乎每個云數據倉庫DBaaS都支持某種形式的數據庫內部ML模型的訓練和運行。數據庫內ML已成為一個復選框項，因為（1）ML對于數據非常繁瑣，并且（2）當有替代的方式處理所有數據時，移動所有這些數據既昂貴又效率低下。

在湖邊小屋放松

數據倉庫支持者稱其為云原生架構為他們提供了規模，并且多模型數據支持使他們能夠支持與數據湖相關的各種變化。數據湖的支持者認為，大小問題尤其重要，尤其是當您運行數據密集型AI模型時，新興的開源技術（例如Presto，Trino查詢引擎；表格式如Iceberg）可以使數據湖的性能幾乎與數據一樣好倉庫。

現實情況是，數據倉庫和數據湖各自具有各自不同的優勢。是的，云數據倉庫現在可以冒險進入PB領域，但是對大多數企業而言，障礙是經濟的：在這些規模上，數據湖通常會更經濟。同樣，無論查詢引擎如何優化，數據湖都依賴于文件掃描，而這種效率永遠不會像擁有可以對數據進行索引，壓縮和過濾的表那樣高效。

聯合查詢與來自不同數據庫的聯接表相關聯以進行單個查詢。由于數據移動（僅結果集）可以被最小化，因此將處理推進到數據所處的位置更適合云計算。在云中，這意味著聯合查詢以深入到云對象存儲。來自AWS，Azure，GCP和Snowflake的數據倉庫已經通過聯合查詢或他們自己的專用查詢引擎進入了云存儲，我們期望Oracle和SAP今年將增加這些功能。

展望未來，我們并不希望將數據倉庫重新構想為關系數據湖或數據湖屋，否則一定會使其過時。最終，將由您的開發人員來推動選擇。傳統的SQL數據庫開發人員可能會選擇關系數據湖，而使用Java或Python之類的語言的數據科學家和開發人員可能更喜歡數據湖，或者，如果他們的自然懷疑論得到了解決，則可能會選擇數據湖。在許多組織中，在數據倉庫，數據湖或數據湖屋之間進行選擇不是一個決定性的決定。