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

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

亞馬遜數據湖：

https://mp.weixin.qq.com/cgi-bin/appmsg?t=media/appmsg_edit&action=edit&type=10&isMul=1&isNew=1&lang=zh_CN&token=1763595143&token=1763595143&lang=zh_CN#data-lakes

兼容HIPPA的數據湖：

https://aws.amazon.com/lake-formation/

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

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

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

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

審視現(xiàn)實-數據倉庫和數據湖之間的區(qū)別

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

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

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

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

Pesky'pole：https://www.youtube.com/watch?v=ZdiCbHh5U7w

那么，為什么供應商和咨詢公司會在這里應用數據倉庫計算概念?

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

FUD行銷手法：

https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

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

Redshift Spectrum

https://mp.weixin.qq.com/cgi-bin/appmsg?t=media/appmsg_edit&action=edit&type=10&appmsgid=100013110&isMul=1&token=698435870&lang=zh_CN#aws-redshift-spectrum

Presto

https://mp.weixin.qq.com/cgi-bin/appmsg?t=media/appmsg_edit&action=edit&type=10&appmsgid=100013110&isMul=1&token=698435870&lang=zh_CN#aws-data-lake

Athena

https://blog.openbridge.com/aws-athena-automated-60-second-setup-zero-administration-and-automatic-optimization-eba474e9897a

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

Redshift

https://mp.weixin.qq.com/cgi-bin/appmsg?t=media/appmsg_edit&action=edit&type=10&appmsgid=100013110&isMul=1&token=698435870&lang=zh_CN#aws-redshift

BigQuery

https://mp.weixin.qq.com/cgi-bin/appmsg?t=media/appmsg_edit&action=edit&type=10&appmsgid=100013110&isMul=1&token=698435870&lang=zh_CN#bigquery

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

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

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

審視現(xiàn)實-定義有效的數據湖

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

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

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

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

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

操作型數據庫：

https://en.wikipedia.org/wiki/Operational_data_store

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

數據處理：

https://mp.weixin.qq.com/cgi-bin/appmsg?t=media/appmsg_edit&action=edit&type=10&appmsgid=100013110&isMul=1&token=698435870&lang=zh_CN#data-wrangler-data-munging

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

技術債務：

https://en.wikipedia.org/wiki/Technical_debt

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

 

 

數據湖架構

錯誤認知3： 數據湖只能用Hadoop來實現(xiàn)

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

審視現(xiàn)實-Hadoop不是一個數據湖

雖然Hadoop技術可以用于數據湖的構建和運行，但它們并不能反映出所支持的數據湖的基本戰(zhàn)略和架構。

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

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

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

AWS Athena

https://mp.weixin.qq.com/cgi-bin/appmsg?t=media/appmsg_edit&action=edit&type=10&appmsgid=100013110&isMul=1&token=698435870&lang=zh_CN#aws-athena

Redshift Spectrum

https://mp.weixin.qq.com/cgi-bin/appmsg?t=media/appmsg_edit&action=edit&type=10&appmsgid=100013110&isMul=1&token=698435870&lang=zh_CN#redshift

別以為數據湖只能使用Hadoop實現(xiàn)，如果你遵循一個精心抽象的數據湖架構，那么就可以根據技術的發(fā)展性及其對更廣泛的企業(yè)生態(tài)系統(tǒng)的支持度選擇其它技術，從而最小化風險。

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

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

審視現(xiàn)實-數據湖不僅僅是一個存放數據的地方

當供應商將數據湖定義為存儲的同義詞時，這可能會變得復雜。 例如，微軟將產品打包為Azure Data Lake Storage或Azure Data Lake Storage Gen2，數據湖確實提供了存放數據的功能，但這只是其特征之一。

如前所述，應該將數據湖視為是企業(yè)更為廣泛的數據棧中的戰(zhàn)略元素，這包括在下游系統(tǒng)中(如數倉)支持事務數據集成，或者在Tableau或Oracle ETL等工具中支持數據處理。

因此，數據湖不僅僅可以存儲數據，還可以兼容數倉、數據分析技術棧中的技術。 事實上，大多數數據湖是動態(tài)的生態(tài)系統(tǒng)，而不是靜態(tài)的封閉系統(tǒng)。 當數倉負載適中時，數據湖是一個活躍數據源，源源不斷為其輸送數據，反之亦然，負載過重時，數據湖進行對數據進行適當地動態(tài)處理，以降低成本和提高效率。

數據湖對數據進行適當地組織，以便將下游價值傳遞給使用數據的下游系統(tǒng)，包括數倉。 例如，數據湖在支持數倉整合事務數據方面發(fā)揮了積極的作用。

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

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

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

交付業(yè)務價值：

https://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/a-smarter-way-to-jump-into-data-lakes

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

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

審視現(xiàn)實--定義有效的數據湖策略和架構

 

 

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

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

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

那么，數據湖僅是為了存儲“原始”數據嗎?

不。

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

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

優(yōu)化：

https://blog.openbridge.com/how-to-be-a-hero-with-powerful-parquet-google-and-amazon-f2ae0f35ee04

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

Adobe事件數據發(fā)送到AWS，以支持企業(yè)Oracle云環(huán)境：

https://mp.weixin.qq.com/cgi-bin/appmsg?t=media/appmsg_edit&action=edit&type=10&appmsgid=100013110&isMul=1&token=698435870&lang=zh_CN#oracle-data-lake

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

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

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

審視現(xiàn)實-數據湖有各種形狀和大小

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

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

以下是一些例子：

諾大的“Caspian” ：

就像里海是大片水域一樣，這種類型的數據湖是一個存放各種半結構化和非結構化數據的大型數倉，這些整合了不同數據集的超大數據集反映了來自企業(yè)方方面面的信息。

臨時的“Ephemeral” ： 就像沙漠可以有小的、臨時的湖泊一樣，臨時的數據湖“Ephemeral”也是短暫存在的。 它們可以用于項目、試生產、PoC或者一個點解決方案，可以很快打開，也可以很快關閉。

領域性的“Project” ： 這種類型的數據湖和“Ephemeral”一樣往往集中在特定的知識領域中。 然后，和臨時“Ephemeral”不同的是，這種數據湖可以持續(xù)一段時間。 這些數據湖可能也很淺，可能專注于一個狹窄的數據領域，如媒體、社交、網絡分析、電子郵件或類似的數據源。 有一位客戶稱他們的項目為“Tableau數據湖”。

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

 

 

數據湖示例

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

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

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

審視現(xiàn)實-安全是一種選擇，確保你考慮的是它從某種意義上說，人們會依賴于隱性的安全技術解決方案(即自動的AWS S3 AES對象加密)，而不會去構建一個顯性的、可以管理安全性的架構和下游使用場景，這可能會導致安全漏洞，但這可以說是很多系統(tǒng)的漏洞，而非僅是數據湖本身的漏洞。 因此，認為數據湖本質上不安全的觀點是不準確的。

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

訪問 ： 通常，對針對基礎數據定義良好的訪問策略。 在AWS中，你可以定義針對S3的IAM策略及其相關服務。 除此以外，微軟還有一個描述類似安全策略方法的Azure數據湖架構。

工具 ： 處理數據的工作和系統(tǒng)也會確保一定的安全性。 例如，查詢引擎可以有一個表級和列級數據的訪問控制機制。 此外，數據處理工具(如Tableau或Power BI)也可以對數據湖中的數據設置訪問控制。

加密 ： 通常會希望(或強制)在數據傳輸和靜止時對其進行加密。

分區(qū) ： 邏輯分區(qū)和物理分區(qū)在一定水平上進一步簡化了安全策略，例如團隊可以將數據從初始數據池ETL至另一個位置，實現(xiàn)匿名化敏感數據，以供下游使用。

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

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

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

審視現(xiàn)實-正確安排人員、流程和技術

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

那么，真正的數據沼澤是什么呢? 真正的數據沼澤是設計不當創(chuàng)造出來的，而不是疏于管理促成的。

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

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

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

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

請警惕，當前或計劃中的數據湖逐漸看起來更像是傳統(tǒng)的ETL工具和數倉的合體，如果你已經經歷過一個過于復雜的構建企業(yè)級數倉工作，會很容易發(fā)現(xiàn)這一點。

數據驅動企業(yè)的數據湖架構及策略

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

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

不幸的是，這些批評逐漸變成廣為流傳的“數據湖不成功”、“數據湖等同于數據沼澤”、“數據湖與Hadoop等特定技術過于緊密聯(lián)系”等這類信息。 最后，還會出現(xiàn)“什么是數據湖”定義過于模糊和不固定的抱怨。

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

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

不。

通常情況下，蔑視數據湖的咨詢公司或企業(yè)都將自己提供的產品和服務視為靈丹妙藥，致力于實現(xiàn)自己的愿景和最佳實踐。 如果一個咨詢公司或供應商不相信一個模型，為什么要他們參與一個他們不相信的解決方案呢? 將數據湖工作委托給這類咨詢公司或供應商，很有可能是數據湖失敗的一個原因。

在深入了解如何構建數據湖或如何和企業(yè)定制數據湖之前，我們有一些技巧可以幫助你進行規(guī)劃。

如何構建數據湖

https://mp.weixin.qq.com/cgi-bin/appmsg?t=media/appmsg_edit&action=edit&type=10&appmsgid=100013110&isMul=1&token=698435870&lang=zh_CN#amazon-data-lake

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

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

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

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

焦點 ：

尋找可以部署“Ephemeral”

和“Project”解決方案的機會，確保你可以降低風險，克服技術和組織挑戰(zhàn)，從而使你的團隊能夠建立對數據湖的信心。

激情 ：

確保你有一個內部的“福音傳道者”或“大力倡導者”，這個人對公司內部的解決方案和應用充滿激情。

如果缺少這樣充滿激情的人或團隊，你會發(fā)現(xiàn)構建數據湖的熱情就很快殆盡，正如健身房新年促銷4周會員卡一樣。

簡單 ：

堅持簡單和敏捷的理念，根據這一點，做出人、流程和技術的選擇。

缺乏復雜性不應該被視為缺陷，而應該視作是精心設計的副產品。

縮小 ：

縮小數據范圍，可以很好地定義數據湖，以便了解從ERP、CRM、Point-of-Sales、Marketing or Advertising data從導出地數據，這個階段的數據處理經歷有助于你了解數據的基本結構、獲取、治理、質量和測試的工作流。

實驗 ：

將你的解決方案和現(xiàn)代BI分析工具(如Tableau、Power BI、Amazon Quicksight或Looker)結合起來，這可以讓非技術用戶有機會通過訪問數據湖來測試和探索數據，同時也有助于你利用不同的用戶群來評估性能瓶頸，發(fā)現(xiàn)改進機會，及時補充與現(xiàn)有EDW系統(tǒng)或其它數據系統(tǒng)的連接和其它候補數據源。 除此之外，還允許你發(fā)現(xiàn)對團隊有意義的數據湖工具以及適合投入資源的數據湖自動化部分。

將你的解決方案和現(xiàn)代BI分析工具(如Tableau、Power BI、Amazon Quicksight或Looker)結合起來：

https://blog.openbridge.com/building-a-serverless-business-intelligence-stack-with-apache-parquet-tableau-and-amazon-athena-e1a2363c2e6d

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

AWS Lake Formation

https://aws.amazon.com/lake-formation/

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

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

Amazon Redshift Spectrum

https://www.openbridge.com/warehouse/amazon-redshift-spectrum

Amazon Athena Services

https://www.openbridge.com/warehouse/amazon-athena

原文鏈接：

https://blog.openbridge.com/8-myths-about-data-lakes-c0f1fc71240

標簽： 數據湖 數據倉 

版權申明：本站文章部分自網絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。