如果說有一個明顯的預測在這原本不可預測的一年里得到了證實，那就是云計算應用的加速。只要看看每一個主要的云持續著非常健康的兩位數增長率。對于企業來說，這是為了適應虛擬環境和突然被封鎖的世界中受限的供應鏈。

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

在過去的一年里，數據、分析和云服務的主要主題是擴展。我們看到新的數據庫云服務的推出相對較少（Amazon Timestream和Oracle MySQL服務是今年的主要推出內容），而是現有服務的擴展，包括新的緩存、查詢聯合，以及作為云本機托管服務的第二代數據庫的推出（或在某些情況下重新推出）。

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

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

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

面臨的挑戰是，在過去的一年中，我們在可解釋的AI方面沒有看到太多進展。一年前，我們在2020年的展望中概述了使AI擺脫黑匣子的挑戰，并猜測在過去一年中，可解釋AI的局限性變化相對較小。例如，在隨后的12個月中，Google Cloud的披露頁面發生了微小的變化。

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

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

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

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

隨著數據庫內ML功能的涌現，我們已經看到了這一點。幾乎每個云數據倉庫DBaaS都支持某種形式的數據庫內部ML模型的訓練和運行。數據庫內ML已成為一個復選框項，因為（1）ML對于數據非常繁瑣，并且（2）當有替代的方式處理所有數據時，移動所有這些數據既昂貴又效率低下。而且無論如何，在某些情況下，我們可能要討論PB級的數據。誰愿意為轉移所有費用付費，然后等待所有數據轉移？

這里有一些例子。AWS最近宣布了Redshift及其圖形數據庫Neptune中的ML功能預覽。Microsoft支持在由Azure Synapse Analytics管理的SQL和Spark池中處理ML模型。Google BigQuery支持在數據庫中運行大約十種不同類型的ML算法。Oracle長期以來一直支持數據庫內R和Python處理。同時，Snowflake支持使用ML工具（例如Dataiku，Alteryx和Zepl）中的SQL下推功能，以及與AutoML工具（例如DataRobot，Dataiku，H20.ai和Amazon SageMaker）的集成來支持功能工程。

在湖邊小屋放松

數據倉庫與數據湖之間的爭奪是安德魯·布魯斯特（Andrew Brust）的綜述中爭議最大的趨勢。本質上，話語可以歸結為這一點。數據倉庫支持者稱其為云原生架構為他們提供了規模，并且多模型數據支持使他們能夠支持與數據湖相關的各種變化。數據湖的支持者認為，大小問題尤其重要，尤其是當您運行數據密集型AI模型時，新興的開源技術（例如Presto，Trino查詢引擎；表格式如Iceberg）可以使數據湖的性能幾乎與數據一樣好倉庫。

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

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

Data Lakehouse是一個新手，它可以在聯盟查詢離開的地方進行選擇。它是一年前由Databricks引入的，它是指由數據倉庫和數據湖混合而成的系統。這個詞已由Snowflake借用，最近又被Informatica接受（我們將在本周晚些時候對此發表更多看法）。對于僅僅在一年前推出的一個術語，此時，三分之二的人群非常多，這意味著我們可能會在來年看到更多這個術語。Data Lake房屋不一定使用關系數據倉庫作為入口點，而是依靠“開放”數據格式，最有可能是Parquet或CSV。

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