當今社會，隨著數(shù)據(jù)數(shù)量、種類和速度不斷變化，相信大家也意識到數(shù)據(jù)庫管理使用的這個問題，那就是并沒有一種能夠滿足我們所有數(shù)據(jù)需要的數(shù)據(jù)庫。因此很多企業(yè)已經(jīng)轉(zhuǎn)向特定或者適合的數(shù)據(jù)存儲技術(shù)。但是數(shù)據(jù)分散儲存在不同的空間會給數(shù)據(jù)分析帶來一定的困擾，真正能夠解決這個問題的應(yīng)該就是數(shù)據(jù)湖和數(shù)據(jù)倉庫的組合，也可以經(jīng)得起未來的考驗。下面我們就來介紹一下組織為什么要創(chuàng)建數(shù)據(jù)湖？為什么要選擇數(shù)據(jù)湖的具體原因。

從歷史上看，唯一可行的解決方案是構(gòu)建數(shù)據(jù)倉庫，這可以從所有不同的數(shù)據(jù)源攝取數(shù)據(jù)，在清理之后并將其合并在一起，最后以定義良好的結(jié)構(gòu)將這些數(shù)據(jù)加載到精煉的數(shù)據(jù)倉庫中。雖然這種方法并沒有什么問題，但是數(shù)據(jù)湖和數(shù)據(jù)倉庫的組合才是組織真正需要的解決方案。

為什么要創(chuàng)建數(shù)據(jù)湖？

為數(shù)據(jù)倉庫構(gòu)建暫存區(qū)，數(shù)據(jù)湖并不需要成為數(shù)據(jù)的最終存儲目的地。由于數(shù)據(jù)不斷流動并改變其形式，現(xiàn)代數(shù)據(jù)平臺應(yīng)該便于數(shù)據(jù)的攝取和發(fā)現(xiàn)，同時又要為分析需求提供完整而嚴格的結(jié)構(gòu)。常見的一個模式是數(shù)據(jù)湖充當數(shù)據(jù)攝取的不可變層。任何內(nèi)容都不會從中刪除(可能只會被新版本覆蓋，或者出于合規(guī)性原因而刪除)。所有被攝取到數(shù)據(jù)平臺的原始數(shù)據(jù)都可以在數(shù)據(jù)湖中找到。這意味著組織仍然可以有ELT/ETL作業(yè)來轉(zhuǎn)換和清理數(shù)據(jù)，然后將其接收到數(shù)據(jù)倉庫中，同時嚴格遵循Kimbol、Inmon或Data Vault方法。

組織無需在數(shù)據(jù)湖或數(shù)據(jù)倉庫之間進行選擇，可以同時使用數(shù)據(jù)湖和不可更改的暫存區(qū)，以及將數(shù)據(jù)倉庫用于商業(yè)智能的分析報告。人工智能廠商Databricks公司創(chuàng)造了“湖倉一體”(Data Lakehouse)這一術(shù)語，也就是在一個解決方案中將數(shù)據(jù)湖和數(shù)據(jù)倉庫的優(yōu)點結(jié)合在一起。同樣，組織采用Snowflake之類的平臺將諸如S3之類的云存儲桶作為外部存儲，從而有效地利用數(shù)據(jù)湖作為暫存區(qū)域。最后，組織需要確定為其用例是選擇采用湖倉一體，還是數(shù)據(jù)湖與數(shù)據(jù)倉庫的組合。

研究發(fā)現(xiàn)，越來越多的數(shù)據(jù)團隊不再只是采用數(shù)據(jù)倉庫或數(shù)據(jù)湖，他們希望采用湖倉一體，這有著充分的理由。隨著更多用例的出現(xiàn)和涉及更多利益相關(guān)者，單一的解決方案難以滿足所有需求。

由于暫存區(qū)不可變，因此可以審核所有數(shù)據(jù)的日志，這些數(shù)據(jù)都被攝入到組織的數(shù)據(jù)生態(tài)系統(tǒng)中，審計跟蹤對于滿足合規(guī)性要求通常很重要。數(shù)據(jù)湖使收集元數(shù)據(jù)變得更容易，它可以了解用戶何時和從何處攝取數(shù)據(jù)。這不僅有助于合規(guī)性，而且有助于跟蹤數(shù)據(jù)所有權(quán)。

增加洞察價值的時間和數(shù)據(jù)價值，通過提供不可變的所有數(shù)據(jù)層，組織在獲取數(shù)據(jù)后立即向消費者提供數(shù)據(jù)。通過提供原始數(shù)據(jù)，組織將啟用探索性分析，而在不同的數(shù)據(jù)團隊以不同的方式使用相同的數(shù)據(jù)集時，這可能很難完成。通常情況下，不同的數(shù)據(jù)使用者可能需要基于相同原始數(shù)據(jù)的不同轉(zhuǎn)換。數(shù)據(jù)湖允許組織深入研究各種類型和形式的數(shù)據(jù)，并決定哪些數(shù)據(jù)可能為組織產(chǎn)生見解。

用于實時和批處理分析的單一數(shù)據(jù)平臺，將實時數(shù)據(jù)攝取到數(shù)據(jù)倉庫中仍然是一個具有挑戰(zhàn)性的問題。即使市場上推出嘗試解決這一問題的工具，但在利用數(shù)據(jù)湖作為提取所有數(shù)據(jù)的不可變層時，也可以輕松解決這一問題。例如，許多解決方案(例如Kinesis Data Streams或Apache Kafka)允許組織將S3存儲桶作為數(shù)據(jù)的接收器。

隨著社交媒體、傳感器、日志和Web分析數(shù)據(jù)量的不斷增長，將所有數(shù)據(jù)存儲在數(shù)據(jù)倉庫中的成本可能會變得越來越高昂。許多傳統(tǒng)的數(shù)據(jù)倉庫將存儲和處理緊密地結(jié)合在一起，使得數(shù)據(jù)倉庫的擴展變得更加困難。數(shù)據(jù)湖彼此獨立地擴展存儲和處理(查詢和API請求以檢索數(shù)據(jù))的規(guī)模，而一些云計算數(shù)據(jù)倉庫也支持這種范例。

通常情況下，采用數(shù)據(jù)倉庫解決方案要求組織管理基礎(chǔ)計算集群。云計算供應(yīng)商開始意識到這樣做的困難，并建立了完全托管或完全無服務(wù)器的數(shù)據(jù)存儲。例如，將S3存儲桶與AWS Glue和Athena結(jié)合使用時，組織的平臺仍然不需要采用服務(wù)器，并只需為其使用的內(nèi)容支付費用。

經(jīng)得起未來的考驗，根據(jù)調(diào)查和統(tǒng)計，通常存儲在數(shù)據(jù)倉庫中的數(shù)據(jù)中至少有三分之一幾乎從未使用過。組織需要攝取、清理和維護這樣的數(shù)據(jù)源，以便以后可能需要它們。這意味著數(shù)據(jù)工程師將要花費大量時間和精力來構(gòu)建和維護可能還沒有明確業(yè)務(wù)需求的數(shù)據(jù)。

ELT范例使組織可以通過只針對實際需要的用例構(gòu)建數(shù)據(jù)管道來節(jié)省時間，同時將所有數(shù)據(jù)存儲在數(shù)據(jù)湖中以備將來可能的用例使用。如果在將來出現(xiàn)特定的業(yè)務(wù)問題，則可能會找到答案，因為數(shù)據(jù)已經(jīng)存在。但是組織不必花時間清理和維護數(shù)據(jù)管道，以解決尚無明確業(yè)務(wù)用例的問題。數(shù)據(jù)湖和云計算數(shù)據(jù)平臺能夠經(jīng)得起未來考驗的另一個原因是，如果組織的業(yè)務(wù)增長迅速，則其平臺將具備快速擴展的能力。組織不需要采用成本高昂的遷移方案即可轉(zhuǎn)換到更大或更小的數(shù)據(jù)庫來適應(yīng)其規(guī)模的增減。無論組織選擇哪一種方法，組織的云數(shù)據(jù)平臺都應(yīng)允許其無限制地增長數(shù)據(jù)資產(chǎn)。

我們知道了數(shù)據(jù)湖以及具有數(shù)據(jù)湖功能的數(shù)據(jù)倉庫構(gòu)成了經(jīng)得起未來考驗的數(shù)據(jù)平臺的重要組成部分，如果您想了解更多相關(guān)信息，請您及時關(guān)注中培偉業(yè)。