一件事物若能經得起時間的推敲，經得起歷史的選擇，回過頭去看仍能矗立在長河之中，那我們通常會稱它為“經典”。
?
10年前，Pentaho公司（一家開源BI公司）的CTO詹姆斯·迪克森在他的博客中第一次提出“數據湖”（Data Lake）的概念；10年后的今天，在業界“數據中臺”大火的時代背景下，再來討論“數據湖”，應該別有一番韻味。
?
本文將會以“數據湖”為中心，展開討論數據倉庫、數據湖和數據中臺這幾個概念之間的藕斷絲連。
?
一
從“數據倉庫”到“數據湖”：歷史的演變
事物總是在不斷演化的，唯一不變的就是變化，因此為了討論這些概念，我們首先要了解其歷史流變。
?
“數據倉庫”，由比爾·恩門（Bill Inmon）于1990年提出，其被廣泛接受的定義是，一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，用于支持管理決策，通常也被認為是決策支持型應用的必要條件。
?
此處的定義大多都是針對事務型數據系統而制定的。所謂事務型數據系統，是指記錄業務交易的系統，這個名詞先是在金融業，特別是銀行實施信息化IT系統時使用的。例如銀行的交易流水數據庫，每分每秒都有大量的交易被數據庫所記錄并持久化的保存下來，其最小的顆粒度就是一筆“交易”。后來信息化系統在各行各業開花結果，“業務”漸漸演變為現在的“事務”概念，例如員工刷卡進入辦公室，后臺就會記錄員工的這一“事務行為”。
?
事務性數據系統存在諸多劣勢：試想，如果一個銀行的分行長想知道今天到目前為止共有多少現鈔存款入賬，那么系統就需要遍歷今天截止到目前的所有交易行為，并篩選其中的存款行為進行匯總。查詢交易的行為需要遍歷當前系統的所有記錄，因此當這一行為頻率變高時，會對數據系統造成巨大的讀取壓力。
?
其次，當分析業務時需要的信息變多，也就是查詢行為的數據對象范圍變廣時，例如分行長想知道今天一共有多少人民幣現匯（包括外幣購匯）入賬時，系統需要將每筆外匯交易換算成人民幣，再進行全部交易的匯總。假設有一百種外幣進行了一萬次的交易，數據系統內的計算空間會呈“笛卡爾積”般的增長，造成資源上的重大消耗。
?
“笛卡爾乘積是指在數學中，兩個集合X和Y的笛卡爾積（Cartesianproduct），又稱直積，表示為X × Y，第一個對象是X的成員而第二個對象是Y的所有可能有序對的其中一個成員。”
?
除開查詢或分析任務對事務型數據系統造成的資源壓力外，系統執行任務時，返回的結果只代表著任務開始運行那一刻的數據狀態，假設執行查詢任務消耗了1分鐘，這1分鐘內很有可能發生多次的交易撤銷、額度修改，增加交易等行為。有些數據系統允許在讀取數據的同時寫入數據，那么查詢任務返回的結果并不能代表最新的狀態；有些數據系統則有“讀鎖”，即在讀取數據的時候不允許寫入數據，那么這個長達1分鐘的查詢任務會使得業務交易失敗或者暫緩進入數據系統，如果其中發生業務中斷，這些交易數據可能面臨丟失的風險。
?
當然，我們可以通過技術手段來避免或緩解事務型數據系統的不足，因此事務型的數據庫并不是不能做業務分析，只是當決策者需要進行經營性的分析和決策時，大多數時候它并非最優方案。此時，數據倉庫面向主題且便于分析的優勢就體現出來了：
?
（1）面向主題的：
?
相對于事務型系統將交易類型（存款）、交易幣種（人民幣或外幣）、交易數值（存款額）以一條事務（Transcation）的方式存儲，數據倉庫通常會將一條事務中的不同信息拆分到不同的主題域中分別存儲，例如交易類型表、交易幣種表和交易額度表等。
?
（2）集成的：
?
不同主題域中的信息之間以統一的ID，如交易流水號為標識進行鏈接。這樣的好處是當分行長想知道今天到目前為止一共有多少人民幣存款入賬時，只需要先篩選出交易類型為存款，交易幣種為人民幣的交易流水號，再基于這些流水號去匯總交易額度，比起原先需要遍歷全部交易記錄后才能匯總的方式大大節約了系統資源的開銷。
?
（3）相對穩定的：
?
通常數據倉庫和事務型數據系統會被物理隔離在不同的硬件資源上，前者注重數據的查詢（讀取），后者注重數據的錄入（寫入），避免了單一數據系統讀寫沖突的問題。事務型數據系統由于直接應對業務的多樣性，交易的增加、更改和刪除非常頻繁，這些變化有時候采用對沖的方式做記錄，有時候在原有的記錄上直接做更改，導致系統處于一直變化的狀態；而數據倉庫通常以時間窗口作為數據批量導入的分區，例如每一小時或一天從事務型系統導入一次數據，在下一次數據導入任務開始之前，系統處于一個相對穩定的狀態，有利于進行經營性的業務分析。
?
（4）反映歷史變化的：
?
正是由于通常數據倉庫中的數據是基于預先設定好的時間窗口從事務型系統中獲取數據，無論是一分鐘、一小時還是一天、一周，它都是可以反映數據整體歷史變化的，分行長可以清楚地知道今天銀行的人民幣存款入賬環比昨天增長或減少了多少，同比上個月的今天又發生了什么變化。
?
因此，比起事務型的數據系統，數據倉庫能更有效地對業務數據進行統計分析，無論是在提高效率、穩定性還是降低資源成本上都有其優勢，所以被廣為接受而大行其道。我們可以清楚地看到，數據倉庫是數據處理中一種特定的實施方法。
?
后來，數據倉庫領域的大師Ralph Kimball又演化出“維度建模”的概念，認為數據倉庫是一系列數據集市的集合。如果說數據倉庫中包含著許多不同的主題域，那么數據集市可以理解為主要面向業務應用的單一主題域。比如，分行長可以建設面向存儲部門的、專門提供存款數據的“存款數據集市”，面向商業貸款部門的“貸款數據集市”，面向信用卡部門的“信用卡數據集市”等，其數據都源自數據倉庫，但數據集市的匯總程度更高、更注重業務表示。例如“環比存款增長率”這個指標在數據倉庫中可能表示為“上月存款額”和“本月存款額”兩個不同的數值，而在數據集市或者數據倉庫的“集市層”中，就表示為計算后的一個數值，可以直接被業務所用而無需再做多余的計算。
?
?
而“數據湖”這個概念，由Pentaho公司的CTO詹姆斯·迪克森于2010年提出，這里漸漸開始有了商業的味道。他認為：
?
“如果你認為一個數據集市可以看作是桶裝水店——提供了清洗、包裝和組織等服務以方便用戶消費，那‘數據湖’就是一個擁有更自然狀態的大的水體。來自源頭的內容流補充到湖中，各類客戶可以來湖中檢測、探索以及獲取樣本。”?
?
因為當時業界正興起“XaaS”的風潮，例如軟件即服務（SaaS，Software as a Service），平臺即服務（PaaS，Platform as a Service），基礎設施即服務（Iaas，Infrastructure as a Service），甚至還有解決方案即服務（SolaaS，Solution as a Service）以及數據中心即服務（DCaaS，Data Center as a Service）。在這一背景下，已發展成熟的公有云能力為數據湖體系架構的發展奠定基礎，催生“數據湖”的概念。
?
接著在2011年，福布斯在文章《Big Data Requires a Big, New Architecture》中報道了“data lake”這個詞，并給出了數據倉庫與數據湖的對比：數據倉庫的數據在被集成時就會被預先分類，并以最優的方式進行存儲，以支撐特定的分析；但在大數據時代，我們從源系統抽取數據時可能無法明確知道這些數據的價值，因此無法給出一個最優的存儲方式。
?
例如，分行長從交易系統中將所有的數據都抽取過來，但并不知道業務部門想做什么類型反映業務歷史的變化。因此建議將這些數據先保存在一個海量的數據庫中。由于數據來源的格式五花八門而且會越存越多，因此這個數據庫需要具備容易訪問且存儲成本低（允許硬件資源擴容的成本而盡可能降低其他成本，例如軟件使用費用、人工維護費用等）的特性，需要進行分析時，再來組織和篩選所需數據，這個數據庫就是數據湖（Data Lake）。
?
彼時的數據湖概念更多地是關于當企業在處理海量異構的數據時，如何在數據產生實際的應用價值之前，為海量數據構建一個易訪問且成本低的存儲方式，和數據資產化、資產服務化等當下熱點名詞并沒有太大關系。
?
但事物都是在不斷演化的，2014年福布斯雜志上刊登了一篇名為《The Data Lake Dream》的文章，文章作者EddDumbill描述了數據湖的愿景：
?
融合所有數據，解決系統間數據孤島、各類應用統一訪問問題；
?
數據可獲取性提高，應用部署時間縮短；
?
具有彈性的分布數據處理的平臺，能同時支撐批量和實時數據操作處理和分析；
?
數據湖增加安全和管控層面的功能；
?
重視集中、自動的元數據管理和入湖標準，避免成為沒有價值的數據。
?
從這個時候開始，單純的數據湖就朝向一個“平臺級的方案”而演進。為什么說是方案呢，因為時至今日，數據湖仍是個架構概念，是一種架構設計的理念，而不是一種特定的實施方法，更不是一款特定的產品。其所要達成的目標囊括了不止一種數據技術，已經從當初的一種“大數據存算方案”進階到了“大數據存算+處理分析+資產治理+安全隱私+數據變現”的一攬子方案。
?
10年前，迪克森曾認為“數據湖”是面向企業的最佳大數據解決方案。從技術上來看，其論點是有根據的，但是從商業價值上來看，這個愿景似乎并沒有被實現。實際情況是過去數據倉庫的落地實踐要遠比數據湖來的多和廣。而就在現今所有人都在強調數據資產化、資產業務化，強調數據變現和數據商業價值的年代，數據中臺的概念似乎又代替了數據湖的概念。
?
數據中臺，由于受到從業者的追捧并在這兩年瘋狂流行，隔著屏幕應該都可以嗅到濃重的商業氣息，但目前對其仍然沒有清晰明朗的定義。當大多數人努力想要為數據中臺做名詞解釋時，我倒認為這個局面十分恰當且正常。
?
首先，數據中臺的概念如同數據湖一樣，是一種架構概念；其次，它不僅是工程設計上的技術架構，還包括了組織架構的變革，因為中臺通常會強調其作為一個企業組織運作的“獨立性”、“中央性”和“統一性”。
?
中臺作為抽離原來各個數據部門共性業務、由技術和人員并提供統一數據、產品及服務的“共享業務事業部”，無論在業務功能上還是工程技術上都會有其獨立運作，數據權威和統一分發的訴求，因此其組織承載的考核目標及衡量標準較原先的數據倉庫、數據湖等技術概念而有所不同，特別是在“數據驅動業務”、“數字化轉型”的時代大背景下，它們是和企業的總體業務目標緊密相關的，不再只是一個“旁路IT系統”，不再只是一個業務信息化的支撐系統，而是產生并驅動業務的關鍵環節。數據中臺應當是企業組織和技術架構的有機結合體。
?
二
技術商業化應用之動力：業務的訴求
科學技術的發展有其自有的原發性，而商業世界里對一項技術的認可并將其廣泛商業化應用的動力，仍來自于商業目的的要求。數據技術也是如此，業務訴求的發展推進了技術的革新。
?
大數據平臺，數據湖，數據倉庫和數據中臺這些概念有什么不同，到底是誰代替了誰？我相信非專業領域的從業人員每當看到這些詞匯的時候或多或少有這樣的困惑。我認為，這里并沒有誰代替了誰，所謂孰優孰劣只是從不同的業務需求出發得出的不同結論而已。
?
當企業的信息化發展到一定程度，企業流程得以用數據的形式持久化的留存下來，決策者們的判斷依據慢慢從經驗主義過渡到數據主義，因此90年代初為了更好的支持經營的決策分析，數據倉庫的技術就油然而生并被廣泛應用。
?
當企業開始邁向全面數字化的階段，需要處理的數據越來越多、形式越來越雜，原先使用的數據存算方式其成本越來越高，業務對數據處理的效率要求也越來越快。在這種背景下，企業亟需一種成本更低且效率較高的方式來存算數據、訪問數據，因此大數據技術孕育而生。我們通常說的大數據平臺就是利用大數據技術而搭建的平臺型能力，為企業提供大數據技術服務。
?
而當企業邁入大數據時代后，紛紛利用大數據技術搭建各自的大數據平臺。為了進一步降低數據存儲和處理的成本，提升大數據平臺的可用性、可靠性和可運營性，解決大數據時代數據分析鏈路越來越長、數據探索復雜度越來越高、數據資產管理越來越難以及數據變現的路徑尚不清晰等問題，基于數據湖的架構概念，我們又開始在大數據平臺上嘗試搭建各自的數據湖架構。由此可見，數據湖也是由業務訴求催生出的平臺架構概念和能力。
?
?
?
所謂分久必合，當企業的數字化、數據化成為一種常態時，有些企業發現內部存在紛繁復雜的數據源，存在多個所謂大數據平臺甚至是數據湖，導致了很多不必要的重復性建設，包括服務、軟件和硬件層面的冗余，或是由于部門壁壘而導致數據無法有效統一來支持前端業務，不統一的數據出處又帶來數據不一致的問題，亦或是不同部門各起爐灶導致數據技術人員各自分散的問題。在這種背景下，由高層拍板構建企業級的數據中臺，把原有資源剝離和再分配，將共性抽象集成并形成資產，統一面向全組織提供服務。這里的服務包括了數據資產、產品軟件、算法算力甚至是技術人力。
?
因此，我認為這三者沒有誰對誰錯或是誰替代了誰，只是企業不同的發展背景形成了不同的建設目標，各自有不一樣的業務訴求罷了。
?
三
技術的革新
業務訴求會推動技術的發展，有時技術本身的革新也會帶給業務發展更多的想象空間。
?
如同前文所述，隨著時代的發展，技術也在不斷演化，但其演化歷程通常是具有連續性而非跳躍性的。當然，跳躍性的原始創新會被歷史所銘記并開創一個新的時代，成為時代的主角，例如蒸汽機，發電機，計算機和互聯網。但循序漸進的集成創新才是平凡日子里的重要配角，小步蓄力以期待下一次的飛躍。因此大多數時候新概念的產生通常會帶有前任的影子而導致傻傻分不清楚，或被誤認為是“老瓶裝新酒”的現象。
?
在當下時代對“企業是否一定要建設中臺”的爭論仍在持續著，我認為里面除技術之外，更多地牽涉到企業本身的發展階段、組織架構和企業文化等問題。有些管理者能很好的從自身業務和技術角度去辨別組織真正需要的是什么，因此我們回頭看數據湖的建設，這個議題仍是舞臺上活躍的一份子。而技術的革新，已經使得數據湖的建設目標不止于10年前剛提出時的愿景。
?
目前在建設數據湖的時候，企業通常會展望以下幾個技術目標：
?
（1）提供高可靠性、高性能、可伸縮的分布式存儲系統，在一定程度上降低單位存算成本的同時統一承載海量結構化、半結構化以及非結構化數據。
?
（2）提供豐富的數據計算分析引擎，具備對結構化、半結構化和非結構化數據進行多層次融合分析的能力。
?
（3）關鍵能力包括：
?
混合處理：支持所有類型數據入湖無需預先設計模型，同時支持事務型和分析型的數據處理，數據入湖就能即席分析、持續迭代。
?
聯邦分析：支持多類型數據格式融合分析，無需額外數據搬遷，可通過標準查詢語句實現跨源數據探索計算分析。
?
彈性伸縮：計算層和存儲層可獨立彈性擴展，具備大容量存儲池和“理論上”無限彈性計算資源能力，快速應對數據和業務變化。
?
分級存儲：支持冷熱數據分級存儲，數據自動管理，合理利用存儲，降低成本。
?
數據探索：具備集成的算法開發能力，能快速地構建算法模型及數據探索任務，甚至與標準數據庫查詢語句融合，支持采用標準接口完成算法及AI業務的開發。
?
四
展望：更大想象力空間
在萬物互聯的時代構想數據湖的未來，不乏有許多引人想象的可發展空間，舉例來說：
?
（1）更智能的數據接入：
?
物聯網時代信息進一步爆炸，無論是數據量還是數據種類和復雜度都呈指數級發展，數據湖可以成為整個物聯網基建的融合匯聚中心，通過數據感知技術，根據接入的數據類型、更新頻率、數據量大小以及預設好的使用場景等信息，智能判別數據接入方式、自動化地進行底層協議及技術的匹配，降低接入數據湖的門檻和整體運維的成本。
?
（2）更精細的資產管理：
?
可以從冷熱數據（被使用頻率低和高的數據）、業務標簽等不同角度對數據進行分級分層存儲，在預先定義好的數據治理規則和基于日志的機器學習運維任務下，做到半自動甚至全自動的數據管理，合理利用系統資源，實現“數據自治”。
?
（3）更靈活的數據分析：
?
納入“數據不動計算動”的聯邦學習能力，解決數據遷移、數據安全和數據權責的問題；納入“既能保證數據事務性又能保證數據分析性”的混合事物/分析處理架構（Hybrid Transaction and Analytical Process），解決從事務性數據庫導入到數據倉庫產生的時效性和一致性問題；納入針對“大寬表”的即席多維度分析能力，解決傳統上做多維度分析時需要將數據預先按主題拆分和轉換處理過程而導致的分析長鏈路以及低時效問題等。
?
（4）更直觀的數據價值：
?
在數據應用實現商業變現之前，就數據本身而言，納入靈活但可控的數據共享工具及平臺，加速湖內和湖外、組織內和組織外數據的碰撞，共融互通而形成更完整的數據全景從而為業務服務；納入數據商業化/社會化運營工具，例如數據沙箱、智能脫敏、自主訂閱、用量統計等，撬動數據資產本身的價值。
?
雖然無論在功能目標還是項目建設方面，數據湖總體仍處于不斷發展的階段，
?
我們不知道數據湖的概念還能在商業科技的世界里存在多久，亦不知道若干年后我們回頭看待它時，能否將之稱為“經典”。但這并不妨礙在當下企業參照數據湖的架構概念和功能目標，去搭建大數據處理平臺所帶來的積極效果，即使在所謂的“數據中臺時代”來反觀數據湖的概念，每一個從業者仍有必要保持不斷學習的謙遜態度，每一個參與方仍要以包容和發展的目光來審視過去、展望未來。
熱門標簽
快速評論
收藏
粵公網安備 44010402002339號
