如果說(shuō)有一個(gè)明顯的預(yù)測(cè)在這原本不可預(yù)測(cè)的一年里得到了證實(shí)，那就是云計(jì)算應(yīng)用的加速。只要看看每一個(gè)主要的云持續(xù)著非常健康的兩位數(shù)增長(zhǎng)率。對(duì)于企業(yè)來(lái)說(shuō)，這是為了適應(yīng)虛擬環(huán)境和突然被封鎖的世界中受限的供應(yīng)鏈。

一年前(COVID之前)，我們將云應(yīng)用視為一系列邏輯階段，從DevTest到開發(fā)新的云中應(yīng)用程序，機(jī)會(huì)性采用新的SaaS服務(wù)，隨著核心企業(yè)后端應(yīng)用程序的重新平臺(tái)化或轉(zhuǎn)型，家庭延伸現(xiàn)在進(jìn)入視野。但是事后看來(lái)，過(guò)去一年云應(yīng)用的標(biāo)題是針對(duì)用例的，這些案例使企業(yè)能夠轉(zhuǎn)向新的常態(tài)–在工作和消費(fèi)日益虛擬化的情況下，更改或開發(fā)新服務(wù)的需求，以及傳統(tǒng)供應(yīng)鏈面臨壓力的地方。

在過(guò)去的一年里，數(shù)據(jù)、分析和云服務(wù)的主要主題是擴(kuò)展。我們看到新的數(shù)據(jù)庫(kù)云服務(wù)的推出相對(duì)較少(Amazon Timestream和Oracle MySQL服務(wù)是今年的主要推出內(nèi)容)，而是現(xiàn)有服務(wù)的擴(kuò)展，包括新的緩存、查詢聯(lián)合，以及作為云本機(jī)托管服務(wù)的第二代數(shù)據(jù)庫(kù)的推出(或在某些情況下重新推出)。

負(fù)責(zé)任的AI和可解釋的AI將并駕齊驅(qū)

我們不會(huì)在這里耙海濱。在過(guò)去的幾周中，這些頁(yè)面已經(jīng)看到了有關(guān)人類智能作用的預(yù)測(cè);職位招聘中對(duì)AI的需求; 在短期影響對(duì)AI的COVID大流行，這在長(zhǎng)期正在鍛煉的更現(xiàn)實(shí)的期望對(duì)于AI在軟件市場(chǎng)的影響。

如果您是一名數(shù)據(jù)科學(xué)家，確保AI負(fù)責(zé)任并盡可能減少偏見就足夠具有挑戰(zhàn)性;當(dāng)您向技術(shù)較少的從業(yè)人員敞開大門時(shí)，這一挑戰(zhàn)就變得更大。我們沒(méi)有辦法倒轉(zhuǎn)時(shí)鐘，關(guān)閉所有這些公民數(shù)據(jù)科學(xué)家的大門。因此，技術(shù)將必須伸出援手，以幫助使AI處于直線和狹窄狀態(tài)。可解釋的AI對(duì)于使負(fù)責(zé)任的AI計(jì)劃有效是必不可少的。盡管可解釋的AI不會(huì)是萬(wàn)能藥(需要人類來(lái)開發(fā)如何建立自我文檔模型的標(biāo)準(zhǔn))，但如果沒(méi)有可解釋性，則消除偏見和不公平的努力就等于是輕率的努力。

面臨的挑戰(zhàn)是，在過(guò)去的一年中，我們?cè)诳山忉尩腁I方面沒(méi)有看到太多進(jìn)展。一年前，我們?cè)?020年的展望中概述了使AI擺脫黑匣子的挑戰(zhàn)，并猜測(cè)在過(guò)去一年中，可解釋AI的局限性變化相對(duì)較小。例如，在隨后的12個(gè)月中，Google Cloud的披露頁(yè)面發(fā)生了微小的變化。

展望未來(lái)，負(fù)責(zé)任的AI不會(huì)在2021年成為新趨勢(shì)。但是，我們確實(shí)希望，由于法規(guī)的外部壓力，由于法規(guī)的外部壓力，將在解釋性方面進(jìn)行新的努力?？萍脊矩?fù)責(zé)。隨之而來(lái)的是，隨著AI越來(lái)越普及，以及隨著公眾監(jiān)督需求的不斷增長(zhǎng)，負(fù)責(zé)任AI的目標(biāo)將繼續(xù)成為目標(biāo)。

數(shù)據(jù)庫(kù)內(nèi)機(jī)器學(xué)習(xí)成為復(fù)選框項(xiàng)

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

推動(dòng)下推并不是什么新鮮事。從一個(gè)角度來(lái)看，可以將其追溯到大型機(jī)計(jì)算的曙光中，程序和數(shù)據(jù)是互鎖的，但是更現(xiàn)代的表現(xiàn)形式是數(shù)據(jù)庫(kù)存儲(chǔ)過(guò)程和觸發(fā)器，它們實(shí)際上是Sybase的名片(以及為什么華爾街客戶頑固地存在的關(guān)鍵)被一個(gè)不穩(wěn)固的平臺(tái)所困，我們希望SAP能夠在1990年代注入新的生命。

隨著數(shù)據(jù)庫(kù)內(nèi)ML功能的涌現(xiàn)，我們已經(jīng)看到了這一點(diǎn)。幾乎每個(gè)云數(shù)據(jù)倉(cāng)庫(kù)DBaaS都支持某種形式的數(shù)據(jù)庫(kù)內(nèi)部ML模型的訓(xùn)練和運(yùn)行。數(shù)據(jù)庫(kù)內(nèi)ML已成為一個(gè)復(fù)選框項(xiàng)，因?yàn)?1)ML對(duì)于數(shù)據(jù)非常繁瑣，并且(2)當(dāng)有替代的方式處理所有數(shù)據(jù)時(shí)，移動(dòng)所有這些數(shù)據(jù)既昂貴又效率低下。而且無(wú)論如何，在某些情況下，我們可能要討論P(yáng)B級(jí)的數(shù)據(jù)。誰(shuí)愿意為轉(zhuǎn)移所有費(fèi)用付費(fèi)，然后等待所有數(shù)據(jù)轉(zhuǎn)移?

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

在湖邊小屋放松

數(shù)據(jù)倉(cāng)庫(kù)與數(shù)據(jù)湖之間的爭(zhēng)奪是安德魯·布魯斯特(Andrew Brust)的綜述中爭(zhēng)議最大的趨勢(shì)。本質(zhì)上，話語(yǔ)可以歸結(jié)為這一點(diǎn)。數(shù)據(jù)倉(cāng)庫(kù)支持者稱其為云原生架構(gòu)為他們提供了規(guī)模，并且多模型數(shù)據(jù)支持使他們能夠支持與數(shù)據(jù)湖相關(guān)的各種變化。數(shù)據(jù)湖的支持者認(rèn)為，大小問(wèn)題尤其重要，尤其是當(dāng)您運(yùn)行數(shù)據(jù)密集型AI模型時(shí)，新興的開源技術(shù)(例如Presto，Trino查詢引擎;表格式如Iceberg)可以使數(shù)據(jù)湖的性能幾乎與數(shù)據(jù)一樣好倉(cāng)庫(kù)。

現(xiàn)實(shí)情況是，數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖各自具有各自不同的優(yōu)勢(shì)。是的，云數(shù)據(jù)倉(cāng)庫(kù)現(xiàn)在可以冒險(xiǎn)進(jìn)入PB領(lǐng)域，但是對(duì)大多數(shù)企業(yè)而言，障礙是經(jīng)濟(jì)的：在這些規(guī)模上，數(shù)據(jù)湖通常會(huì)更經(jīng)濟(jì)。同樣，無(wú)論查詢引擎如何優(yōu)化，數(shù)據(jù)湖都依賴于文件掃描，而這種效率永遠(yuǎn)不會(huì)像擁有可以對(duì)數(shù)據(jù)進(jìn)行索引，壓縮和過(guò)濾的表那樣高效。

聯(lián)合查詢與來(lái)自不同數(shù)據(jù)庫(kù)的聯(lián)接表相關(guān)聯(lián)以進(jìn)行單個(gè)查詢。由于數(shù)據(jù)移動(dòng)(僅結(jié)果集)可以被最小化，因此將處理推進(jìn)到數(shù)據(jù)所處的位置更適合云計(jì)算。在云中，這意味著聯(lián)合查詢以深入到云對(duì)象存儲(chǔ)。來(lái)自AWS，Azure，GCP和Snowflake的數(shù)據(jù)倉(cāng)庫(kù)已經(jīng)通過(guò)聯(lián)合查詢或他們自己的專用查詢引擎進(jìn)入了云存儲(chǔ)，我們期望Oracle和SAP今年將增加這些功能。

Data Lakehouse是一個(gè)新手，它可以在聯(lián)盟查詢離開的地方進(jìn)行選擇。它是一年前由Databricks引入的，它是指由數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖混合而成的系統(tǒng)。這個(gè)詞已由Snowflake借用，最近又被Informatica接受(我們將在本周晚些時(shí)候?qū)Υ税l(fā)表更多看法)。對(duì)于僅僅在一年前推出的一個(gè)術(shù)語(yǔ)，此時(shí)，三分之二的人群非常多，這意味著我們可能會(huì)在來(lái)年看到更多這個(gè)術(shù)語(yǔ)。Data Lake房屋不一定使用關(guān)系數(shù)據(jù)倉(cāng)庫(kù)作為入口點(diǎn)，而是依靠“開放”數(shù)據(jù)格式，最有可能是Parquet或CSV。

展望未來(lái)，我們并不希望將數(shù)據(jù)倉(cāng)庫(kù)重新構(gòu)想為關(guān)系數(shù)據(jù)湖或數(shù)據(jù)湖屋，否則一定會(huì)使其過(guò)時(shí)。最終，將由您的開發(fā)人員來(lái)推動(dòng)選擇。傳統(tǒng)的SQL數(shù)據(jù)庫(kù)開發(fā)人員可能會(huì)選擇關(guān)系數(shù)據(jù)湖，而使用Java或Python之類的語(yǔ)言的數(shù)據(jù)科學(xué)家和開發(fā)人員可能更喜歡數(shù)據(jù)湖，或者，如果他們的自然懷疑論得到了解決，則可能會(huì)選擇數(shù)據(jù)湖。在許多組織中，在數(shù)據(jù)倉(cāng)庫(kù)，數(shù)據(jù)湖或數(shù)據(jù)湖屋之間進(jìn)行選擇不是一個(gè)決定性的決定。