官方微信：日成最新資訊
移動官網(wǎng)
官方商城
如果說有一個明顯的預測在這原本不可預測的一年里得到了證實，那就是云計算應(yīng)用的加速。只要看看每一個主要的云持續(xù)著非常健康的兩位數(shù)增長率。對于企業(yè)來說，這是為了適應(yīng)虛擬環(huán)境和突然被封鎖的世界中受限的供應(yīng)鏈。
一年前(COVID之前)，我們將云應(yīng)用視為一系列邏輯階段，從DevTest到開發(fā)新的云中應(yīng)用程序，機會性采用新的SaaS服務(wù)，隨著核心企業(yè)后端應(yīng)用程序的重新平臺化或轉(zhuǎn)型，家庭延伸現(xiàn)在進入視野。但是事后看來，過去一年云應(yīng)用的標題是針對用例的，這些案例使企業(yè)能夠轉(zhuǎn)向新的常態(tài)–在工作和消費日益虛擬化的情況下，更改或開發(fā)新服務(wù)的需求，以及傳統(tǒng)供應(yīng)鏈面臨壓力的地方。
在過去的一年里，數(shù)據(jù)、分析和云服務(wù)的主要主題是擴展。我們看到新的數(shù)據(jù)庫云服務(wù)的推出相對較少(Amazon Timestream和Oracle MySQL服務(wù)是今年的主要推出內(nèi)容)，而是現(xiàn)有服務(wù)的擴展，包括新的緩存、查詢聯(lián)合，以及作為云本機托管服務(wù)的第二代數(shù)據(jù)庫的推出(或在某些情況下重新推出)。
負責任的AI和可解釋的AI將并駕齊驅(qū)
我們不會在這里耙海濱。在過去的幾周中，這些頁面已經(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以及其他提供單獨的計算，存儲和微服務(wù)的提供商的第二波云原生DBaaS服務(wù)似乎正以另一種趨勢出現(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ù)湖屋之間進行選擇不是一個決定性的決定。
