如今，數據湖在大型企業中風靡一時。 數據湖是單個存儲，用於存儲源系統數據的原始副本和轉換後的數據，以用於報告，可視化，高級分析和機器學習等任務。
Figure 1: Data lake ecosystem
對象存儲（如S3）正成為數據湖的首選平臺，原因有兩個：
· 它們在雲中提供廉價，持久且幾乎無限的存儲
· 它們實現了計算和存儲的分離，從而可以獨立擴展任何一個
在這篇博客文章中，我將更深入地探討對象存儲的一些優點，這些對象存儲成為數據湖平臺的流行。 我還將研究一些經常被低估的難題，這些難題困擾著許多數據湖用例的對象存儲。
對象存儲的好處：持久，便宜且幾乎不受限制的存儲
像S3這樣的對象存儲提供11個9的耐用性（99.999999999％）和四個9的可用性（99.99％），並且他們設法以幾乎無限的規模做到了這一點，其價格低得令人難以置信，約為$ 23 / TB / TB。 與此形成鮮明對比的是，幾年前流行的本地數據倉庫設備（DWA）。 不包括企業支持，DWA每TB的成本為數萬美元。 僅支持數百TB的數百萬美元的DWA合同是很常見的。
當IT領導者考慮為其數據湖選擇數據平臺時，對象存儲的$ 23 / TB /月的價格標籤實在令人無法抗拒。 使用最便宜的存儲空間來存儲預期將要容納的數據湖的大量數據（從數百TB到PB）是有意義的。 像S3這樣的對象存儲（不正確，我們將在本文後面看到）似乎比許多大型企業仍在使用的DWA具有千倍的定價優勢。
對象存儲的好處：存儲和計算的分離
數據湖所需的存儲規模使使用DWA之類的架構（將存儲和計算耦合到單個程序包中）的成本過高。 通過解耦存儲和計算，我們可以在任何給定時間攜帶適當數量的按需計算，以承載需要分析的數據。 這大大降低了數據分析解決方案的總體成本。
Figure 2: Separation of storage and compute
可以理解，所有這些優勢對於推動S3和其他對象存儲作為數據湖平臺的普及至關重要。 但是對象存儲面臨很多挑戰，沒有引起足夠的重視。 對於源於RDBMS且經常刷新（每天/每小時）的數據尤其如此，後者構成了企業中大量的高質量數據。
對象存儲的缺點：不變性
所有對象存儲，包括S3，GCS和Azure Blob存儲，都是不可變的。 這意味著，一旦將文件寫入對象存儲，就無法對其進行編輯。 用戶只能硬刪除舊文件並創建一個新文件，或者在邏輯上刪除該舊文件並創建一個新文件（版本控制）。
當使用S3作為源於RDBMS且經常刷新的數據的數據平臺時，這將導致為每個表創建大量的小文件。
Figure 3: The problem of many small files for RDBMS-sourced data
隨著插入，更新和刪除隨著時間的推移而堆積，嘗試導出表的當前狀態將成倍增加時間和計算量。 大多數數據科學家都對這項複雜的工作不屑一顧，而是要求直接訪問源系統，從而一開始就破壞了使用數據湖的目的。
Figure 4: Problems with using raw changesets on S3
U =更新，I =插入，D =刪除
解決方案，第1部分：對數據進行分區
解除最終用戶合併變更責任的一種解決方案是對數據進行分區，然後重新寫入最新插入，更新和刪除所針對的分區。 這在一定程度上減輕了最終用戶的負擔。 但是，仍然存在性能問題，特別是如果表中包含大量列並且僅需要這些列的子集進行分析時。
Figure 5: Using partitions to merge changesets
解決方案，第2部分：使用列式存儲
通過使用諸如Apache Parquet或Apache ORC之類的列格式，可以改進上述解決方案。 列格式通過更好地壓縮數據並將I / O限制為僅用於分析所需的列，從而顯著提高了性能。 但是，從語言和工具（如Python，R或Tableau）讀取Parquet文件仍然很困難。
Figure 6: Columnar storage helps with performance
解決方案，第3部分：使用SQL接口簡化訪問
為了進一步構建此解決方案，許多工程師在原始Parquet文件上添加了SQL接口（例如AWS Athena，Presto或Spark SQL）。 這使最終用戶的數據訪問變得更加簡化，最終用戶現在可以跨自己喜歡的編程語言和工具（例如Python，R或Tableau）發出SQL查詢。
Figure 7: SQL interfaces simplify access to data in a data lake
解決方案，第4部分：使用Delta Lake添加功能
通過使用像Delta Lake這樣的開源存儲層，可以再次改進上述解決方案。 Delta Lake通過增加對ACID（原子性，一致性，隔離性，持久性）交易的支持，支持流和批處理用例的lambda架構以及訪問先前刷新日期/之前的數據的能力，進一步改進了Parquet格式。 時間（時間旅行）。
Figure 8: Delta Lake adds transactions, simultaneous batch and streaming use cases, and time travel
問題解決了？
沒那麼快！ 上面的架構確實代表了可行的解決方案，並且許多企業為能夠設計和實施這種解決方案而自以為是。 公平地說，能夠大規模實現這一目標是相當可觀的。 但是，該體系結構仍然困擾著許多問題，並且還有很多改進的餘地。 作為數據湖平臺的S3上的Delta Lake的關鍵問題包括：
· 該體系結構無法解決變更集的創建問題，因此創建變更集可能會遇到很大的挑戰
· 實施和支持企業級的彈性提取，轉換和加載（ETL）解決方案非常複雜
· 編寫Parquet和Delta文件需要額外的計算以及技術知識，才能大規模配置和運行集群計算平臺（例如Apache Spark）
· SQL接口訪問（通過AWS Athena，Presto或Spark SQL等技術）需要附加的計算基礎架構，從而增加了解決方案的整體複雜性和成本
· 解決方案的複雜性使其支持成本高昂
· S3提供有限的元數據和標記功能
· 在S3中的對象上集成表級或行級安全性，尤其是對於大型和複雜的企業，可能會非常具有挑戰性
· 最後但並非最不重要的一點是，這種平臺的性能遠遠落後於它打算取代的數據倉庫設備的性能
考慮到隱藏的計算和支持成本，安全性集成和性能問題，S3作為用於RDBMS的，經常刷新的數據的數據平臺，與其每月每TB 23美元的承諾相去甚遠。 一旦我們將所有成本加起來，它便開始攀升至每月每TB數千美元的範圍。 對於那種錢，有很多更好的選擇。
諸如Snowflake，Google BigQuery或Azure Synapse Analytics之類的雲級託管分析數據庫提供了兩全其美的優勢。 通過將存儲和計算分開，它們提供了S3可比的存儲成本以及可管理的數據平臺，該平臺抽象了實現雲規模分析解決方案的複雜性。 它們具有AWS Athena / Presto / Spark SQL界面，提供了與基於S3的Parquet / ORC / Delta Lake類似的TCO，同時擁有更好的性能，安全性集成和架構支持。 它們還減少了運營開銷，同時將技術和人才風險轉移給了第三方供應商。
Figure 9: Advantages of a managed analytics DBs over the "object-store + Delta Lake + SQL interfaces
源自RDBMS的大部分為靜態數據呢？
基於RDBMS的，大多數為靜態數據（即數週或數月不變）不會像基於RDBMS的，經常刷新的數據那樣產生大量的ETL計算和支持開銷。 但是，對於此類用例，我的建議是首選基於雲規模的託管分析數據庫，而不是基於S3的Parquet / ORC / Delta Lake存儲，因為圍繞元數據管理，安全集成和性能的所有挑戰和成本仍然存在。
那半結構化數據呢？
進入企業的大多數半結構化數據（通過XML，JSON和CSV等格式）都具有相當穩定的架構，可以將其吸收到關係表中。 大型企業中的大多數此類數據經常被吸收到AWS Redshift等分析數據庫中，或通過基於S3的Parquet / ORC / Delta Lake存儲通過SQL接口（如AWS Athena，Presto或Spark SQL）進行訪問。 對於這種類型的用例，我的建議是考慮將存儲和計算分開的託管分析數據庫。
TCO應該是您的北極星
最後，應根據總擁有成本（TCO）來考慮解決方案，並要考慮它們帶來的功能和解決方案固有的風險。 如果兩種解決方案的總擁有成本相似，但是其中一種提供了更好的功能，那麼與該解決方案保持一致就很容易了。 此外，應仔細考慮與內部開發的解決方案相關的技術和人才風險。 通常，對於大型企業，在合理的情況下，將技術和人才風險轉移到信譽良好的供應商產品上更為合理。
Figure 10: Balancing TCO, performance, features, and risk
那麼什麼時候對象存儲可用作數據湖平臺？
對於其他用例，例如半結構化和非結構化數據，由於（出於成本或實用性的原因）不能或不應該將其吸收到雲規模分析數據庫中，對象存儲（如S3）仍然是一個極好的數據平臺。 例如，將圖像，音頻文件，視頻，電子郵件，PowerPoint演示文稿，Word文檔或PDF提取到託管分析數據庫中是沒有意義的。 此外，許多這些雲規模的分佈式數據庫都使用對象存儲（如S3）作為它們的數據攝取接口，甚至有一些甚至使用對象存儲作為幕後的內部管理存儲平臺。
Table 1: Recommendations
在以後的文章中，我們將深入討論為什麼將存儲和計算分開的雲級託管分析數據庫（例如Snowflake，Google BigQuery或Azure Synapse Analytics），以及專門構建的CDC工具（例如Qlik Replicate，Oracle GoldenGate或 HVR CDC）更適合企業數據湖中源自RDBMS的，經常刷新的數據。
(本文翻譯自Farhan Siddiqui的文章《Why and When to Avoid S3 as a Data Platform for Data Lakes》，參考：https://medium.com/swlh/why-and-when-to-avoid-s3-as-a-data-platform-for-data-lakes-c802947664e4)
閱讀更多 聞數起舞 的文章
