數據湖架構、戰略和分析的 8 大錯誤認知

翻譯：張玲

校對：丁楠雅

本文打破有關數據湖的 8 個錯誤認知，錯誤認知包括 3 方面，還提出了 5 個小技巧，以構建一個靈活的、可交付業務價值的數據湖。

本文的目的是構建數據湖，並提供適應企業數據策略的背景信息。諮詢公司和提供商提出的意見相互矛盾，因此，這些信息歷來一直不透明，令人困惑。

不幸的是，這些令人困惑和頗具誤導性的建議導致人們不斷就技術平臺的背景信息發問，而不是就一個戰略或者業務成果來發問。這種技術驅動的決策過程試圖使主觀的討論變得更加客觀，例如，他們會追問什麼是亞馬遜數據湖？或者什麼是最好的數據湖軟件。也許有一個供應商急於求成，正在醫療領域裏推廣符合流行語的、兼容 HIPPA 的數據湖。所以，對於那些想要釐清數據湖如何賦能數據洞察的人來說，這些關於數據湖的討論令人更加困惑。

打破這些與數據湖策略、架構和實現建議相關的錯誤認知，將有助於你理解數據湖失敗的原因及其實現面臨的各種挑戰，還有助於闡明供應商和諮詢公司提供的建議可能與數據湖最佳實踐背道而馳的原因。

讓我們開始一一打破這些錯誤認知吧！

**錯誤認知 1：**數據湖與數據倉庫，必須二選一

人們普遍建議在數據湖和數據倉庫之間二選一，但這是錯誤的。

審視現實 - 數據倉庫和數據湖之間的區別

這種必須在數據湖和數據倉庫之間二選一的認知錯誤地限制了討論的框架。當人們通過詢問數據倉庫是否過時來開啓討論時，似乎在告知是時候拋棄你的企業級數據倉庫。這些問題的出發點都有誤，而且正在引你誤入歧途。

通常，一家公司需要就某一特定的設計模式進行某種形式的技術投資時，就會引發這些問題的討論。例如，他們聲稱某些操作可以或必須發生在數據倉庫中，然後將這些操作定義爲是採用數據湖架構的限制和風險。

那供應商推廣的數據湖架構限制示例是什麼？

供應商會說數據湖無法像數據倉庫那樣便於按需擴展計算資源，從而它是受限的。這是真的，但具有誤導性。就這就像抱怨湯姆布拉迪肯定是一名可怕的運動員，因爲他從未在職業橄欖球生涯中打過本壘打。既然湯姆布拉迪是一名橄欖球運動員，你會期望他成爲一名在芬威棒球場（好吧，也叫 Pesky'pole）投球飛過左外野全壘打牆的全壘打投球手嗎？不。

那麼，爲什麼供應商和諮詢公司會在這裏應用數據倉庫計算概念？

事實上，聲稱數據湖沒有計算資源是一種 FUD 行銷手法（灌輸數據湖的負面觀念，在你的頭腦裏注入疑惑和恐懼，使你誤以爲除了數據倉庫以外，別無選擇）。數據湖無法按需擴展計算資源，是因爲沒有需要擴展的計算資源。

在數據湖體系結構中，計算資源分離是一種核心的抽象，這是 Redshift Spectrum、Presto 和 Athena 解決方案存在的原因。以 Amazon 的 Athena 爲例，Athena 不是一個數據倉庫軟件，而是一個基於開源 FaceBook Presto 開發的按需查詢引擎，它將按需提供 “計算” 資源查詢數據作爲一項服務來提供。Amazon 的 Redshift Spectrum 和 Athena 一樣可以查詢數據湖中的數據，利用的是從一個 Redshift 集羣中分離出來的計算資源。

根據設計，數據湖中的查詢數據服務可以很好地抽象出這個引擎模型，而且無論你在 Google 雲上是否有亞馬遜數據湖（AWS 數據湖）、Oracle 數據湖、Azure 數據湖或 BigQuery 數據湖，模型都是類似的。可以通過 Athena 這類的查詢引擎或者像 Redshift、 BigQuery、Snowflake 等 “倉庫” 來查詢數據湖數據內容，這些服務提供計算資源，而不是提供一個數據湖。

所以，對於大多數企業來說，數據湖和數據倉庫如何共存纔是正確的討論內容，而不是討論如何二選一。當有人向你提出只能二選一時，他們可能是利益相關方，也就是說他們的產品或者商業夥伴也提供相關的功能。

**錯誤認知 2：**數據倉庫就是一個數據湖

這種想法會誘使你放棄數據湖，將所有數據都扔進數倉中。

審視現實 - 定義有效的數據湖

的確，有一些供應商和諮詢公司主張將數倉作爲數據湖模型。

不同的供應商和諮詢公司會建議使用模式（或其他物理或邏輯結構）來表示數據從 “原始” 到數倉中其他狀態的生命週期，業務所需的任何成熟度數據都可以在倉庫範圍內完成。

傳統上，數倉旨在反映企業已經完成的事務，也反映企業完成一系列的一致事務，例如一個已經完成的事務可能提供有關收入、訂單、“最佳客戶” 和其他領域的重要事務。

但是，在數倉 “導入所有數據” 模型中，數倉包含所有的數據內容，其中會包括暫時的和易失的原始數據。

將所有的原始數據重新打包到數倉中的操作更像是操作型數據庫（Operational Data Store，ODS）或者數據集市的操作，而不像是數倉的操作。你能將所有的數據都扔進數倉嗎？不能。不能僅僅因爲你可以在技術上做一些事情，就可以使它成爲正確的體系結構。

將所有數據放進倉庫的建議說，事務數據只是邏輯組織數據的一個功能。在企業內部定義和推廣這個邏輯定義的人將無法得到理解，甚至更糟的是他將被忽視，原因是這種方式幾乎就是一種發生在數倉中的 “數據沼澤”，儘管教科書上定義數據沼澤發生在數據湖中。對於任何一個被迫善後處理的人來說，這都是一場數據處理的噩夢。

這個模型會將你限制在數倉技術及其模型中，同時還需要你將所有數據都導入數倉。如果你喜歡四處尋找供應商、設定各種人爲限制、降低數據認知能力和揹負各種技術債務，那麼這種方法肯定很適合你。

正確的做法是，數據湖可以最小化技術債務，同時還可以加速企業團隊對數據的消耗。考慮到數倉、查詢引起和數據分析市場的變化在加快，你戰略的核心應該是最小化風險和技術債務。

數據湖架構

**錯誤認知 3：**數據湖只能用 Hadoop 來實現

你會經常發現有討論和示例將數據湖等同於 Hadoop 或者 Hadoop 相關供應商技術棧，這會給人一種錯覺：數據湖和 Hadoop 特定的技術緊密相關。

審視現實 - Hadoop 不是一個數據湖

雖然 Hadoop 技術可以用於數據湖的構建和運行，但它們並不能反映出所支持的數據湖的基本戰略和架構。

認識到數據湖最先反映的是戰略和架構，而不是技術，這一點很重要。Pentaho 聯合創始人兼首席技術官詹姆斯 · 狄克遜（也就是創造 “數據湖” 這個詞的人）說：

這種情況和傳統的商業智能分析程序構建方式類似，根據終端用戶給出的數據問題清單，從數據流中篩選出與問題相關的字段屬性，並批量記載到數據集市中。在你提出新問題之前，這個方法是可行的。數據湖可以完全解決這個問題，你可以將所有數據存儲在數據湖中，填充數據集市和數據倉庫以滿足傳統的數據需求，針對新問題，則可以啓用數據湖中的原始數據以供即席查詢和生成報告。

Hadoop 和其它技術一樣，可以支持戰略和架構的實現。如果現在你有一個數據湖，會有很多非 Hadoop 的選擇，即使這些選擇使用了 Hadoop 相關技術。例如，你的數據湖需要同時支持 Snowflake 這樣的數倉解決方案和在 AWS Athena、Presto,、Redshift Spectrum 和 BigQuery 這樣的就地查詢方式。

別以爲數據湖只能使用 Hadoop 實現，如果你遵循一個精心抽象的數據湖架構，那麼就可以根據技術的發展性及其對更廣泛的企業生態系統的支持度選擇其它技術，從而最小化風險。

**錯誤認知 4：**數據湖僅用於 “存儲” 數據

在這種情況下，數據湖只是一個存儲你所有數據的地方。你只需要所有數據放入數據湖，而後啓用新的數據管理模型就可以大功造成，這就和將所有的文件都放進筆記本電腦上超大硬盤中的 “無標題文件夾” 一樣。

審視現實 - 數據湖不僅僅是一個存放數據的地方

我們有一位客戶使用數據湖對數十個網站和第三方酒店的標籤進行質量控制分析，這有助於識別負責這項工作的不同團隊可能存在的差異和執行錯誤。還有一位客戶在將數據導入企業級數據倉庫前，使用數據湖過濾來自不同部門、第三方和合作夥伴系統中的不準確訂單或重複的多渠道訂單。

這兩個例子都強調了，數據湖在保證下游事務數據的準確性和合規性上發揮了積極的作用。

正如麥肯錫員工所說：“... 數據湖不僅保證了技術棧的靈活性，而且還保證了業務能力的靈活性。” 數據湖作爲一種服務模型，是爲了交付業務價值，而不僅僅是存儲數據。

**錯誤認知 5：**數據湖僅存儲 “原始” 數據

和錯誤認知 2 相關，“把所有數據都倒進數倉” 的方法表示，數據湖不會增加價值，原因是隻有原始數據駐留在數據湖中。他們主張：“如果數據湖只處理原始數據，那麼就不用擔心數據湖了，只需將所有的原始數據或者已被處理的數據轉存至數倉中”。

審視現實 -- 定義有效的數據湖策略和架構

數倉或 SQL 查詢引擎的典型工作流

正如之前所說的，這和數倉旨在反映既定事務數據的基本前提相矛盾。一個更好的歷史數據比較不是在數倉和數據湖之間進行，而是在 ODS 和數據湖之間進行。

從歷史數據角度上看，數據湖是一個 ODS，而不是一個數倉，因爲數據湖從上游獲取粗糙和不穩定的原始數據。一個 ODS 數據通常時間範圍很窄，可能只有 90 天內的數據，針對某一特定數據領域，時間範圍可能更窄。另一方面，數據湖對於保留的數據沒有時間範圍限制，從而時間範圍更廣些。

那麼，數據湖僅是爲了存儲 “原始” 數據嗎？

不。

根據設計，數據湖應該有一定程度的數據輸入管理（即管理什麼數據要進入數據湖）。如果你沒有管理數據進入模式的意識，那麼你其它地方的技術棧可能存在問題，這對於數倉或任何其它數據系統也是一樣的，垃圾進，垃圾出。

數據湖的最佳實踐應該包括一個配備初始數據池的模型，在這個初始數據池裏，你可以最低限度地優化模型，以爲下游處理數據或輔助處理數據。數據處理可能發生在 Tableau 或 PowerBi 之類的分析工具中，也有可能發生在加載數據到數倉（如 Snowflake、Redshift 和 BigQuery）的應用程序中。

與我們合作的一位客戶將 Adobe 事件數據發送到 AWS，以支持企業 Oracle 雲環境。爲什麼要從 AWS 到 Oracle 呢？因爲這是 Oracle BI 環境中最高效的和最具成本效益的數據處理模式，尤其是考慮到使用 AWS 數據湖和 Athena 作爲按需查詢服務的靈活性和經濟性。

通過最大限度地保證數據的有效性，提高處理數據的效率，你可以最大限度地降低下游數據處理者所要付出的數據處理成本。

**錯誤認知 6：**數據湖僅適用於 “大” 數據

如果你花時間閱讀過數據湖的相關資料，你會認爲數據湖只有一種類型，看起來像裏海（它是一個湖，儘管名字中有 “海”）。人們將數據湖描述成一個龐大的、包容一切的實體，旨在保存所有的知識，因此只會有一個企業大數據湖或者大數據架構的同義詞。

審視現實 - 數據湖有各種形狀和大小

不幸的是，“大數據” 角度給人以一種錯覺：數據湖僅適用於裏海範圍那麼大的數據，這當然會讓數據胡的概念令人生畏。因此，用如此量大的術語來描述數據湖會使那些本可以從中獲益的人無法接近。

另一個觀點是數據湖和大數據只能二選一。像自然界中的湖泊一樣，數據湖有各種不同的形狀和大小。每一種數據湖都有一種自然狀態，通常反映數據的生態系統，就像自然界中反映魚、鳥或其它有機體的生態系統一樣。

以下是一些例子：

通過設計，所有數據湖類型都應該採用一種抽象，以最大限度地降低風險，並提供更大的靈活性。此外，它們的結構應該便於數據處理，獨立於數據規模的大小。當數據科學家、業務用戶或者 python 代碼使用數據湖時，確保它們擁有一個易於處理數據和可自定義數據規模的數據環境。

數據湖示例

無論你的使用場景是機器學習、數據可視化、生成報告還是爲數倉和數據集市輸送數據，數據規模的不同，思考方式不同，有可能創造出使用這些數據湖的新方式。

**錯誤認知 7：**數據湖沒有安全保障

數據湖是一個不安全的數據對象集合，可供組織中的任何人使用，而這些人只是想從中獲得一些幫助，帶着他們想要的信息離開。

審視現實 - 安全是一種選擇，確保你考慮的是它

從某種意義上說，人們會依賴於隱性的安全技術解決方案（即自動的 AWS S3 AES 對象加密），而不會去構建一個顯性的、可以管理安全性的架構和下游使用場景，這可能會導致安全漏洞，但這可以說是很多系統的漏洞，而非僅是數據湖本身的漏洞。因此，認爲數據湖本質上不安全的觀點是不準確的。

安全可以是而且應該是我們要考慮的重中之重，這裏有 4 個需要考慮的方面：

人們可以爭論這些不同策略的優點，但要是說數據湖本身是不安全的，這是不正確的。

**錯誤認知 8：**數據湖會變成數據沼澤

曾有一篇文章評論數據湖最終會變成數據沼澤，因爲它們只是存儲，缺乏治理、管理，沒有數據生命週期 / 保留策略，也沒有元數據。

審視現實 - 正確安排人員、流程和技術

在極端情況下，這是真的。如果你把一個數據湖當作是你筆記本電腦上一個通用的 “無標題文件夾” 來處理文件，那麼就可能會變成一個數據沼澤（見錯誤認知 4）, 所以，這會存在風險。然而，對於任何習慣以這種方式進行文件轉儲的人來說，他們對成功安排人員、流程和技術都有點不感興趣。

那麼，真正的數據沼澤是什麼呢？真正的數據沼澤是設計不當創造出來的，而不是疏於管理促成的。

數據湖更大的威脅不是缺乏治理、管理、生命週期策略和元數據，而是缺乏防止這種情況發生的生態系統，這個生態系統包括工具、角色、職責和系統。數據湖之所以成爲沼澤，不僅僅是因爲 “傾倒文件”，還因爲數據湖的相關人員、流程和技術安排過於複雜。如果你認爲你的企業級數倉過程緩慢，那麼你的數據湖也會如此。

簡單、敏捷和靈活是數據湖衆多優點中的一部分，當湖中出現重要的業務邏輯和流程時，你將面臨這樣的風險：創建出來的解決方案缺乏簡單性、無法響應變化、設計過於嚴格，而這就是你需要警惕的數據沼澤。數據沼澤是昂貴的、費時的，從而無法滿足任何人的期望。這聽起來是不是很熟悉？

對於那些正在計劃或者已經部署了數據湖的人來說，要小心數據湖的定位和特性蔓延。經常會看到供應商將其在傳統數倉和其它 ETL 產品中發現的特性和功能定義爲數據湖的功能，儘管從技術上講，可以在數據湖中進行復雜的數據處理。

但是，你可能在數據湖外已經有了執行這些處理操作的工作流、工具、人員和技術，並不是所有的數據處理都符合你的上下游流程，請仔細考慮數據湖嵌套處理數據導致複雜性激增的風險。

請警惕，當前或計劃中的數據湖逐漸看起來更像是傳統的 ETL 工具和數倉的合體，如果你已經經歷過一個過於複雜的構建企業級數倉工作，會很容易發現這一點。

數據驅動企業的數據湖架構及策略

數據湖的發展模式和我們熟知的技術發展模式一樣，新的概念出現，接着被先驅者和技術江湖騙子採用，隨着時間的推移，成功模式才變得清晰。這種清晰源自努力實踐的經驗教訓，很大程度上是通過失敗來獲得成功。

結果，數據湖的技術術語、最佳實踐和致力於構建更好平臺的投資都在改進。業務實踐的經濟性、架構方式和優化方法都在不斷變化，這允許團隊以適應應用場景的方法將這些數據湖解決方案整合進企業的數據棧中。

不幸的是，這些批評逐漸變成廣爲流傳的 “數據湖不成功”、“數據湖等同於數據沼澤”、“數據湖與 Hadoop 等特定技術過於緊密聯繫” 等這類信息。最後，還會出現 “什麼是數據湖” 定義過於模糊和不固定的抱怨。

批評是任何技術發展的必要組成部分。

然而，技術發展的關鍵是以退爲進，這樣做，是因爲這些批評並非僅針對數據湖。事實上，這些評論可以針對任何一項技術，特別是數據項目。例如，術語 “數據倉庫” 和數據湖定義一樣模糊而不斷變化（見錯誤認知 2），在谷歌上搜索 “失敗的數據倉庫”，也會發現一些關於項目失敗的故事。這些是否意味着我們應該放棄“數據倉庫” 這個短語或者停止追求這些項目？

不。

通常情況下，蔑視數據湖的諮詢公司或企業都將自己提供的產品和服務視爲靈丹妙藥，致力於實現自己的願景和最佳實踐。如果一個諮詢公司或供應商不相信一個模型，爲什麼要他們參與一個他們不相信的解決方案呢？將數據湖工作委託給這類諮詢公司或供應商，很有可能是數據湖失敗的一個原因。

在深入瞭解如何構建數據湖或如何和企業定製數據湖之前，我們有一些技巧可以幫助你進行規劃。

**開始：**從小處做起，要靈活

到目前爲止，我們已經討論了什麼是數據湖或者構建數據湖的步驟是什麼的基本問題。我們還忽視了一個重要事實：數據湖和數倉不僅可以共生，也可以共繁榮。

因此，停止購買閃亮的 Hortonworks 數據湖解決方案，組建軟件開發工程師、客戶經理、解決方案架構和支持技術工程師來構建企業數據湖吧！

從小處做起，要靈活。下面是一些關於如何運轉數據湖實現的小技巧：

作爲一個成功的數據湖早期採用者，應該重點關注商業價值方法而不是具體實現的技術方法，這意味着你不必擔心 Cloudera Data Lake 新出了產品、如何開啓 AWS Lake Formation 工作流、Gartner 魔方圖或是 Azure 團隊希望你購買哪些數據湖分析方案。

數據湖專注於業務價值，爲你提供了一個在全面數據分析的背景下搭建工作框架的機會，這會提高你實現數據湖目標和衡量業務績效的速度。

使用無代碼、全自動和零管理的 Amazon Redshift Spectrum 或 Amazon Athena Services 來啓動你的工作。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/COMZ5tdUCb68-eg3HrULgg

猜你喜歡