一文讀懂選擇資料湖還是資料倉儲

今天，每秒都在生成 TB 和 PB 的資料，為這些海量資料集尋找儲存解決方案至關重要。複雜的機器和技術現在收集了令人難以置信的廣泛資料——每天超過 2.5 萬億位元組!— 來自裝置感測器、日誌、使用者、消費者和其他地方。資料儲存並不像以前看起來那麼簡單。在管理和儲存資料時，資料管理者需要考慮使用資料湖或資料倉儲作為儲存庫。

隨著資料量、速度和種類的增加，選擇合適的資料平臺來管理資料從未像現在這樣重要。它應該是迄今為止滿足我們需求的古老資料倉儲，還是應該是承諾支援任何型別工作負載的任何型別資料的資料湖?

在這裡，我們深入探討了這兩個平臺.

資料湖

資料湖是一箇中央儲存庫，可以大量儲存所有資料(結構化和非結構化資料)。資料通常以原始格式儲存，無需首先進行處理或結構化。在這種情況下，它可以針對手頭的目的進行最佳化和處理，無論是互動式分析、下游機器學習或分析應用程式的儀表板。

可以這樣想，資料湖就像一個大水體，比如說一個處於自然狀態的湖。資料湖是使用來自各種來源的資料流建立的，然後，多個使用者可以來到湖中對其進行檢查並取樣。資料湖的美妙之處在於每個人都在檢視和操作相同的資料。消除多個資料來源並在資料湖中擁有一個可引用的“黃金”資料集來保障組織內的一致性，因為用於訪問組織中智慧的任何其他下游儲存庫或技術都將同步。這很關鍵。使用這種集中的資料來源，就不會從不同的孤島中提取資料;組織中的每個人都有一個單一的事實來源。

該模式為公司的分析生命週期提供了近乎無限的能力：

• 攝取：資料以任何原始格式到達並儲存以供將來分析或災難恢復。公司通常會根據隱私、生產訪問以及將利用傳入資訊的團隊來劃分多個資料湖。

• 儲存：資料湖允許企業管理和組織幾乎無限量的資訊。雲物件儲存以較低的成本為大資料計算提供高可用性訪問。

• 流程：藉助雲端計算，基礎設施現在只需一個 API 呼叫即可。這是從資料湖中的原始狀態獲取資料並格式化以與其他資訊一起使用的時候。這些資料也經常使用高階演算法進行聚合、合併或分析。然後將資料推回資料湖以供商業智慧或其他應用程式儲存和進一步使用。

• 消費：當我們談論自助服務資料湖時，消費通常是生命週期中的階段。此時，資料可供業務和客戶根據需要進行分析。根據複雜用例的型別，終端使用者還可以間接或直接以預測(預測天氣、財務、運動表現等)或感知分析(推薦引擎、欺詐檢測、基因組測序、 ETC)。

資料湖支援原生流，資料流在其中被處理並在到達時可用於分析。資料管道在從資料流接收資料時轉換資料，並觸發分析所需的計算。資料湖的原生流式傳輸特性使其非常適合流式分析。

資料倉儲

資料倉儲發明於1980 年底，專為業務應用程式生成的高度結構化資料而設計。它將組織的所有資料集中在一起並以結構化方式儲存。它通常用於連線和分析來自異構來源的資料。

資料倉儲架構依賴於資料結構來支援高效能的 SQL(結構化查詢語言)操作。資料倉儲是專門為基於 SQL 的訪問而構建和最佳化的，以支援商業智慧，但為流分析和機器學習提供有限的功能。它們受到 ETL 要求的限制，需要在儲存資料之前對其進行預處理。

資料倉儲在資料用於分析之前需要順序 ETL攝取和轉換資料，因此它們對於流式分析效率低下。一些資料倉儲支援“微批處理”以經常以小增量收集資料。它支援順序 ETL 操作，其中資料以瀑布模型從原始資料格式流向完全轉換的集合，並針對快速效能進行了最佳化。

資料倉儲以專有格式儲存資料。一旦資料儲存在資料倉儲中，對該資料的訪問僅限於 SQL 和資料倉儲提供的自定義驅動程式。一些較新的資料倉儲支援半結構化資料，例如 JSON、Parquet 和 XML 檔案;與結構化資料集相比，它們對此類資料集的支援有限且效能下降。資料倉儲不能完全支援儲存非結構化資料。

資料湖和資料倉儲之間的區別

資料倉儲和商業智慧工具支援歷史資料的報告和分析，而資料湖支援利用資料進行機器學習、預測和實時分析的新用例。

雖然一些資料倉儲擴充套件了基於 SQL 的訪問以提供機器學習功能，但它們不提供原生支援來執行廣泛可用的程式化資料處理框架，例如 Apache Spark、Tensorflow 等。

相比之下，資料湖是機器學習用例的理想選擇。它們不僅提供基於 SQL 的資料訪問，還透過 Python、Scala、Java 等語言為 Apache Spark 和 Tensorflow 等程式設計分散式資料處理框架提供原生支援。

資料倉儲需要在資料用於分析之前順序 ETL攝取和轉換資料，因此它們對於流式分析效率低下。一些資料倉儲支援“微批處理”以經常以小增量收集資料。這種流到批處理的轉換增加了資料到達與用於分析之間的時間，使得資料倉儲不適用於多種形式的流分析。

資料湖支援本地流式傳輸，其中資料流在到達時被處理並可供分析。資料管道在從資料流接收資料時轉換資料，並觸發分析所需的計算。資料湖的原生流式傳輸特性使其非常適合流式分析。

資料倉儲支援順序 ETL 操作，其中資料以瀑布模型從原始資料格式流向完全轉換的集合，並針對快速效能進行了最佳化。

相比之下，對於需要持續資料工程的用例，資料湖異常強大。在資料湖中，ETL 的瀑布方法被迭代和連續的資料工程所取代。可以透過 SQL 和程式設計介面迭代地訪問和轉換資料湖中的原始資料，以滿足用例不斷變化的需求。這種對持續資料工程的支援對於互動式分析和機器學習至關重要。

揭穿關於資料湖和資料倉儲的三大神話

讓我們解決一些關於兩種流行的資料儲存型別的常見誤解：

誤區一：只需要資料湖或資料倉儲中的一個

如今，經常聽到人們談論資料湖和資料倉儲，好像企業必須選擇其中一個。但現實情況是，資料湖和資料倉儲服務於不同的目的。雖然兩者都提供資料儲存，但它們使用不同的結構，支援不同的格式，並針對不同的用途進行了最佳化。通常，公司可能會從使用資料倉儲和資料湖中受益。

資料倉儲最適合希望為商業智慧分析作業系統資料的企業。資料倉儲在這方面工作得很好，因為儲存的資料是結構化、清理和準備分析的。同時，資料湖允許企業以任何格式儲存資料以用於幾乎任何用途，包括機器學習 (ML) 模型和大資料分析。

誤區 2：資料湖是流行趨勢，資料倉儲不是

人工智慧 (AI) 和 ML 代表了一些增長最快的雲工作負載，組織越來越多地轉向資料湖來幫助確保這些專案的成功。由於資料湖允許儲存幾乎任何型別的資料(結構化和非結構化)而無需事先準備或清理，因此組織能夠保留儘可能多的潛在價值以供將來使用，未指定使用。此設定非常適合更復雜的工作負載，例如尚未確定具體資料型別和用途的機器學習模型。

資料倉儲可能是這兩種選擇中更為人所知的一種，但資料湖和類似型別的儲存基礎設施可能會隨著資料工作負載的趨勢而繼續流行。資料倉儲適用於某些型別的工作負載和用例，而資料湖代表了服務於其他型別工作負載的另一種選擇。

誤區三：資料倉儲易於使用，而資料湖很複雜

資料湖需要資料工程師和資料科學家的特定技能來分類和利用其中儲存的資料。資料的非結構化性質使得那些不瞭解資料湖如何工作的人更不容易訪問它。

但是，一旦資料科學家和資料工程師構建了資料模型或管道，業務使用者通常可以利用與流行業務工具的整合(自定義或預構建)來探索資料。同樣，大多數業務使用者透過連線的商業智慧 (BI) 工具訪問儲存在資料倉儲中的資料。在第三方 BI 工具的幫助下，業務使用者應該能夠訪問和分析資料，無論該資料儲存在資料倉儲還是資料湖中。

構建現代資料平臺的原則

儘量減少資料平臺中人員、網路和磁碟操作的影響。雖然人類永遠無法像計算機一樣快，但網路和磁碟操作是客觀問題。為了減少這些問題的影響，避免在各處複製資料，加強平臺讀取和處理來自不同位置的資料的能力，包括事務性、釋出/子系統和資料倉儲系統，而無需當天移動。構建現代資料平臺的原則是：

• 把事情簡單化，不要過度架構或過度設計;

• 為正確的工作使用正確的工具;

• 讓用例決定你應該使用什麼;

• 使用雲進行擴充套件;

• 將資料與上下文分開，這將使資料能夠用於多個用例。

資料湖和資料倉儲：用例

Data Lake 已經成為一個強大的平臺，企業可以使用它來管理、挖掘大量非結構化資料並將其貨幣化，以獲得競爭優勢。因此，公司對資料湖平臺的採用率急劇增加。

在這種利用大資料的熱潮中，一直存在一種誤解，即 Data Lake 旨在取代資料倉儲，而實際上，Data Lake 旨在補充傳統的關聯式資料庫管理系統 (RDBMS)。

資料倉儲適用於某些型別的工作負載和用例，而資料湖代表了服務於其他型別工作負載的另一種選擇。

用例應該驅動資料平臺架構。如果您的用例需要速度、具有已知的資料模型、完全結構化或非常接近它，那麼 SQL 資料倉儲就足夠了。但是，如果您需要及時靈活地對資料進行建模並將其用於多種工作負載，您應該使用資料湖。

組織將依靠多種技術的最佳解決方案，包括資料倉儲和資料湖。最終，組織的選擇需要平衡管理多種技術的複雜性和 TCO 與以高效能和經濟高效的方式執行更多種類的工作負載的能力。

未來該如何選擇

我們現在處於這樣一個階段，我們不僅可以使用資料來回顧過去，還可以瞭解現在，甚至可以預測未來。資料和工具將不斷髮展，以幫助我們幾乎實時地到達那裡。

將資料與上下文分開。進來的資料不一定有你想用它的上下文。所以，在弄清楚你想用它做什麼之前，把將資料獲取到一個位置的想法分開。因為實際上，您將對該資料進行多種用途。因此，您永遠不知道您可以將這些資料用於什麼用途。因此，如果您首先獲取資料，然後弄清楚您想用它做什麼，通常會導致使用這些資料產生更積極的結果。

資料倉儲供應商正在逐漸從他們現有的模型轉向資料倉儲和資料湖模型的融合。同樣，資料湖的供應商現在正在擴充套件到資料倉儲領域，雙方正在趨同。例如，BigQuery 現在允許組織在 Amazon S3 上查詢資料。同樣，Databricks 和 Qubole 等資料湖平臺現在正在果斷地轉向資料倉儲用例。您可以使用 ACID 屬性、事務一致性、快照等來管理儲存，並將查詢引擎更多地與儲存管理整合，為客戶建立湖倉模式。資料湖和資料倉儲之間的融合不僅僅是在談論，而是正在現實中應用。