如果說(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)就變得更大。我們沒有辦法倒轉(zhuǎn)時(shí)鐘,關(guān)閉所有這些公民數(shù)據(jù)科學(xué)家的大門。因此,技術(shù)將必須伸出援手,以幫助使AI處于直線和狹窄狀態(tài)??山忉尩腁I對(duì)于使負(fù)責(zé)任的AI計(jì)劃有效是必不可少的。盡管可解釋的AI不會(huì)是萬(wàn)能藥(需要人類來(lái)開發(fā)如何建立自我文檔模型的標(biāo)準(zhǔn)),但如果沒有可解釋性,則消除偏見和不公平的努力就等于是輕率的努力。
面臨的挑戰(zhàn)是,在過(guò)去的一年中,我們?cè)诳山忉尩腁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è)決定性的決定。