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

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

亞馬遜數(shù)據(jù)湖：

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的數(shù)據(jù)湖：

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

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

讓我們開始一一打破這些錯誤認(rèn)知吧!

錯誤認(rèn)知1： 數(shù)據(jù)湖與數(shù)據(jù)倉庫，必須二選一

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

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

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

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

那供應(yīng)商推廣的數(shù)據(jù)湖架構(gòu)限制示例是什么?

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

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

那么，為什么供應(yīng)商和咨詢公司會在這里應(yīng)用數(shù)據(jù)倉庫計算概念?

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

FUD行銷手法：

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

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

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

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

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

錯誤認(rèn)知2： 數(shù)據(jù)倉庫就是一個數(shù)據(jù)湖

這種想法會誘使你放棄數(shù)據(jù)湖，將所有數(shù)據(jù)都扔進(jìn)數(shù)倉中。

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

的確，有一些供應(yīng)商和咨詢公司主張將數(shù)倉作為數(shù)據(jù)湖模型。

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

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

但是，在數(shù)倉“導(dǎo)入所有數(shù)據(jù)”模型中，數(shù)倉包含所有的數(shù)據(jù)內(nèi)容，其中會包括暫時的和易失的原始數(shù)據(jù)。

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

操作型數(shù)據(jù)庫：

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

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

數(shù)據(jù)處理：

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

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

技術(shù)債務(wù)：

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

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

 

 

數(shù)據(jù)湖架構(gòu)

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

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

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

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

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

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

Hadoop和其它技術(shù)一樣，可以支持戰(zhàn)略和架構(gòu)的實現(xiàn)。 如果現(xiàn)在你有一個數(shù)據(jù)湖，會有很多非Hadoop的選擇，即使這些選擇使用了Hadoop相關(guān)技術(shù)。 例如，你的數(shù)據(jù)湖需要同時支持Snowflake這樣的數(shù)倉解決方案和在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

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

錯誤認(rèn)知4： 數(shù)據(jù)湖僅用于“存儲”數(shù)據(jù)

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

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

當(dāng)供應(yīng)商將數(shù)據(jù)湖定義為存儲的同義詞時，這可能會變得復(fù)雜。 例如，微軟將產(chǎn)品打包為Azure Data Lake Storage或Azure Data Lake Storage Gen2，數(shù)據(jù)湖確實提供了存放數(shù)據(jù)的功能，但這只是其特征之一。

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

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

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

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

這兩個例子都強(qiáng)調(diào)了，數(shù)據(jù)湖在保證下游事務(wù)數(shù)據(jù)的準(zhǔn)確性和合規(guī)性上發(fā)揮了積極的作用。

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

交付業(yè)務(wù)價值：

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

錯誤認(rèn)知5： 數(shù)據(jù)湖僅存儲“原始”數(shù)據(jù)

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

審視現(xiàn)實--定義有效的數(shù)據(jù)湖策略和架構(gòu)

 

 

數(shù)倉或SQL查詢引擎的典型工作流

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

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

那么，數(shù)據(jù)湖僅是為了存儲“原始”數(shù)據(jù)嗎?

不。

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

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

優(yōu)化：

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

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

Adobe事件數(shù)據(jù)發(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

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

錯誤認(rèn)知6： 數(shù)據(jù)湖僅適用于“大”數(shù)據(jù)

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

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

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

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

以下是一些例子：

諾大的“Caspian” ：

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

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

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

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

 

 

數(shù)據(jù)湖示例

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

錯誤認(rèn)知7： 數(shù)據(jù)湖沒有安全保障

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

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

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

訪問 ： 通常，對針對基礎(chǔ)數(shù)據(jù)定義良好的訪問策略。 在AWS中，你可以定義針對S3的IAM策略及其相關(guān)服務(wù)。 除此以外，微軟還有一個描述類似安全策略方法的Azure數(shù)據(jù)湖架構(gòu)。

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

加密 ： 通常會希望(或強(qiáng)制)在數(shù)據(jù)傳輸和靜止時對其進(jìn)行加密。

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

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

錯誤認(rèn)知8： 數(shù)據(jù)湖會變成數(shù)據(jù)沼澤

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

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

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

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

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

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

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

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

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

數(shù)據(jù)驅(qū)動企業(yè)的數(shù)據(jù)湖架構(gòu)及策略

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

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

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

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

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

不。

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

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

如何構(gòu)建數(shù)據(jù)湖

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

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

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

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

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

焦點(diǎn) ：

尋找可以部署“Ephemeral”

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

激情 ：

確保你有一個內(nèi)部的“福音傳道者”或“大力倡導(dǎo)者”，這個人對公司內(nèi)部的解決方案和應(yīng)用充滿激情。

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

簡單 ：

堅持簡單和敏捷的理念，根據(jù)這一點(diǎn)，做出人、流程和技術(shù)的選擇。

缺乏復(fù)雜性不應(yīng)該被視為缺陷，而應(yīng)該視作是精心設(shè)計的副產(chǎn)品。

縮小 ：

縮小數(shù)據(jù)范圍，可以很好地定義數(shù)據(jù)湖，以便了解從ERP、CRM、Point-of-Sales、Marketing or Advertising data從導(dǎo)出地數(shù)據(jù)，這個階段的數(shù)據(jù)處理經(jīng)歷有助于你了解數(shù)據(jù)的基本結(jié)構(gòu)、獲取、治理、質(zhì)量和測試的工作流。

實驗 ：

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

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

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

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

AWS Lake Formation

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

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

使用無代碼、全自動和零管理的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

標(biāo)簽： 數(shù)據(jù)湖 數(shù)據(jù)倉 

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