數據湖簡介

數據湖的曆史和演變

早期的數據管理:數據庫

在早期的數據管理中關係數據庫是公司用來收集、存儲和分析數據的主要方法。關係數據庫，也稱為關係數據庫管理係統(rdbms)，為公司提供了一種使用結構化查詢語言(SQL)存儲和分析關於客戶的高度結構化數據的方法。beplay体育app下载地址多年來，關係數據庫足以滿足公司的需求:需要存儲的數據量相對較小，而且關係數據庫簡單可靠。直到今天，關係數據庫仍然是存儲不太大的高度結構化數據的絕佳選擇。然而，數據的速度和規模即將爆發。

互聯網的興起，以及數據孤島

隨著互聯網的興起，公司發現自己被淹沒在客戶數據中。要存儲所有這些數據，單一的數據庫已經不夠了。公司通常建立多個按業務線組織的數據庫來保存數據。隨著數據量的不斷增長，公司最終可能會擁有幾十個用戶和用途不同的不連接的數據庫。

一方麵，這是一件幸事:有了更多更好的數據，公司能夠比以往任何時候都更精確地定位客戶並管理他們的運營。beplay体育app下载地址另一方麵，這導致了數據倉庫:分散的、碎片化的數據存儲。由於沒有辦法集中和綜合他們的數據，許多公司未能將其綜合成可操作的見解。這種痛苦導致了數據倉庫的興起。數據倉庫

數據倉庫的誕生是為了將公司的結構化數據統一到一個屋簷下

由於有如此多的數據存儲在不同的源係統中，公司需要一種方法來集成它們。“360度的客戶視圖”的想法成為了當時的想法，數據倉庫的誕生就是為了滿足這一需求，並將整個組織中的不同數據庫統一起來。

數據倉庫作為一種技術出現，它將組織的關係數據庫集合聚集在一個保護傘下，允許將數據作為一個整體進行查詢和查看。起初，數據倉庫通常運行在Teradata和Vertica等供應商提供的昂貴的基於本地設備的硬件上，後來在雲中可用。從90年代末開始，數據倉庫成為大公司最主要的數據架構。該技術的主要優勢包括:

• 集成多個數據源
• 為讀訪問優化的數據
• 能夠快速運行特別分析查詢
• 數據審計、治理和沿襲

數據倉庫很好地實現了它們的目的，但隨著時間的推移，這種技術的缺點變得很明顯。

• 無法存儲非結構化的原始數據
• 昂貴的專有硬件和軟件
• 由於存儲和計算能力的緊密耦合，難以擴展

Apache Hadoop™和Spark™支持非結構化數據分析，為現代數據湖奠定了基礎

隨著21世紀初“大數據”的興起，企業發現他們需要對數據集進行分析，而這些數據集無法在一台計算機上容納。此外，他們需要分析的數據類型並不總是結構整齊——公司也需要利用非結構化數據的方法。為了使大數據分析成為可能，並解決對數據倉庫成本和供應商鎖定的擔憂，Apache Hadoop™是一種開源的分布式數據處理技術。

什麼是Hadoop?

Apache Hadoop™是一個用於大數據分析的開源軟件集合，它允許大型數據集通過並行工作的計算機集群進行處理。它包括Hadoop MapReduce,HDFS (Hadoop Distributed File System)而且YARN(另一個資源協商者)。HDFS允許將單個數據集存儲在許多不同的存儲設備上，就像它是單個文件一樣。它與MapReduce算法協同工作，MapReduce算法決定如何將大型計算任務(如統計計數或聚合)拆分為可以在計算集群上並行運行的小得多的任務。

Hadoop的引入是大數據分析的分水嶺，主要有兩個原因。首先，這意味著一些公司可以從昂貴的專有數據倉庫軟件轉向運行免費開源Hadoop的內部計算集群。其次，它允許公司以一種以前不可能實現的方式分析大量非結構化數據。在Hadoop之前，擁有數據倉庫的公司通常隻能分析高度結構化的數據，但現在他們可以從更大的數據池中提取價值，其中包括半結構化和非結構化數據。一旦公司有能力分析原始數據，收集和存儲這些數據就變得越來越重要——這為現代數據湖奠定了基礎。

早期的數據湖建立在Hadoop上

早期建立在Hadoop MapReduce和HDFS上的數據湖取得了不同程度的成功。許多早期的數據湖使用Apache Hive™，使用戶能夠使用麵向hadoop的SQL引擎查詢數據。一些早期的數據湖成功了，而另一些則由於Hadoop的複雜性和其他因素而失敗了。直到今天，許多人仍然將“數據湖”一詞與Hadoop聯係在一起，因為它是第一個能夠收集和分析大量非結構化數據的框架。然而，今天，許多現代數據湖架構已經從本地Hadoop轉移到在雲中運行Spark。盡管如此，這些最初的嚐試仍然很重要，因為這些Hadoop數據湖是現代數據湖的前身。隨著時間的推移,Hadoop的流行程度趨於平穩，因為它存在大多數組織無法克服的問題，比如性能較慢，安全性有限，以及缺乏對流等重要用例的支持。

Apache Spark:支持現代數據湖的統一分析引擎

在Hadoop引入後不久，Apache火花介紹了。Spark進一步發展了MapReduce的思想，為大數據上的分布式計算提供了一個強大的通用框架。隨著時間的推移，Spark在數據從業者中越來越受歡迎，這主要是因為它易於使用，在基準測試中表現良好，並提供了額外的功能，增加了其實用性並擴大了其吸引力。例如，Spark的交互模式使數據科學家能夠對龐大的數據集進行探索性數據分析，而不必花費時間在編寫複雜代碼以將數據轉換為可靠源等低價值工作上。Spark還使大規模訓練機器學習模型、使用SQL查詢大數據集、使用Spark Streaming快速處理實時數據成為可能，顯著增加了該技術的用戶數量和潛在應用。

自推出以來，Spark的受歡迎程度越來越高，它已經成為大數據處理的事實上的標準，這在很大程度上歸功於社區成員和專注的開源貢獻者的忠實基礎。如今，許多現代數據湖架構使用Spark作為處理引擎，使數據工程師和數據科學家能夠執行ETL、優化數據並訓練機器學習模型。

數據湖的挑戰是什麼?

挑戰#1:數據可靠性

如果沒有適當的工具，數據湖可能會出現可靠性問題，這使得數據科學家和分析師很難對數據進行推理。在本節中，我們將探討數據湖上數據可靠性問題的一些根本原因。

重新處理由於管道損壞的數據

對於傳統的數據湖，需要不斷地重新處理丟失或損壞的數據可能成為一個主要問題。這種情況經常發生在某人正在向數據湖寫入數據，但由於硬件或軟件故障，寫入作業沒有完成。在這種情況下，數據工程師必須花費時間和精力刪除任何損壞的數據，檢查剩餘數據的正確性，並設置一個新的寫作業來填充數據中的任何漏洞。

三角洲湖通過使數據湖具有事務性來解決再處理問題，這意味著在數據湖上執行的每個操作都是原子的:它要麼完全成功，要麼完全失敗。沒有中間地帶，這很好，因為您的數據湖的狀態可以保持幹淨。因此，數據科學家不必因為部分寫入失敗而花費時間繁瑣地重新處理數據。相反，他們可以把時間用於在數據中尋找見解，並建立機器學習模型，以推動更好的業務成果。

數據驗證和質量執行

在考慮數據應用程序時，而不是軟件應用程序，數據驗證是至關重要的，因為沒有它，就無法衡量數據中的某些內容是否損壞或不準確，從而最終導致低可靠性。使用傳統的軟件應用程序，很容易知道什麼時候出了問題——例如，你可以看到網站上的按鈕不在正確的位置。然而，對於數據應用程序，數據質量問題很容易不被發現。邊緣情況、損壞的數據或不正確的數據類型可能會在關鍵時刻浮出水麵，破壞數據管道。更糟糕的是，像這樣的數據錯誤可能不會被發現，並扭曲您的數據，導致您做出糟糕的業務決策。

解決方案是使用數據質量強製工具，如Delta Lake的模式強製和模式進化來管理數據質量。這些工具，加上Delta Lake的ACID事務，使您能夠完全信任您的數據，即使它在整個生命周期中不斷發展和變化，並確保數據的可靠性。了解更多三角洲湖．

結合批處理和流數據

隨著實時收集的數據量不斷增加，數據湖需要能夠輕鬆捕獲流數據並將其與曆史批量數據結合起來，以便始終保持更新。傳統上，許多係統架構師已經轉向lambda體係結構來解決這個問題，但是lambda體係結構需要兩個單獨的代碼基(一個用於批處理，一個用於流處理)，並且很難構建和維護。

與三角洲湖，每個表都可以輕鬆地集成這些類型的數據，作為批處理和流源和接收器。Delta Lake能夠通過ACID事務的兩個特性來實現這一點:一致性和隔離性。這些屬性確保每個查看器都能看到一致的數據視圖，即使多個用戶同時修改表，甚至在新數據同時流入表時也是如此。

批量更新、合並和刪除

數據湖可以容納大量的數據，公司需要可靠地對這些數據執行更新、合並和刪除操作，以便始終保持最新。對於傳統的數據湖，執行這樣的簡單操作並確認它們成功發生是非常困難的，因為沒有機製來確保數據的一致性。如果沒有這樣的機製，數據科學家就很難對他們的數據進行推理。

數據湖上的更新、合並和刪除成為公司痛點的一種常見方式是與CCPA和GDPR等數據法規有關。根據這些規定，公司有義務根據客戶的要求刪除客戶的所有信息。對於傳統的數據湖，要實現這一要求有兩個挑戰。公司需要能夠:

1. 使用SQL查詢數據湖中的所有數據
2. 逐行刪除與該客戶相關的所有數據，這是傳統分析引擎所不具備的功能

三角洲湖通過允許數據分析師使用SQL輕鬆地查詢數據湖中的所有數據，解決了這個問題。然後，分析師可以執行更新，由於Delta Lake的ACID事務，使用單個命令合並或刪除數據。閱讀更多關於如何使您的數據湖CCPA符合統一的數據和分析方法。

挑戰#2:查詢性能

查詢性能是數據湖分析工具用戶滿意度的關鍵驅動因素。對於使用SQL執行交互式探索性數據分析的用戶來說，對常見查詢的快速響應是必不可少的。

數據湖可以容納數百萬個文件和表，因此對數據湖查詢引擎進行大規模性能優化非常重要。下麵將討論數據湖可能出現的一些主要性能瓶頸。

小文件

由於I/O吞吐量的限製，在數據湖中放置大量小文件(而不是為分析而優化的大文件)會大大降低性能。三角洲湖使用小文件壓縮將小文件合並為針對讀訪問進行優化的大文件。

對磁盤進行不必要的讀取

從存儲中反複訪問數據會顯著降低查詢性能。三角洲湖使用緩存選擇性地將重要的表保存在內存中，以便更快地回收它們。它還使用數據跳躍將讀吞吐量提高了15倍，以避免處理與給定查詢不相關的數據。

刪除文件

在使用雲存儲的現代數據湖上，被“刪除”的文件實際上可以在數據湖中保留長達30天，從而產生不必要的開銷，降低了查詢性能。三角洲湖提供VACUUM命令永久刪除不再需要的文件。

數據索引和分區

為了獲得適當的查詢性能，應該按照最可能分組的維度對數據湖進行適當的索引和分區。三角洲湖可以創建和維護為分析優化的索引和分區。

元數據管理

增長到幾拍字節或更多的數據湖可能成為瓶頸不是靠數據本身，而是靠伴隨數據的元數據。三角洲湖使用Spark提供可擴展的元數據管理，就像數據本身一樣分布其處理。

挑戰#3:治理

傳統上，數據湖很難得到適當的保護，並為治理需求提供足夠的支持。GDPR和CCPA等法律要求，如果客戶提出要求，公司可以刪除與客戶有關的所有數據。在常規Parquet數據湖中刪除或更新數據是計算密集型的，有時幾乎是不可能的。所有與被請求的個人數據有關的文件都必須被識別、吸收、過濾、作為新文件寫入，並刪除原始文件。這必須以一種不會破壞或破壞表上查詢的方式完成。沒有簡單的刪除數據的方法，組織受到監管機構的高度限製(經常被罰款)。

數據湖還使以合理的成本保存數據的曆史版本具有挑戰性，因為它們需要手動快照，並存儲所有這些快照。

數據湖最佳實踐

正如前一節所分享的，湖屋是一種平台架構，它使用與數據倉庫中類似的數據結構和數據管理功能，但直接在用於Beplay体育安卓版本雲數據湖的低成本、靈活的存儲上運行。對非結構化數據進行高級分析和機器學習是當今企業最重要的戰略優先事項之一，由於能夠以各種格式(結構化、非結構化、半結構化)吸收原始數據，數據湖是這種新的簡化架構的明確選擇。最終，以數據湖為中心的Lakehouse架構允許傳統分析、數據科學和機器學習在同一個係統中共存。

使用數據湖作為原始數據的基礎和著陸區

在向數據湖中添加新數據時，不要對原始數據執行任何數據轉換(個人身份信息除外，請參見下文)。數據應該以其原生格式保存，這樣就不會因聚合或以其他方式修改數據而無意中丟失信息。例如，即使清除數據中的空值，也可能不利於優秀的數據科學家，他們似乎不僅可以從數據中擠出額外的分析價值，甚至可以從缺乏數據中擠出額外的分析價值。

然而，數據工程師確實需要從包含PII(個人身份信息)的任何數據源中剝離PII(個人身份信息)，用唯一的ID替換它，然後才能將這些數據源保存到數據湖。這一過程維護了個人與其數據之間的聯係，用於分析目的，但也確保了用戶隱私，並遵守GDPR和CCPA等數據法規。由於數據湖的主要目標之一是無限期地持久化原始數據資產，因此這一步可以保留原本需要丟棄的數據。

使用基於角色和視圖的訪問控製來保護您的湖屋

傳統的基於角色的訪問控製(如AWS上的IAM角色和Azure上的基於角色的訪問控製)為管理數據湖安全提供了一個很好的起點，但它們對許多應用程序來說不夠細粒度。相比之下，基於視圖的訪問控製允許使用SQL視圖將權限邊界精確分割到單個列、行或筆記本單元格級別。SQL是實現這種模型的最簡單的方法，因為它的普遍性和基於條件和謂詞進行過濾的簡單能力。

基於視圖的訪問控製可在現代統一數據平台上使用，並且可以通過憑據傳遞與雲本地基於角色的控製集成，從而無需移交敏感的雲提供商憑據。Beplay体育安卓版本設置完成後，管理員可以開始將用戶映射到基於角色的權限，然後加入經過微調的基於視圖的權限，根據每個用戶的特定情況擴展或收縮權限集。您應該定期檢查訪問控製權限，以確保它們不會過時。

通過使用Delta Lake將可靠性和ACID事務構建到您的Lake house中

直到最近，ACID事務還不能在數據湖上實現。然而，隨著開源的Delta Lake的引入，它們現在可以使用，為數據湖帶來了數據倉庫的可靠性和一致性。

ACID屬性(原子性、一致性、隔離性和持久性)是數據庫事務的屬性，通常在傳統的關係數據庫管理係統(rdbms)中可以找到。它們對於數據庫、數據倉庫和數據湖都是可取的，因為它們通過防止前麵提到的一些數據汙染來源來確保數據的可靠性、完整性和可信賴性。

Delta Lake構建在開源Parquet(已經是一種高性能文件格式)的速度和可靠性基礎上，添加了事務保證、可擴展元數據處理以及批處理和流處理統一。它還100%兼容Apache Spark API，因此它可以與Spark統一分析引擎無縫工作。與Michael Armbrust一起了解更多關於Delta Lake的信息網絡研討會題為Delta Lake:數據湖的開源可靠性，或者看看三角洲湖的快速入門指南在這裏。

將你湖屋中的數據分類

為了實現成功的湖屋策略，重要的是用戶在新數據進入數據湖時正確地對其進行分類，並不斷地對其進行管理，以確保其保持更新。數據目錄是一個有組織的、全麵的表元數據存儲，包括表和列描述、模式、數據沿襲信息等等。它是下遊消費者(例如BI和數據分析師)發現哪些數據可用、它意味著什麼以及如何使用它的主要方式。它應該在中央平台或共享存儲庫中供用戶使用。Beplay体育安卓版本

在輸入數據時，數據管理員應該鼓勵(或者可能要求)用戶用關於新數據源或表的信息(包括業務單元、項目、所有者、數據質量級別等等)“標記”它們，以便對它們進行排序和輕鬆發現。在理想的情況下，這種注釋精神會發展成為全公司的承諾，即仔細標記新數據。至少，數據管理員可以要求對數據湖的任何新提交進行注釋，並且隨著時間的推移，希望培養一種協作管理的文化，在這種文化中，對數據進行標記和分類成為一種共同的義務。beplay娱乐ios

有許多軟件可以使數據編目更容易。主要的雲提供商提供他們自己的雲服務專有數據目錄軟件產品，即Azure數據目錄和AWS Glue。除此之外，Apache Atlas還可以作為開源軟件使用，其他選擇包括Alation、Collibra和Informatica等公司的產品。

先從湖邊小屋開始

現在你了解了建造一個湖屋的價值和重要性，下一步是建立你的湖屋的基礎三角洲湖．查看我們的網站了解更多信息或免費試用Databricks．