精心設計的數據湖建築的商業案例

 

讓咱們從數據湖的標準定義開始：

數據湖是一個存儲庫，它以原生格式保存大量原始數據，包括結構化，半結構化和非結構化數據。 在須要數據以前，不會定義數據結構和要求。

你爲何要關心？

革新

在大型企業中，數據湖最強大的影響多是創新的實現 。 咱們已經看到許多數十億美圓的組織正在努力創建數據驅動的洞察力和創新文化。 它們被孤立於部門或分區劃分的數據存儲的結構孤島所困擾，而且這些結構孤立於圍繞數據全部者的大規模組織政治。 企業數據湖雖然遠非微不足道，但它提供了從根本上清除企業級數據訪問問題的必要基礎。 之前沒法進行探索性分析和數據挖掘的大門打開了，實現了全新的可能性。

速度

在當今動態的業務環境中，新的數據消費需求和用例很是迅速地出現。 在準備需求文檔以反映對數據存儲或模式的請求更改時，用戶常常轉向不一樣甚至相互矛盾的模式更改集。 相比之下，數據湖的整個理念圍繞着爲未知用例作好準備。 當源數據位於一箇中心湖中時，其中沒有嵌入單一控制結構或模式，支持新的附加用例能夠更加簡單。

自助服務

對報表的IT請求與最終在組織中發佈健壯的工做報表之間的平均時間是多少？ 在太多的狀況下，答案是在幾周甚至幾個月內測量的。 經過設計合理的數據湖和訓練有素的商業社區，人們能夠真正實現自助式商業智能。 容許業務人員訪問他們須要的全部數據，讓他們使用各類工具開發他們想要的報表。 IT成爲雲上基礎架構和數據的保管人，而業務則負責探索和挖掘雲。

圖1：Data Lake存儲層

設計物理存儲

任何數據湖設計和實現的基礎都是物理存儲。 核心存儲層用於主要數據資產。 一般，它將包含原始和/或輕度處理的數據。 評估基於雲的數據湖存儲技術時的關鍵考慮因素是如下原則和要求：

出色的可擴展性

因爲企業數據湖一般旨在成爲整個部門或整個公司的集中式數據存儲，所以它必須可以進行大規模擴展，而不會遇到固定的任意容量限制。

高耐用性

做爲關鍵企業數據的主要存儲庫，核心存儲層的高耐用性可實現出色的數據穩健性，而無需採用極高的可用性設計。

支持非結構化，半結構化和結構化數據

數據湖的主要設計考慮因素之一是可以將全部類型的數據存儲在單個存儲庫中。

獨立於固定架構

只有在底層核心存儲層沒有規定固定模式時，才能根據每一個消費目的的須要在讀取時應用模式。

與計算資源分離

與Hadoop上的「遺留」大數據存儲相比，基於雲的數據湖最重要的哲學和實踐優點是可以將存儲與計算分離，從而實現每一個存儲的獨立擴展。

鑑於這些要求，基於對象的商店已成爲核心數據湖存儲的事實上的選擇。 AWS，Google和Azure都提供對象存儲技術。核心存儲的重點是集中全部類型的數據，幾乎沒有強加於它的模式結構。 可是，數據湖一般在覈心存儲之上具備額外的「層」。 這容許保留原始數據本質上是不可變的，而附加層一般會添加一些結構，以便有助於有效的數據消耗，例如報告和分析。 圖1表示在原始存儲層頂部添加的附加層。

這個的一個具體例子是添加由Hive Metastore定義的層。 在諸如此類的層中，對象存儲器中的文件被劃分爲「目錄」，而且由Hive聚類的文件被安排在其中以加強圖2中所示的訪問模式。

關於這個例子，能夠寫得更多; 能夠說，能夠根據所需的消費模式實施許多附加的分層方法。

圖2：使用Hive羣集的分區對象存儲

選擇文件格式

介紹

來自傳統RDBMS世界的人們經常對咱們做爲數據湖的架構師對於如何存儲數據的超常控制感到驚訝。 與RDBMS存儲引擎相反，咱們能夠肯定一系列元素，例如文件大小，存儲類型（行與列），壓縮程度，索引，模式和塊大小。 這些與面向Hadoop的工具生態系統有關，這些工具一般用於訪問湖中的數據。

文件大小

一個小文件是一個明顯小於Hadoop文件系統（HDFS）默認塊大小的文件，即128 MB。 若是咱們存儲小文件，考慮到數據湖的大量數據，咱們最終會獲得大量文件。根據經驗，每一個文件都表示爲羣集名稱節點內存中的一個對象，每一個文件佔用150個字節。 所以，每一個使用一個塊的1億個文件將使用大約30千兆字節的內存。 須要注意的是，Hadoop生態系統工具並未針對有效訪問小文件進行優化。 它們主要用於大文件，一般是塊大小的偶數倍。

Apache ORC

ORC是爲Hadoop工做負載設計的突出的列式文件格式。 經過列式文件格式化，能夠只讀取，解壓縮和處理當前查詢所需的值。 雖然有多種可用的列式格式，但許多大型Hadoop用戶都採用了ORC。 例如，Facebook使用ORC在其數據倉庫中節省數十PB。他們還證實了ORC明顯快於RC File或Parquet。 雅虎還使​​用ORC存儲他們的生產數據，並一樣發佈了一些基準測試結果。

相同數據，多種格式

極可能一種類型的存儲結構和文件格式針對特定工做負載進行了優化，但不太適合另外一種工做負載。 在這樣的狀況下，鑑於存儲成本低，實際上很是適合使用不一樣的底層存儲結構（分區，文件夾）和文件格式（例如ORC vs Parquet）建立相同數據集的多個副本。 

設計安全

與每一個基於雲的部署同樣，企業數據湖的安全性是關鍵優先事項，必須從一開始就設計好。 此外，只有在企業的總體安全基礎架構和控制框架內部署和管理數據湖的安全性，才能取得成功。 從廣義上講，有三個與數據湖部署相關的主要安全域：

• 加密
• 網絡級安全性
• 訪問控制

加密

實際上，每一個企業級組織都要求對存儲數據進行加密，若是不是廣泛的話，至少對於除公開數據以外的大多數數據分類。 默認狀況下，全部領先的雲提供商都支持對其主要對象存儲技術（例如AWS S3）進行加密。 一樣，用於其餘存儲層的技術（例如用於消費的衍生數據存儲）一般也提供加密。

加密密鑰管理也是一個重要的考慮因素，其要求一般由企業的總體安全控制決定。 選項包括由雲提供商建立和管理的密鑰，由雲提供商管理的客戶生成密鑰，以及由內部客戶徹底建立和管理的密鑰。

最後的相關考慮因素是加密傳輸。 這包括在設備和服務之間經過網絡傳輸的數據。 在大多數狀況下，可使用每一個服務的內置選項或使用帶有相關證書的標準TLS / SSL輕鬆配置。

網絡級安全性

另外一個重要的安全層位於網絡級別。 諸如安全組之類的雲原生構造以及包括網絡ACL和CIDR塊限制在內的傳統方法都在實施強大的「縱深防護」戰略中發揮做用，經過阻擋大量不適當的訪問路徑。網絡層面。 此實現還應與企業的總體安全框架保持一致。

訪問控制

這側重於身份驗證（你是誰？）和受權（你能夠作什麼？）。 事實上，每一個企業都將擁有標準的身份驗證和用戶目錄技術; 例如，Active Directory。 每一個領先的雲提供商都支持將企業身份基礎架構映射到雲提供商的資源和服務的權限基礎架構的方法。 雖然涉及的管道可能很複雜，可是與雲提供商的訪問管理基礎架構（例如AWS上的IAM）相關聯的角色可由通過身份驗證的用戶使用，從而實現對受權操做的細粒度權限控制。 對於在雲中運行的第三方產品（例如報告和BI工具），一般也是如此。 一般支持LDAP和/或Active Directory進行身份驗證，而且工具的內部受權和角色能夠與通過身份驗證的用戶身份相關聯並由其驅動。

創建治理

一般，數據治理是指對企業中使用的數據的可用性，可用性，完整性和安全性的總體管理。 它依賴於業務策略和技術實踐。 與任何雲部署的其餘描述方面相似，企業數據湖的數據治理須要由整個組織的整體實踐和策略驅動並與之一致。

在傳統的數據倉庫基礎架構中，對數據庫內容的控制一般與業務數據保持一致，並按業務單位或系統功能分爲孤島。 可是，爲了得到集中組織數據的好處，它相應地須要集中查看數據治理。

即便企業的數據治理實踐還不徹底成熟，至少要實施一套最小控制措施相當重要，這樣在沒有定義重要元數據（「數據數據」）的狀況下，數據沒法進入湖泊和捕獲。 雖然這部分取決於早期「設計物理存儲」部分中描述的元數據基礎架構的技術實現，但數據治理還意味着業務流程肯定了所需的關鍵元數據。 一樣，與完整性，準確性，一致性和標準化等概念相關的數據質量要求實質上是必須首先制定的業務政策決策，而後纔將這些決策的結果烘焙到實際執行這些要求的技術系統和流程中。

用於在數據湖實施中實施數據治理策略的技術一般不是單獨的產品或服務。 更好的方法是指望將遵照數據治理要求的須要嵌入到整個數據湖基礎架構和工具中。

啓用元數據編目和搜索

主要考慮因素

任何數據湖泊設計都應該包含元數據存儲策略，以使業務用戶可以搜索，定位和了解湖中可用的數據集。 傳統數據倉庫在關係存儲層中存儲固定和靜態的一組有意義的數據定義和特徵，而數據湖存儲旨在靈活地支持在讀取時應用模式。 可是，這意味着須要一個單獨的存儲層來存放表明技術和業務含義的編目元數據。 雖然組織有時只是在沒有元數據層的數據湖中累積內容，但這確定會建立一個難以管理的數據沼澤，而不是一個有用的數據湖。 有許多方法和解決方案可確保建立和維護適當的元數據。 如下是一些要記住的重要原則和模式。

實施元數據要求

確保建立適當元數據的最佳方法是強制建立。 確保數據到達核心數據湖層的全部方法都強制執行元數據建立要求，而且任何新的數據提取例程都必須指定如何強制執行元數據建立要求。

自動化元數據建立

與雲中的幾乎全部內容同樣，自動化是一致性和準確性的關鍵。 儘量設計從源材料中提取的自動元數據建立。

優先考慮雲原生解決方案

儘量使用雲原生自動化框架來捕獲，存儲和訪問數據湖中的元數據。 圖3中列出了一般爲數據源編目的核心屬性。

圖3：用於Data Lake元數據存儲的AWS建議架構

基於AWS的解決方案理念

AWS建議使用簡單解決方案的示例，其中包括在S3上建立數據對象時觸發AWS Lambda函數，並將數據屬性存儲到DynamoDB數據庫中。 生成的基於DynamoDB的數據目錄能夠由Elasticsearch編制索引，容許業務用戶執行全文搜索。

AWS Glue提供了一組自動化工具來支持數據源編目功能。 AWS Glue可使用針對許多經常使用源格式和數據類型的預構建分類器來抓取數據源並構建數據目錄，包括JSON，CSV，Parquet等。 所以，這爲企業實施提供了潛在的但願。

咱們建議客戶將數據編目做爲數據湖實施的核心要求。 

圖4：數據湖層和消費模式

進入並挖掘湖泊

Schema on Read

'架構上的架構'是在數據存儲在「結構化」關係數據庫以前，通過仔細檢查的模式，用於清理，轉換和添加邏輯架構。 可是，如前所述，數據湖創建在徹底不一樣的「讀取模式」模式上，可防止主數據存儲被鎖定到預約模式中。 數據以原始或僅溫和處理的格式存儲，而且每一個分析工具能夠在數據集上施加適合於分析上下文的業務含義。 這種方法有許多好處，包括使各類工具可以出於各類目的訪問數據。

數據處理

在湖中擁有不可變數據的原始層後，您將須要建立多層處理數據以在組織中啓用各類用例。 這些是前面描述的結構化存儲的示例。 建立這些結構化數據存儲所需的典型操做包括：

• 組合不一樣的數據集
• 非規範化
• 清潔，重複數據刪除，持有房屋
• 導出計算數據字段

Apache Spark已成爲處理原始數據層以建立各類增值結構化數據層的首選工具。

數據倉庫

對於某些特殊用例（想一想高性能數據倉庫），您可能須要對數PB的數據運行SQL查詢並不是常快速地返回複雜的分析結果。 在這些狀況下，您可能須要將湖中的部分數據攝取到列存儲平臺中。 完成此任務的工具示例包括Google BigQuery，Amazon Redshift或Azure SQL數據倉庫。

交互式查詢和報告

仍有大量用例須要支持常規SQL查詢工具來分析這些海量數據存儲。 Apache Hive ，Apache Presto，Amazon Athena和Impala都是專門開發的，經過在原始數據之上建立或使用SQL友好模式來支持這些用例。

數據探索和機器學習

最後，做爲數據湖最大受益者的一類用戶是您的數據科學家，他們如今能夠訪問企業範圍的數據，不受各類模式的限制，而後能夠探索和挖掘數據以得到高價值商業看法。 許多數據科學家工具要麼基於Hadoop，要麼能夠與基於Hadoop的平臺一塊兒工做，這些平臺能夠訪問數據湖。

結論

在設計和構建良好時，數據湖能夠消除數據孤島，並開啓靈活的企業級探索和結果挖掘。 數據湖是收集企業大數據做爲核心資產，從數據中提取基於模型的洞察力以及培養數據驅動決策文化所需的最重要元素之一。