如果說有一個明顯的預測在這原本不可預測的一年里得到了證實，那就是云計算應用的加速。只要看看每一個主要的云持續(xù)著非常健康的兩位數(shù)增長率。對于企業(yè)來說，這是為了適應虛擬環(huán)境和突然被封鎖的世界中受限的供應鏈。
一年前（COVID之前），我們將云應用視為一系列邏輯階段，從DevTest到開發(fā)新的云中應用程序，機會性采用新的SaaS服務，隨著核心企業(yè)后端應用程序的重新平臺化或轉(zhuǎn)型，家庭延伸現(xiàn)在進入視野。但是事后看來，過去一年云應用的標題是針對用例的，這些案例使企業(yè)能夠轉(zhuǎn)向新的常態(tài)–在工作和消費日益虛擬化的情況下，更改或開發(fā)新服務的需求，以及傳統(tǒng)供應鏈面臨壓力的地方。
在過去的一年里，數(shù)據(jù)、分析和云服務的主要主題是擴展。我們看到新的數(shù)據(jù)庫云服務的推出相對較少（Amazon Timestream和Oracle MySQL服務是今年的主要推出內(nèi)容），而是現(xiàn)有服務的擴展，包括新的緩存、查詢聯(lián)合，以及作為云本機托管服務的第二代數(shù)據(jù)庫的推出（或在某些情況下重新推出）。
我們不會在這里耙海濱。在過去的幾周中，這些頁面已經(jīng)看到了有關(guān)人類智能作用的預測；職位招聘中對AI的需求; 在短期影響對AI的COVID大流行，這在長期正在鍛煉的更現(xiàn)實的期望對于AI在軟件市場的影響。
如果您是一名數(shù)據(jù)科學家，確保AI負責任并盡可能減少偏見就足夠具有挑戰(zhàn)性；當您向技術(shù)較少的從業(yè)人員敞開大門時，這一挑戰(zhàn)就變得更大。我們沒有辦法倒轉(zhuǎn)時鐘，關(guān)閉所有這些公民數(shù)據(jù)科學家的大門。因此，技術(shù)將必須伸出援手，以幫助使AI處于直線和狹窄狀態(tài)?？山忉尩腁I對于使負責任的AI計劃有效是必不可少的。盡管可解釋的AI不會是萬能藥（需要人類來開發(fā)如何建立自我文檔模型的標準），但如果沒有可解釋性，則消除偏見和不公平的努力就等于是輕率的努力。
面臨的挑戰(zhàn)是，在過去的一年中，我們在可解釋的AI方面沒有看到太多進展。一年前，我們在2020年的展望中概述了使AI擺脫黑匣子的挑戰(zhàn)，并猜測在過去一年中，可解釋AI的局限性變化相對較小。例如，在隨后的12個月中，Google Cloud的披露頁面發(fā)生了微小的變化。
展望未來，負責任的AI不會在2021年成為新趨勢。但是，我們確實希望，由于法規(guī)的外部壓力，由于法規(guī)的外部壓力，將在解釋性方面進行新的努力?？萍脊矩撠?。隨之而來的是，隨著AI越來越普及，以及隨著公眾監(jiān)督需求的不斷增長，負責任AI的目標將繼續(xù)成為目標。
數(shù)據(jù)庫內(nèi)機器學習成為復選框項
乍一看，從提供商到Microsoft、SAP、Oracle、Informatica，SAS以及其他提供單獨的計算，存儲和微服務的提供商的第二波云原生DBaaS服務似乎正以另一種趨勢出現(xiàn)：所謂的“將數(shù)據(jù)密集型流程下推”到數(shù)據(jù)庫中。在來年，我們將看到更多兩者。
推動下推并不是什么新鮮事。從一個角度來看，可以將其追溯到大型機計算的曙光中，程序和數(shù)據(jù)是互鎖的，但是更現(xiàn)代的表現(xiàn)形式是數(shù)據(jù)庫存儲過程和觸發(fā)器，它們實際上是Sybase的名片（以及為什么華爾街客戶頑固地存在的關(guān)鍵）被一個不穩(wěn)固的平臺所困，我們希望SAP能夠在1990年代注入新的生命。
隨著數(shù)據(jù)庫內(nèi)ML功能的涌現(xiàn)，我們已經(jīng)看到了這一點。幾乎每個云數(shù)據(jù)倉庫DBaaS都支持某種形式的數(shù)據(jù)庫內(nèi)部ML模型的訓練和運行。數(shù)據(jù)庫內(nèi)ML已成為一個復選框項，因為（1）ML對于數(shù)據(jù)非常繁瑣，并且（2）當有替代的方式處理所有數(shù)據(jù)時，移動所有這些數(shù)據(jù)既昂貴又效率低下。而且無論如何，在某些情況下，我們可能要討論PB級的數(shù)據(jù)。誰愿意為轉(zhuǎn)移所有費用付費，然后等待所有數(shù)據(jù)轉(zhuǎn)移？
這里有一些例子。AWS最近宣布了Redshift及其圖形數(shù)據(jù)庫Neptune中的ML功能預覽。Microsoft支持在由Azure Synapse Analytics管理的SQL和Spark池中處理ML模型。Google BigQuery支持在數(shù)據(jù)庫中運行大約十種不同類型的ML算法。Oracle長期以來一直支持數(shù)據(jù)庫內(nèi)R和Python處理。同時，Snowflake支持使用ML工具（例如Dataiku，Alteryx和Zepl）中的SQL下推功能，以及與AutoML工具（例如DataRobot，Dataiku，H20.ai和Amazon SageMaker）的集成來支持功能工程。
在湖邊小屋放松
數(shù)據(jù)倉庫與數(shù)據(jù)湖之間的爭奪是安德魯·布魯斯特（Andrew Brust）的綜述中爭議最大的趨勢。本質(zhì)上，話語可以歸結(jié)為這一點。數(shù)據(jù)倉庫支持者稱其為云原生架構(gòu)為他們提供了規(guī)模，并且多模型數(shù)據(jù)支持使他們能夠支持與數(shù)據(jù)湖相關(guān)的各種變化。數(shù)據(jù)湖的支持者認為，大小問題尤其重要，尤其是當您運行數(shù)據(jù)密集型AI模型時，新興的開源技術(shù)（例如Presto，Trino查詢引擎；表格式如Iceberg）可以使數(shù)據(jù)湖的性能幾乎與數(shù)據(jù)一樣好倉庫。
現(xiàn)實情況是，數(shù)據(jù)倉庫和數(shù)據(jù)湖各自具有各自不同的優(yōu)勢。是的，云數(shù)據(jù)倉庫現(xiàn)在可以冒險進入PB領(lǐng)域，但是對大多數(shù)企業(yè)而言，障礙是經(jīng)濟的：在這些規(guī)模上，數(shù)據(jù)湖通常會更經(jīng)濟。同樣，無論查詢引擎如何優(yōu)化，數(shù)據(jù)湖都依賴于文件掃描，而這種效率永遠不會像擁有可以對數(shù)據(jù)進行索引，壓縮和過濾的表那樣高效。
聯(lián)合查詢與來自不同數(shù)據(jù)庫的聯(lián)接表相關(guān)聯(lián)以進行單個查詢。由于數(shù)據(jù)移動（僅結(jié)果集）可以被最小化，因此將處理推進到數(shù)據(jù)所處的位置更適合云計算。在云中，這意味著聯(lián)合查詢以深入到云對象存儲。來自AWS，Azure，GCP和Snowflake的數(shù)據(jù)倉庫已經(jīng)通過聯(lián)合查詢或他們自己的專用查詢引擎進入了云存儲，我們期望Oracle和SAP今年將增加這些功能。
Data Lakehouse是一個新手，它可以在聯(lián)盟查詢離開的地方進行選擇。它是一年前由Databricks引入的，它是指由數(shù)據(jù)倉庫和數(shù)據(jù)湖混合而成的系統(tǒng)。這個詞已由Snowflake借用，最近又被Informatica接受（我們將在本周晚些時候?qū)Υ税l(fā)表更多看法）。對于僅僅在一年前推出的一個術(shù)語，此時，三分之二的人群非常多，這意味著我們可能會在來年看到更多這個術(shù)語。Data Lake房屋不一定使用關(guān)系數(shù)據(jù)倉庫作為入口點，而是依靠“開放”數(shù)據(jù)格式，最有可能是Parquet或CSV。
展望未來，我們并不希望將數(shù)據(jù)倉庫重新構(gòu)想為關(guān)系數(shù)據(jù)湖或數(shù)據(jù)湖屋，否則一定會使其過時。最終，將由您的開發(fā)人員來推動選擇。傳統(tǒng)的SQL數(shù)據(jù)庫開發(fā)人員可能會選擇關(guān)系數(shù)據(jù)湖，而使用Java或Python之類的語言的數(shù)據(jù)科學家和開發(fā)人員可能更喜歡數(shù)據(jù)湖，或者，如果他們的自然懷疑論得到了解決，則可能會選擇數(shù)據(jù)湖。在許多組織中，在數(shù)據(jù)倉庫，數(shù)據(jù)湖或數(shù)據(jù)湖屋之間進行選擇不是一個決定性的決定。
（免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
