將數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)評(píng)估為機(jī)器學(xué)習(xí)數(shù)據(jù)倉(cāng)庫(kù)

無論你是零售商、金融服務(wù)公司還是數(shù)字廣告商，數(shù)據(jù)都是現(xiàn)代企業(yè)的生命線?？缧袠I(yè)，組織正在認(rèn)識(shí)到其數(shù)據(jù)對(duì)于業(yè)務(wù)分析、機(jī)器學(xué)習(xí)和人工智能的重要性。

智能企業(yè)正在投資于從數(shù)據(jù)中提取價(jià)值的新方法：更好地了解客戶需求和行為，定制新產(chǎn)品和服務(wù)，并做出在未來幾年將帶來競(jìng)爭(zhēng)優(yōu)勢(shì)的戰(zhàn)略決策。

幾十年來，企業(yè)數(shù)據(jù)倉(cāng)庫(kù)已用于所有類型的業(yè)務(wù)分析，圍繞 SQL 和關(guān)系數(shù)據(jù)庫(kù)的強(qiáng)大生態(tài)系統(tǒng)。現(xiàn)在，一個(gè)挑戰(zhàn)者出現(xiàn)了。

創(chuàng)建數(shù)據(jù)湖是為了存儲(chǔ)用于訓(xùn)練人工智能模型和預(yù)測(cè)分析的大數(shù)據(jù)。這篇文章涵蓋了每個(gè)存儲(chǔ)庫(kù)的優(yōu)缺點(diǎn)：如何使用它們，以及最終為 ML 項(xiàng)目提供最佳結(jié)果的方法。

這個(gè)難題的關(guān)鍵是處理 AI 和 ML 工作流的數(shù)據(jù)。人工智能項(xiàng)目需要大量數(shù)據(jù)來訓(xùn)練模型和運(yùn)行預(yù)測(cè)分析。技術(shù)團(tuán)隊(duì)必須評(píng)估如何捕獲、處理和存儲(chǔ)數(shù)據(jù)，以使其具有可擴(kuò)展性、經(jīng)濟(jì)性和易用性。

什么是數(shù)據(jù)倉(cāng)庫(kù)？

數(shù)據(jù)倉(cāng)庫(kù)創(chuàng)建于 20 世紀(jì) 80 年代，旨在幫助企業(yè)組織高數(shù)據(jù)量，以便做出更好的業(yè)務(wù)決策。數(shù)據(jù)倉(cāng)庫(kù)與企業(yè)資源規(guī)劃（ ERP ）、客戶關(guān)系管理（ CRM ）軟件、庫(kù)存和銷售點(diǎn)系統(tǒng)等遺留資源一起使用。

主要目標(biāo)是跨業(yè)務(wù)線、產(chǎn)品分析和商業(yè)智能提供運(yùn)營(yíng)報(bào)告。

數(shù)據(jù)倉(cāng)庫(kù)使用 ETL （提取、轉(zhuǎn)換、加載）已有幾十年的歷史，在上傳數(shù)據(jù)之前，傾向于完成轉(zhuǎn)換和清理數(shù)據(jù)。傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)對(duì)數(shù)據(jù)結(jié)構(gòu)和提前規(guī)劃有嚴(yán)格的標(biāo)準(zhǔn)，以滿足模式要求。

數(shù)據(jù)只有在經(jīng)過處理和優(yōu)化后才能存儲(chǔ)在數(shù)據(jù)倉(cāng)庫(kù)中。 ETL 通過首先清理數(shù)據(jù)，然后上傳到關(guān)系數(shù)據(jù)庫(kù)來處理數(shù)據(jù)。好處是數(shù)據(jù)狀態(tài)良好，可以使用。但是，您需要預(yù)先支付處理開銷，如果數(shù)據(jù)從未使用，則會(huì)丟失這些開銷。

數(shù)據(jù)分析員在運(yùn)行查詢之前，必須創(chuàng)建預(yù)先確定的數(shù)據(jù)結(jié)構(gòu)和固定模式。這個(gè)攔截器對(duì)于數(shù)據(jù)科學(xué)家、分析師和其他業(yè)務(wù)部門來說是一個(gè)巨大的痛點(diǎn)，因?yàn)檫\(yùn)行新的查詢需要幾個(gè)月或更長(zhǎng)的時(shí)間。

通常，倉(cāng)庫(kù)中的數(shù)據(jù)是只讀的，因此很難添加、更新或刪除數(shù)據(jù)文件。

優(yōu)勢(shì)：數(shù)據(jù)質(zhì)量

對(duì)于任何系統(tǒng)，都存在權(quán)衡。數(shù)據(jù)倉(cāng)庫(kù)的優(yōu)點(diǎn)是，它們的數(shù)據(jù)在接收時(shí)處于良好狀態(tài)，并且由于數(shù)據(jù)倉(cāng)庫(kù)的規(guī)則，可能會(huì)保持這種狀態(tài) 數(shù)據(jù)清洗 和數(shù)據(jù)治理。

傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)可以作為分類賬，提供干凈、結(jié)構(gòu)化和規(guī)范化的數(shù)據(jù)，作為組織的唯一真實(shí)來源。通過使用關(guān)系數(shù)據(jù)庫(kù)，整個(gè)組織的經(jīng)理和業(yè)務(wù)分析師可以快速準(zhǔn)確地查詢大量企業(yè)數(shù)據(jù)，以指導(dǎo)關(guān)鍵業(yè)務(wù)戰(zhàn)略。

缺點(diǎn)：模式需求

數(shù)據(jù)倉(cāng)庫(kù)更有可能將 ETL 用于操作分析和機(jī)器學(xué)習(xí)工作負(fù)載。

然而，傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)需要一個(gè)固定的模式來構(gòu)建數(shù)據(jù)，這可能需要數(shù)月或數(shù)年的時(shí)間才能在所有團(tuán)隊(duì)和業(yè)務(wù)線經(jīng)理之間達(dá)成一致。當(dāng)一個(gè)模式被實(shí)現(xiàn)時(shí)，它的用戶有了新的查詢，使他們回到原點(diǎn)。

公平地說，數(shù)據(jù)倉(cāng)庫(kù)模式引發(fā)了人們對(duì)數(shù)據(jù)湖的極大興趣。

為什么使用數(shù)據(jù)湖？

在 21 世紀(jì)初， Apache Hadoop 引入了一種在分布式文件系統(tǒng)（ HDF ）中存儲(chǔ)數(shù)據(jù)的新范式，使企業(yè)能夠更輕松地挖掘其數(shù)據(jù)以獲得競(jìng)爭(zhēng)優(yōu)勢(shì)。數(shù)據(jù)湖的想法來自 Hadoop ，能夠吸收存儲(chǔ)在低成本 blob 或?qū)ο蟠鎯?chǔ)中的各種數(shù)據(jù)類型。

在過去的十年中，組織紛紛涌向數(shù)據(jù)湖，以捕獲來自 web 、社交媒體、傳感器、物聯(lián)網(wǎng)、天氣數(shù)據(jù)、購(gòu)買列表等的各種數(shù)據(jù)類型。隨著大數(shù)據(jù)變得越來越大，數(shù)據(jù)湖開始流行使用彈性技術(shù)存儲(chǔ)數(shù) PB 的原始數(shù)據(jù)。

數(shù)據(jù)湖有兩個(gè)主要優(yōu)點(diǎn)：易于接受廣泛的數(shù)據(jù)類型和隨時(shí)訪問該數(shù)據(jù)以進(jìn)行臨時(shí)查詢。

使用 ELT （提取、加載、轉(zhuǎn)換），數(shù)據(jù)湖可以吸收大多數(shù)任何類型的數(shù)據(jù)：結(jié)構(gòu)化、非結(jié)構(gòu)化、半結(jié)構(gòu)化和二進(jìn)制圖像和視頻。

進(jìn)入數(shù)據(jù)湖的數(shù)據(jù)在存儲(chǔ)之前不必進(jìn)行轉(zhuǎn)換。攝取是高效的，沒有按類型清理和規(guī)范化數(shù)據(jù)的開銷。

數(shù)據(jù)湖使存儲(chǔ)所有類型的數(shù)據(jù)（ PDF 、音頻、 JSON 文檔）變得很容易，而不知道將來如何使用這些數(shù)據(jù)。

優(yōu)勢(shì)：即席查詢

數(shù)據(jù)湖的好處是團(tuán)隊(duì)可以訪問不同的數(shù)據(jù)，并根據(jù)需要運(yùn)行任意查詢。需要立即提供數(shù)據(jù)分析是采用數(shù)據(jù)湖的主要驅(qū)動(dòng)力。

缺點(diǎn)：隨著時(shí)間的推移，數(shù)據(jù)質(zhì)量會(huì)下降

原始數(shù)據(jù)在數(shù)據(jù)湖中很快就會(huì)壞掉。很少有工具可以馴服原始數(shù)據(jù)，因此很難進(jìn)行合并、重復(fù)數(shù)據(jù)消除和數(shù)據(jù)連續(xù)性。

數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖有什么共同點(diǎn)？

數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖都是大型數(shù)據(jù)存儲(chǔ)庫(kù)，具有共同的特點(diǎn)和缺點(diǎn)，尤其是在成本和復(fù)雜性方面。

比例：兩者都可以使用批處理和流式處理來保留大量數(shù)據(jù)。

高成本：兩者都非常昂貴，每年維護(hù)成本超過 100 萬美元。

復(fù)雜性：數(shù)據(jù)中心正在管理數(shù)十個(gè)獨(dú)特的數(shù)據(jù)源，數(shù)據(jù)量以每年 50% 或更高的速度快速增長(zhǎng)。存儲(chǔ)基礎(chǔ)架構(gòu)占用了更多的 IT 工時(shí)，提高了存儲(chǔ)成本，降低了整體效率。

數(shù)據(jù)處理：兩者都可以使用 ETL 和 ELT 處理。

共享用例：隨著數(shù)據(jù)科學(xué)家優(yōu)先考慮 ML 技術(shù)以從他們的數(shù)據(jù)中獲得新的見解，許多組織現(xiàn)在正在充分利用這兩個(gè)領(lǐng)域：支持人工智能的數(shù)據(jù)分析和廣泛的不同數(shù)據(jù)類型。

數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖之間有什么區(qū)別？

比較數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖有點(diǎn)像比較蘋果和桔子。他們提供不同的東西。

數(shù)據(jù)倉(cāng)庫(kù)組織、清理和存儲(chǔ)用于分析的數(shù)據(jù)。

數(shù)據(jù)湖存儲(chǔ)許多數(shù)據(jù)類型，并根據(jù)需要進(jìn)行轉(zhuǎn)換。

隨著團(tuán)隊(duì)越來越專注于人工智能項(xiàng)目，功能性、可管理性和數(shù)據(jù)質(zhì)量問題上的差距逐漸顯現(xiàn)，導(dǎo)致這兩種方法不斷發(fā)展和改進(jìn)。

部署

數(shù)據(jù)倉(cāng)庫(kù)更有可能位于內(nèi)部或混合云中。數(shù)據(jù)湖更有可能是基于云的，以利用更實(shí)惠的存儲(chǔ)選項(xiàng)。

數(shù)據(jù)處理

數(shù)據(jù)倉(cāng)庫(kù)更有可能將 ETL 用于操作分析和機(jī)器學(xué)習(xí)工作負(fù)載。數(shù)據(jù)湖使用原始數(shù)據(jù)的 ELT 管道接收數(shù)據(jù)，以備將來需要。數(shù)據(jù)湖也不需要模式，因此團(tuán)隊(duì)可以毫不延遲地提出臨時(shí)查詢。

工具

就功能性編程模型和成熟的、企業(yè)級(jí)軟件和工具而言，數(shù)據(jù)湖缺乏數(shù)據(jù)倉(cāng)庫(kù)的穩(wěn)健性。數(shù)據(jù)湖有很多痛點(diǎn)，包括不支持事務(wù)、原子性或數(shù)據(jù)治理。

數(shù)據(jù)質(zhì)量

這總是一個(gè)問題。對(duì)于數(shù)據(jù)湖來說，這是一個(gè)更大的問題。希望對(duì)數(shù)據(jù)湖中的數(shù)據(jù)進(jìn)行大量監(jiān)控和維護(hù)。如果不能有效地管理原始數(shù)據(jù)，最終可能會(huì)陷入數(shù)據(jù)沼澤，性能低下，存儲(chǔ)成本失控。

Gartner 估計(jì)，大約 85% 的數(shù)據(jù)湖由于低質(zhì)量的數(shù)據(jù)而失敗。正如諺語所說：數(shù)據(jù)管道的好壞取決于流經(jīng)它們的數(shù)據(jù)。

購(gòu)買與建造相比

像 Teradata 、 Oracle 和 IBM 這樣的公司可以以數(shù)百萬美元的價(jià)格向您出售一個(gè)數(shù)據(jù)倉(cāng)庫(kù)。存儲(chǔ)是最昂貴的組件之一，因?yàn)橐话愎镜臄?shù)據(jù)量每年增長(zhǎng)超過 50% 。

為了獲得數(shù)據(jù)湖，大多數(shù)公司使用開源的 Apache Spark 、 Kafka 或 Zookeeper 在免費(fèi)的 PaaS 上構(gòu)建自己的數(shù)據(jù)湖。然而，這并不意味著構(gòu)建和維護(hù)數(shù)據(jù)湖的成本更低。

據(jù)估計(jì)，雇傭人員部署帶有云存儲(chǔ)的生產(chǎn)數(shù)據(jù)湖每年可能會(huì)花費(fèi)超過 100 萬美元。如果你能獲得專業(yè)知識(shí)，建立一個(gè)數(shù)據(jù)湖可能需要 6 個(gè)月到一年的時(shí)間。

什么最適合 ML 工作負(fù)載？

簡(jiǎn)單的答案是兩者都有。大多數(shù)公司將在人工智能項(xiàng)目中同時(shí)使用數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖。原因如下。

數(shù)據(jù)湖之所以受歡迎，是因?yàn)樗鼈兛梢詳U(kuò)展到 PB 或 EB 級(jí)的大數(shù)據(jù)，而不會(huì)破壞數(shù)據(jù)庫(kù)。然而，由于其編程模型中的約束，數(shù)據(jù)湖并沒有為 ML 工作負(fù)載提供端到端的解決方案。

許多組織采用了 Hadoop 范式，卻發(fā)現(xiàn)幾乎不可能讓高技能人才使用 MapReduce 從數(shù)據(jù)湖中提取數(shù)據(jù)。 Apache Spark 的引入和開發(fā)使數(shù)據(jù)湖得以維持，從而使數(shù)據(jù)訪問變得更容易。

盡管如此， Hadoop 模型并沒有實(shí)現(xiàn)其對(duì) ML 的承諾。 Data lakes 持續(xù)的痛點(diǎn)包括缺乏原子性、性能差、缺乏語義更新，以及不斷發(fā)展的 SQL Spark 引擎。

將其與數(shù)據(jù)倉(cāng)庫(kù)進(jìn)行比較，數(shù)據(jù)倉(cāng)庫(kù)與整個(gè) SQL 生態(tài)系統(tǒng)兼容。任何為 SQL 后端編寫的軟件都可以訪問企業(yè)軟件。這些方法從所見即所得前端和拖放界面到自動(dòng)生成的儀表板，再到進(jìn)行 Kube 分析和超 Kubes 的全自動(dòng)方法等等。

過去 30 年的所有商業(yè)智能和數(shù)據(jù)分析工作都是在 SQL 數(shù)據(jù)庫(kù)中繼承的。這些都不適用于 Hadoop 或數(shù)據(jù)湖。

越來越多的數(shù)據(jù)倉(cāng)庫(kù)支持?jǐn)?shù)據(jù)湖常用的 ELT 。數(shù)據(jù)湖的一個(gè)主要用例是將數(shù)據(jù)攝取到數(shù)據(jù)倉(cāng)庫(kù)中，以便可以為 ML 項(xiàng)目提取和構(gòu)造數(shù)據(jù)。 ELT 使數(shù)據(jù)科學(xué)家能夠定義一種結(jié)構(gòu)數(shù)據(jù)和查詢數(shù)據(jù)的方法，同時(shí)將原始數(shù)據(jù)作為真理的來源。

數(shù)據(jù)湖之家的前景

對(duì)于尋求更強(qiáng)健的數(shù)據(jù)解決方案以滿足其大數(shù)據(jù)需求的數(shù)據(jù)工程師來說，一個(gè) 數(shù)據(jù)湖屋 （數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)的組合）有望解決數(shù)據(jù)湖的缺點(diǎn)。

在一個(gè)名為 三角洲湖 。

混合云選項(xiàng)

如果你剛剛開始人工智能數(shù)據(jù)架構(gòu)，像 Amazon 和谷歌這樣的公司正在提供基于云的數(shù)據(jù)倉(cāng)庫(kù) （ Amazon 紅移 ， Google BigQuery ） 幫助降低存儲(chǔ)和部署成本。

核心數(shù)據(jù)庫(kù) 是一種開源數(shù)據(jù)庫(kù)服務(wù)，作為 Apache 許可證下的一項(xiàng)服務(wù)，其功能相當(dāng)于數(shù)據(jù)湖。

結(jié)論

數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖都是馴服大數(shù)據(jù)和推進(jìn)高級(jí) ML 分析的有用方法。數(shù)據(jù)湖是最近在商業(yè)云中存儲(chǔ)大量數(shù)據(jù)的一種方法，例如 Amazon S3 和 Azure Blob 。

數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖的定義正在演變。每種方法都在為新的用例測(cè)試新的數(shù)據(jù)過程和模型。展望未來，優(yōu)化性能的技術(shù)對(duì)于管理成本和監(jiān)控大型存儲(chǔ)庫(kù)中的數(shù)據(jù)衛(wèi)生至關(guān)重要。

數(shù)據(jù)湖為數(shù)據(jù)分析提供了更靈活的解決方案，可以以較低的價(jià)格處理和存儲(chǔ)數(shù)據(jù)。然而， Hadoop 數(shù)據(jù)湖范式目前并沒有為大規(guī)模機(jī)器學(xué)習(xí)提供全功能解決方案。許多組織正在制定新策略并嘗試新工具，以便在不久的將來為數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖提供更好的功能。

關(guān)于作者

JudyMcConnell 為 NVIDIA 撰寫了關(guān)于企業(yè)數(shù)據(jù)中心和網(wǎng)絡(luò)安全的文章。在過去的 15 年里，她在硅谷的多家公司工作，之前她是一名技術(shù)記者。

審核編輯：郭婷