[[391266]]

【51CTO.com快譯】數據倉庫長期以來一直是管理大數據的標準方法，但是數據湖是否更適合組織的需要?其答案是肯定的。

隨著當今數據的數量、速度和種類的不斷變化，人們開始意識到，并沒有一種能夠滿足組織所有數據需求的數據庫。與其相反，許多組織已經轉向為特定用例或項目選擇合適的數據存儲技術。數據分散存儲在不同數據存儲空間中給組織整合數據進行分析帶來了挑戰。從歷史上看，唯一可行的解決方案是構建數據倉庫，這可以從所有不同的數據源攝取數據，在清理之后并將其合并在一起，最后以定義良好的結構將這些數據加載到精煉的數據倉庫中。雖然這種方法并沒有什么問題，但是數據湖和數據倉庫的組合才是組織真正需要的解決方案。以下是組織為什么應該采用數據湖的7個原因：

為什么要創建數據湖

1.為數據倉庫構建暫存區

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

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

最后，組織需要確定為其用例是選擇采用湖倉一體，還是數據湖與數據倉庫的組合。

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

2.由于暫存區不可變，因此可以審核所有數據的日志，這些數據都被攝入到組織的數據生態系統中

審計跟蹤對于滿足合規性要求通常很重要。數據湖使收集元數據變得更容易，它可以了解用戶何時和從何處攝取數據。這不僅有助于合規性，而且有助于跟蹤數據所有權。

3.增加洞察價值的時間和數據價值

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

4.用于實時和批處理分析的單一數據平臺

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

5.成本

隨著社交媒體、傳感器、日志和Web分析數據量的不斷增長，將所有數據存儲在數據倉庫中的成本可能會變得越來越高昂。許多傳統的數據倉庫將存儲和處理緊密地結合在一起，使得數據倉庫的擴展變得更加困難。

數據湖彼此獨立地擴展存儲和處理(查詢和API請求以檢索數據)的規模，而一些云計算數據倉庫也支持這種范例。

6.便利性

通常情況下，采用數據倉庫解決方案要求組織管理基礎計算集群。云計算供應商開始意識到這樣做的困難，并建立了完全托管或完全無服務器的數據存儲。

例如，將S3存儲桶與AWS Glue和Athena結合使用時，組織的平臺仍然不需要采用服務器，并只需為其使用的內容支付費用。組織可以利用這個單一數據平臺執行以下操作：

• 檢索關系和非關系數據
• 查詢歷史和實時數據
• 檢查組織機器學習訓練工作和服務機器學習模型
• 攝取數據之后直接在應用轉換之前查詢數據
• 通過外部表合并來自數據湖和DWH表的數據(幾乎在所有DWH解決方案中都可用)
• 與其他服務和分布式計算框架(例如Dask或Spark)集成

關于數據集成，在AWS云平臺上，組織可以利用：

• 數據湖形成的通道管理
• awswrangler(可在AWS上稱為Pandas的Python庫)
• Quicksight(AWS BI工具)
• Delta lake(由Databricks創建的開源平臺)
• lakeFS(數據的版本控制)
• Upsolver(使用Kappa架構，例如數據流和批處理的數據攝取)
• AWS Database Migration Service可以使組織將數據從RDS數據庫表(甚至整個架構)以增量方式導出到S3存儲桶文件中，這些文件可以使用AWS Glue使用Athena進行查詢。

7.經得起未來的考驗

根據調查和統計，通常存儲在數據倉庫中的數據中至少有三分之一幾乎從未使用過。組織需要攝取、清理和維護這樣的數據源，以便以后可能需要它們。這意味著數據工程師將要花費大量時間和精力來構建和維護可能還沒有明確業務需求的數據。

ELT范例使組織可以通過只針對實際需要的用例構建數據管道來節省時間，同時將所有數據存儲在數據湖中以備將來可能的用例使用。如果在將來出現特定的業務問題，則可能會找到答案，因為數據已經存在。但是組織不必花時間清理和維護數據管道，以解決尚無明確業務用例的問題。

數據湖和云計算數據平臺能夠經得起未來考驗的另一個原因是，如果組織的業務增長迅速，則其平臺將具備快速擴展的能力。組織不需要采用成本高昂的遷移方案即可轉換到更大或更小的數據庫來適應其規模的增減。

無論組織選擇哪一種方法，組織的云數據平臺都應允許其無限制地增長數據資產。

用例演示：AWS上具有Data Lake的無服務器事件驅動ETL

為了構建事件驅動的ETL演示，使用了一個數據集，并遵循了Databricks的“金銀銅”原則。簡而言之，這意味著組織將“青銅”層用于原始數據，將“白銀”層用于預處理和干凈的數據，最后，“黃金”層用于已經整理數據的最后階段。為了實現這一點而創建：

• 用于原始數據的S3存儲桶：s3//data-lake-bronze
• 用于清理和轉換數據的S3存儲桶：s3//data-lake-silver
• 只要新文件到達“青銅”S3存儲桶中，就會觸發AWS Lambda函數。它將轉換新對象并將數據加載到“白銀”階段。

指令wr.s3.to_parquet()不僅將數據加載到新的數據湖位置，而且還包括：

• 使用snappy和parquet格式壓縮數據
• 根據Pandas數據框的數據類型和列名對架構進行分類
• 將架構存儲在AWS Glue目錄中
• 創建一個新的Athena表

因此，可以看到S3、AWS Glue和Athena如何在管理控制臺中一起發揮作用。

帶有Lambda的無服務器ETL如何擴展?

想象一下，組織將對更多數據集執行類似的操作。管理所有這些lambda函數可能會充滿挑戰。即使AWS Lambda的計算能力可以無限擴展，但管理數據轉換的狀態還是很困難的，尤其是在實時和事件驅動的場景中。如果使用Dashbird之類的可觀察性平臺，則可以輕松檢查哪些事件驅動的ETL工作負載獲得成功，哪些沒有成功。

而組織在測試功能時，可能會犯一些錯誤。而Dashbird平臺的可觀察性對于查看事件驅動的ETL的狀態(包括所有錯誤消息)非常有幫助。它可以更深入地了解日志，并檢查所有失敗的執行情況。想象一下，如果必須對數百個ETL作業執行這一操作，可能會遇到更大的困難。而配置故障警報就像將電子郵件地址或Slack頻道添加到警報策略一樣簡單。

組織還可以根據其他選定條件(例如冷啟動)，持續時間超過特定閾值(可能是僵尸任務)或在特定時間段內異常大量的函數調用來通知用戶。

結論

數據湖以及具有數據湖功能的數據倉庫構成了經得起未來考驗的數據平臺的重要組成部分。而預先為所有數據建立關系架構可能效率低下，并且可能與當今的數據需求不兼容。而擁有一個不變的數據攝取層來存儲曾經攝取的所有數據，這有利于審計、數據發現、再現以及修復數據管道中的錯誤。

原文標題：7 Reasons Why You Should Consider a Data Lake，作者：Anna Anisienia

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】