今天，每秒都在生成 TB 和 PB 的數據，為這些海量數據集尋找存儲解決方案至關(guān)重要。復雜的機器和技術(shù)現在收集了令人難以置信的廣泛數據——每天超過(guò) 2.5 萬(wàn)億字節！— 來(lái)自設備傳感器、日志、用戶(hù)、消費者和其他地方。數據存儲并不像以前看起來(lái)那么簡(jiǎn)單。在管理和存儲數據時(shí)，數據管理者需要考慮使用數據湖或數據倉庫作為存儲庫。隨著(zhù)數據量、速度和種類(lèi)的增加，選擇合適的數據平臺來(lái)管理數據從未像現在這樣重要。它應該是迄今為止滿(mǎn)足我們需求的古老數據倉庫，還是應該是承諾支持任何類(lèi)型工作負載的任何類(lèi)型數據的數據湖？數據湖是一個(gè)中央存儲庫，可以大量存儲所有數據（結構化和非結構化數據）。數據通常以原始格式存儲，無(wú)需首先進(jìn)行處理或結構化。在這種情況下，它可以針對手頭的目的進(jìn)行優(yōu)化和處理，無(wú)論是交互式分析、下游機器學(xué)習或分析應用程序的儀表板。
可以這樣想，數據湖就像一個(gè)大水體，比如說(shuō)一個(gè)處于自然狀態(tài)的湖。數據湖是使用來(lái)自各種來(lái)源的數據流創(chuàng )建的，然后，多個(gè)用戶(hù)可以來(lái)到湖中對其進(jìn)行檢查并取樣。數據湖的美妙之處在于每個(gè)人都在查看和操作相同的數據。消除多個(gè)數據源并在數據湖中擁有一個(gè)可引用的“黃金”數據集來(lái)保障組織內的一致性，因為用于訪(fǎng)問(wèn)組織中智能的任何其他下游存儲庫或技術(shù)都將同步。這很關(guān)鍵。使用這種集中的數據源，就不會(huì )從不同的孤島中提取數據；組織中的每個(gè)人都有一個(gè)單一的事實(shí)來(lái)源。
該模式為公司的分析生命周期提供了近乎無(wú)限的能力：
攝取：數據以任何原始格式到達并存儲以供將來(lái)分析或災難恢復。公司通常會(huì )根據隱私、生產(chǎn)訪(fǎng)問(wèn)以及將利用傳入信息的團隊來(lái)劃分多個(gè)數據湖。存儲：數據湖允許企業(yè)管理和組織幾乎無(wú)限量的信息。云對象存儲以較低的成本為大數據計算提供高可用性訪(fǎng)問(wèn)。流程：借助云計算，基礎設施現在只需一個(gè) API 調用即可。這是從數據湖中的原始狀態(tài)獲取數據并格式化以與其他信息一起使用的時(shí)候。這些數據也經(jīng)常使用高級算法進(jìn)行聚合、合并或分析。然后將數據推回數據湖以供商業(yè)智能或其他應用程序存儲和進(jìn)一步使用。消費：當我們談?wù)撟灾?wù)數據湖時(shí)，消費通常是生命周期中的階段。此時(shí)，數據可供業(yè)務(wù)和客戶(hù)根據需要進(jìn)行分析。根據復雜用例的類(lèi)型，最終用戶(hù)還可以間接或直接以預測（預測天氣、財務(wù)、運動(dòng)表現等）或感知分析（推薦引擎、欺詐檢測、基因組測序、 ETC）。數據湖支持原生流，數據流在其中被處理并在到達時(shí)可用于分析。數據管道在從數據流接收數據時(shí)轉換數據，并觸發(fā)分析所需的計算。數據湖的原生流式傳輸特性使其非常適合流式分析。數據倉庫發(fā)明于1980 年底，專(zhuān)為業(yè)務(wù)應用程序生成的高度結構化數據而設計。它將組織的所有數據集中在一起并以結構化方式存儲。它通常用于連接和分析來(lái)自異構來(lái)源的數據。
數據倉庫架構依賴(lài)于數據結構來(lái)支持高性能的 SQL（結構化查詢(xún)語(yǔ)言）操作。數據倉庫是專(zhuān)門(mén)為基于 SQL 的訪(fǎng)問(wèn)而構建和優(yōu)化的，以支持商業(yè)智能，但為流分析和機器學(xué)習提供有限的功能。它們受到 ETL 要求的限制，需要在存儲數據之前對其進(jìn)行預處理。數據倉庫在數據用于分析之前需要順序 ETL攝取和轉換數據，因此它們對于流式分析效率低下。一些數據倉庫支持“微批處理”以經(jīng)常以小增量收集數據。它支持順序 ETL 操作，其中數據以瀑布模型從原始數據格式流向完全轉換的集合，并針對快速性能進(jìn)行了優(yōu)化。數據倉庫以專(zhuān)有格式存儲數據。一旦數據存儲在數據倉庫中，對該數據的訪(fǎng)問(wèn)僅限于 SQL 和數據倉庫提供的自定義驅動(dòng)程序。一些較新的數據倉庫支持半結構化數據，例如 JSON、Parquet 和 XML 文件；與結構化數據集相比，它們對此類(lèi)數據集的支持有限且性能下降。數據倉庫不能完全支持存儲非結構化數據。數據倉庫和商業(yè)智能工具支持歷史數據的報告和分析，而數據湖支持利用數據進(jìn)行機器學(xué)習、預測和實(shí)時(shí)分析的新用例。雖然一些數據倉庫擴展了基于 SQL 的訪(fǎng)問(wèn)以提供機器學(xué)習功能，但它們不提供原生支持來(lái)運行廣泛可用的程序化數據處理框架，例如 Apache Spark、Tensorflow 等。相比之下，數據湖是機器學(xué)習用例的理想選擇。它們不僅提供基于 SQL 的數據訪(fǎng)問(wèn)，還通過(guò) Python、Scala、Java 等語(yǔ)言為 Apache Spark 和 Tensorflow 等編程分布式數據處理框架提供原生支持。數據倉庫需要在數據用于分析之前順序 ETL攝取和轉換數據，因此它們對于流式分析效率低下。一些數據倉庫支持“微批處理”以經(jīng)常以小增量收集數據。這種流到批處理的轉換增加了數據到達與用于分析之間的時(shí)間，使得數據倉庫不適用于多種形式的流分析。數據湖支持本地流式傳輸，其中數據流在到達時(shí)被處理并可供分析。數據管道在從數據流接收數據時(shí)轉換數據，并觸發(fā)分析所需的計算。數據湖的原生流式傳輸特性使其非常適合流式分析。數據倉庫支持順序 ETL 操作，其中數據以瀑布模型從原始數據格式流向完全轉換的集合，并針對快速性能進(jìn)行了優(yōu)化。相比之下，對于需要持續數據工程的用例，數據湖異常強大。在數據湖中，ETL 的瀑布方法被迭代和連續的數據工程所取代?？梢酝ㄟ^(guò) SQL 和編程接口迭代地訪(fǎng)問(wèn)和轉換數據湖中的原始數據，以滿(mǎn)足用例不斷變化的需求。這種對持續數據工程的支持對于交互式分析和機器學(xué)習至關(guān)重要。揭穿關(guān)于數據湖和數據倉庫的三大神話(huà)讓我們解決一些關(guān)于兩種流行的數據存儲類(lèi)型的常見(jiàn)誤解：
誤區一：只需要數據湖或數據倉庫中的一個(gè)
如今，經(jīng)常聽(tīng)到人們談?wù)摂祿蛿祿}庫，好像企業(yè)必須選擇其中一個(gè)。但現實(shí)情況是，數據湖和數據倉庫服務(wù)于不同的目的。雖然兩者都提供數據存儲，但它們使用不同的結構，支持不同的格式，并針對不同的用途進(jìn)行了優(yōu)化。通常，公司可能會(huì )從使用數據倉庫和數據湖中受益。數據倉庫最適合希望為商業(yè)智能分析操作系統數據的企業(yè)。數據倉庫在這方面工作得很好，因為存儲的數據是結構化、清理和準備分析的。同時(shí)，數據湖允許企業(yè)以任何格式存儲數據以用于幾乎任何用途，包括機器學(xué)習 (ML) 模型和大數據分析。人工智能 (AI) 和 ML 代表了一些增長(cháng)最快的云工作負載，組織越來(lái)越多地轉向數據湖來(lái)幫助確保這些項目的成功。由于數據湖允許存儲幾乎任何類(lèi)型的數據（結構化和非結構化）而無(wú)需事先準備或清理，因此組織能夠保留盡可能多的潛在價(jià)值以供將來(lái)使用，未指定使用。此設置非常適合更復雜的工作負載，例如尚未確定具體數據類(lèi)型和用途的機器學(xué)習模型。數據倉庫可能是這兩種選擇中更為人所知的一種，但數據湖和類(lèi)似類(lèi)型的存儲基礎設施可能會(huì )隨著(zhù)數據工作負載的趨勢而繼續流行。數據倉庫適用于某些類(lèi)型的工作負載和用例，而數據湖代表了服務(wù)于其他類(lèi)型工作負載的另一種選擇。數據湖需要數據工程師和數據科學(xué)家的特定技能來(lái)分類(lèi)和利用其中存儲的數據。數據的非結構化性質(zhì)使得那些不了解數據湖如何工作的人更不容易訪(fǎng)問(wèn)它。但是，一旦數據科學(xué)家和數據工程師構建了數據模型或管道，業(yè)務(wù)用戶(hù)通?？梢岳门c流行業(yè)務(wù)工具的集成（自定義或預構建）來(lái)探索數據。同樣，大多數業(yè)務(wù)用戶(hù)通過(guò)連接的商業(yè)智能 (BI) 工具訪(fǎng)問(wèn)存儲在數據倉庫中的數據。在第三方 BI 工具的幫助下，業(yè)務(wù)用戶(hù)應該能夠訪(fǎng)問(wèn)和分析數據，無(wú)論該數據存儲在數據倉庫還是數據湖中。盡量減少數據平臺中人員、網(wǎng)絡(luò )和磁盤(pán)操作的影響。雖然人類(lèi)永遠無(wú)法像計算機一樣快，但網(wǎng)絡(luò )和磁盤(pán)操作是客觀(guān)問(wèn)題。為了減少這些問(wèn)題的影響，避免在各處復制數據，加強平臺讀取和處理來(lái)自不同位置的數據的能力，包括事務(wù)性、發(fā)布/子系統和數據倉庫系統，而無(wú)需當天移動(dòng)。構建現代數據平臺的原則是：把事情簡(jiǎn)單化，不要過(guò)度架構或過(guò)度設計；將數據與上下文分開(kāi)，這將使數據能夠用于多個(gè)用例。Data Lake 已經(jīng)成為一個(gè)強大的平臺，企業(yè)可以使用它來(lái)管理、挖掘大量非結構化數據并將其貨幣化，以獲得競爭優(yōu)勢。因此，公司對數據湖平臺的采用率急劇增加。
在這種利用大數據的熱潮中，一直存在一種誤解，即 Data Lake 旨在取代數據倉庫，而實(shí)際上，Data Lake 旨在補充傳統的關(guān)系數據庫管理系統 (RDBMS)。數據倉庫適用于某些類(lèi)型的工作負載和用例，而數據湖代表了服務(wù)于其他類(lèi)型工作負載的另一種選擇。用例應該驅動(dòng)數據平臺架構。如果您的用例需要速度、具有已知的數據模型、完全結構化或非常接近它，那么 SQL 數據倉庫就足夠了。但是，如果您需要及時(shí)靈活地對數據進(jìn)行建模并將其用于多種工作負載，您應該使用數據湖。組織將依靠多種技術(shù)的最佳解決方案，包括數據倉庫和數據湖。最終，組織的選擇需要平衡管理多種技術(shù)的復雜性和 TCO 與以高性能和經(jīng)濟高效的方式運行更多種類(lèi)的工作負載的能力。我們現在處于這樣一個(gè)階段，我們不僅可以使用數據來(lái)回顧過(guò)去，還可以了解現在，甚至可以預測未來(lái)。數據和工具將不斷發(fā)展，以幫助我們幾乎實(shí)時(shí)地到達那里。
將數據與上下文分開(kāi)。進(jìn)來(lái)的數據不一定有你想用它的上下文。所以，在弄清楚你想用它做什么之前，把將數據獲取到一個(gè)位置的想法分開(kāi)。因為實(shí)際上，您將對該數據進(jìn)行多種用途。因此，您永遠不知道您可以將這些數據用于什么用途。因此，如果您首先獲取數據，然后弄清楚您想用它做什么，通常會(huì )導致使用這些數據產(chǎn)生更積極的結果。數據倉庫供應商正在逐漸從他們現有的模型轉向數據倉庫和數據湖模型的融合。同樣，數據湖的供應商現在正在擴展到數據倉庫領(lǐng)域，雙方正在趨同。例如，BigQuery 現在允許組織在 Amazon S3 上查詢(xún)數據。同樣，Databricks 和 Qubole 等數據湖平臺現在正在果斷地轉向數據倉庫用例。您可以使用 ACID 屬性、事務(wù)一致性、快照等來(lái)管理存儲，并將查詢(xún)引擎更多地與存儲管理集成，為客戶(hù)創(chuàng )建湖倉模式。數據湖和數據倉庫之間的融合不僅僅是在談?wù)?，而是正在現實(shí)中應用。
