消除資料重力,從智慧湖倉(Lake House)讀懂實現資料價值的未來
忽如一夜春風來,湖倉架構似花開。
今年的雲端計算市場,似乎誰不提湖倉架構誰就落伍。為何湖倉架構這麼火?如今看來,資料湖和資料倉儲加速互動,看似偶然、其實必然。
曾幾何時,很多使用者因為本地資料倉儲方案各種侷限性而叫苦不迭;當進入到大資料時代,資料湖概念興起,人們看到了實現資料價值的新途徑,甚至還有廠商發出用資料湖替代傳統資料倉儲功能的聲音。
殊不知,資料湖與資料倉儲從來就不是取代與被取代的關係。在資料湖蓬勃發展的同時,資料倉儲藉著雲端計算的東風,同樣在高速成長與進化。尤其是當我們踐行大資料十餘載、資料價值逐漸深入人心之時,驀然回首愈發明白:資料只有打通、流動、共享才能充分發揮其價值。
這也是以亞馬遜雲科技Lake House為代表的智慧湖倉架構近年來廣受使用者青睞的原因。資料湖與資料倉儲既不是非此即彼的二元選擇,也不是永不相交的兩條平行線,無縫流動、彼此補充才是二者最佳歸宿,也是加速挖掘資料價值的唯一途徑。
從亞馬遜雲科技Lake House智慧湖倉架構,我們真正讀懂了實現資料價值的未來。
資料湖為何是必然選擇
眾所周知,資料已然成為一種關鍵的生產資料,成為數字化時代一切運轉的基礎。大量基於資料驅動的業務場景湧現,加速重塑企業與組織的生產、經營、銷售、服務等業務。
以銀行營銷為例,過去更多依賴本地部署的資料倉儲解決方案來制定營銷方案,資料模型正規化有要求、維度單一、實時性差,導致營銷方案分析維度少、業務響應差,頗像“事後諸葛亮”;而如今的銀行營銷方案,通常構建在基於資料驅動的場景之上,會收集使用者各種維度的相關資料,採用機器學習不斷學習訓練模型,實現在合適場景、合適時機將合適產品推薦給使用者,並形成資料價值閉環,不斷完善模型,實時調整營銷策略,實現銀行與使用者的雙贏。
一個小小的營銷場景恰恰反映出資料湖核心價值所在。自2010年Pentaho CTO James Dixon首次提出資料湖概念以來,資料湖之所以迅速被人們所認可,核心原因在於它幫助使用者梳理清楚從資料儲存、資料匯聚到資料探勘的過程,這恰恰是大資料時代下實現資料價值的關鍵基礎。
大資料時代,海量規模、型別豐富的資料每時每刻都在產生,而資料湖作為一個以原始格式儲存資料的系統,按原樣儲存資料,無需事先對資料進行結構化處理,可以儲存結構化資料、非結構化資料以及二進位制資料等,並進行資料拉通、消除資料孤島,為資料分析、機器學習等提供極大便利。
資料湖概念深入人心,但資料湖落地卻並不是一帆風順,這十年以來各類代表廠商、營銷理念、解決方案層出不窮,失敗案例也不在少數,而近年來真正“撥亂反正”、率先走出資料湖價值落地之路則是以亞馬遜雲科技為代表的雲服務提供商們。
歸根結底,雲端計算的彈性、可擴充套件性、存算分離等特性,使之與資料湖不期而遇時,在技術層面和使用層面高度契合,成就了實現資料價值的一段佳話。
當雲與資料湖不期而遇
雲端計算與資料湖之所以能成為一對絕佳的CP,資料規模是關鍵因素。
看一個直觀例子,OpenAI GPT-1模型引數只有1.1億個,預訓練資料量為5GB,最新的GPT-3模型引數則高達1750億個,預訓練資料量高達45TB,模型規模和資料量增長了千倍,更何況那些基於AI模型的各種智慧應用每天所產生的海量資料。
基於資料驅動的智慧應用爆發,帶來PB級甚至EB級的海量規模資料時,雲端計算與資料湖組合帶來的價值愈發凸顯:當資料規模越來越大時,計算能力成為關鍵,而有了雲端計算的彈性與可擴充套件,可以讓海量資料的儲存與分析更加容易;與此同時,雲端計算與資料湖都廣泛採用分散式架構與開源體系,技術迭代與進化得以加速,適應未來資料處理的新需求與新變化;另外,在雲上構建起資料湖平臺之後,天然整合更多新技術與服務,例如更好支撐起機器學習等人工智慧技術,實現雲數智的融合。
因此,雖然開源和儲存廠商是資料湖概念的先行者,但真正走出落地之路則是以亞馬遜雲科技為代表的雲服務商。
以亞馬遜雲科技為例,早在2009年就推出了 Amazon Elastic MapReduce(EMR)架構,實現跨 EC2 例項叢集自動配置 HDFS;2012年,亞馬遜雲科技推出了具有標誌性意義的雲資料庫倉庫服務Amazon RedShift;隨後,亞馬遜雲科技陸續打造出Athena、Glue、Lake Formation等一系列核心產品,逐漸形成完整的資料湖解決方案。
亞馬遜作為全球最大的網際網路公司,其資料規模、資料複雜度、資料處理難度、資料價值挖掘在業界無出其右,這使得亞馬遜雲科技對於資料湖的理解、使用以及產品打造等方面往往極具借鑑價值。
例如,資料湖構建的核心目的是為了資料分析與資料探勘,因此快捷的互動式查詢就至關重要。以Amazon Athena為例,其簡單易用,採用標準SQL 分析 Amazon S3 中的資料,只需指向開發者儲存在 S3 中的資料,定義架構即可開始查詢,它無需執行復雜的ETL作業來為資料分析做好準備。
而資料湖無需事先對資料進行結構化處理,可以按照任何格式儲存資料,帶來最大的挑戰之一就是查詢資料並瞭解資料結構和格式,此時資料目錄和ETL服務就至關重要。以Amazon Glue 服務為例,其核心解決思路就是為使用者建立起無伺服器架構的資料目錄和ETL服務,無需使用者自己寫ETL管道,快速完成資料的抽取、轉換和載入。
此外,構建和使用資料湖並不是一件輕鬆的事情,隨著海量資料規模的不斷增加,資料湖的建立、配置、管理和使用的複雜性也會隨之增加,很多使用者對於載入資料來源、設定分割槽、定義轉換作業等複雜手動任務更是深惡痛絕。
此時,雲端計算的優勢再一次凸顯出來。以Amazon Lake Formation為例,開發者只需手動定義資料來源,制定要應用的資料訪問和安全策略,Lake Formation 會自動幫助開發者從資料庫和物件儲存中收集並按目錄分類資料,再將資料移動到新的Amazon S3 資料湖,大幅縮短資料湖的構建時間。
可以說,資料湖已經不僅僅是一個概念,更代表著過去十年使用者實現資料價值的一種進化。在這個過程中,雲端計算憑藉著彈性、可擴充套件、靈活的特性,不斷遮蔽資料湖從建立到使用過程中的各種複雜性,降低資料湖的使用門檻,加速實現資料價值的落地。
但這就足夠了麼?
攻克最後的壁壘
2020年是一個重要的分水嶺,全球疫情常態化以及錯綜複雜的內外部環境,使得企業無時無刻都面臨著不確定性,數字化時代的敏捷性和全域性視角洞察能力正變得愈發重要,而資料的打通、流動與共享無疑是構建起敏捷性和全域性視角洞察能力的關鍵所在。
換句話說,資料湖、資料倉儲以及其他資料儲存方案並不是彼此割裂,而是需要無縫協同工作,讓資料自由流動、共享與使用,讓基於資料的決策更加科學與精準。尤其考慮到海量資料規模成為常態的大背景下,無論是資料湖、資料倉儲還是其他資料儲存方案,其所儲存的資料量一直在不斷膨脹,逐漸衍生出一種新的現象:即資料往來、移動操作變得愈加複雜與困難。
亞馬遜雲科技將這種現象形象地比喻為“資料重力”。毫無疑問,“資料重力”是實現資料價值的最後壁壘。要想打破壁壘,Amazon Lake House智慧湖倉架構來圍繞資料湖構建起專用資料閉環,實現以安全且受控的方式在不同資料儲存方案之間快速移動資料。
事實上,亞馬遜雲科技很早就致力於消除資料重力現象。早在Amazon Redshift誕生伊始,就允許從資料湖S3中匯入資料進行分析,並且在2017年推出Redshift Spectrum引擎,打通資料倉儲對資料湖中資料的直接訪問;之後,2019年,亞馬遜雲科技將redshift spectrum 引擎命名為Lake House引擎;到2020年re:Invent大會上,亞馬遜雲科技提出Lake House智慧湖倉架構。
Lake House智慧湖倉架構關鍵之處在於以高度擴充套件的資料湖為核心,構建起專用資料閉環,實現以安全且受控的方式在不同資料儲存方案之間快速移動資料, 為不同業務場景專門構建的分析工具或資料儲存之間無縫的協同工作(例如:資料倉儲、搜尋引擎、機器學習平臺等)。
現實需求情況的確如此如此,例如,使用者有時希望將來自Web應用程式的點選流資料直接收集在資料湖內,並將其中部分資料移至資料倉儲以生成每日報告;使用者有時又希望將特定區域內的產品銷售查詢結果從資料倉儲複製到資料湖內,進而使用機器學習對大規模資料集執行產品推薦演算法。
隨著亞馬遜雲科技在2020年Re: Invent上公佈一系列新功能,Lake House架構逐步形成五大特徵:可擴充套件資料湖、專門構建的(Purpose-built)分析服務、無縫資料移動、統一資料治理、出色的效能與成本效益。
以無縫資料移動為例,亞馬遜雲科技的無伺服器資料整合服務Glue已經日臻成熟,提供資料整合所需要的全部功能,自動發現資料並儲存Schema,與亞馬遜雲科技上執行的Aurora、RDS、RedShift、S3和資料庫引擎天然整合。透過Glue elastic view, 開發人員使用PartiQL即可在多種資料庫及資料儲存方案內建立物化檢視,幾分鐘就能完成跨資料儲存方案的資料合併與複製。
又如,在當今海量資料規模的環境中,對於資料訪問活動的授權、管理和審計等一系列治理至關重要。例如,如何實現跨組織內各類資料儲存方案的安全管理、訪問控制與審計跟蹤,往往因為極其複雜和耗時讓使用者捉襟見肘。面對這種情況,Lake House架構憑藉集中訪問控制與策略,輔以列與行層級的過濾等功能,帶來細粒度訪問控制與治理選項,能夠立足單一控制點對跨資料湖及專用資料儲存系統的訪問行為進行全面管理。
綜合來看,隨著基於資料驅動的智慧應用遍地開花,使用者面臨的將是一個資料規模更加龐大、管理更加複雜的資料環境。面向未來,資料湖、資料倉儲以及專用分析引擎的協同執行會更加頻繁,智慧湖倉架構必然會成為使用者們的首選,而Amazon Lake House無疑將迎來更大的價值舞臺。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69965091/viewspace-2774325/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 一文讀懂:本地資料湖丨資料倉儲丨雲資料湖的利與弊
- 讀資料湖倉06資料整合
- 讀資料湖倉02資料抽象抽象
- 一文讀懂選擇資料湖還是資料倉儲
- 讀資料湖倉01讓資料可信
- 資料湖倉比較:Apache Hudi、Delta Lake、Apache IcebergApache
- Delta Lake 資料湖原理和實戰
- 讀資料湖倉05資料需要的層次
- 讀資料湖倉03不同型別的資料型別
- 讀資料湖倉08資料架構的演化架構
- 讀資料湖倉07描述性資料
- 資料湖揭祕—Delta Lake
- 讀資料湖倉04資料架構與資料工程架構
- 資料湖+資料倉儲 = 資料湖庫架構架構
- 從火星的古海洋,讀懂藍星的資料湖之變
- 資料智慧的現在與未來
- 資料倉儲、資料湖與湖倉一體的區別與聯絡
- 關於資料湖、資料倉儲的想法
- 資料湖 vs 資料倉儲 vs 資料庫資料庫
- 解讀Nucleus Research 2022資料倉儲價值矩陣矩陣
- 「湖倉一體」釋放全量資料價值!巨杉資料庫亮相2022沙丘大會資料庫
- 萬字詳解資料倉儲、資料湖、資料中臺和湖倉一體
- MRS+LakeFormation:打造一站式湖倉,釋放資料價值ORM
- 資料湖 vs 倉庫 vs 資料庫資料庫
- 資料湖會取代資料倉儲嗎?
- 談談資料湖和資料倉儲
- 資料湖和中央資料倉儲的設計
- 漫談“資料湖”之價值與架構架構
- Databricks決定開源其Delta Lake資料湖
- 資料湖 VS 資料倉儲之爭?阿里提出大資料架構新概念:湖倉一體阿里大資料架構
- 資料倉儲被淘汰了?都怪資料湖
- 談談如何從資料湖(Data Lake)架構轉向資料網格(Data Mesh)架構架構
- 讀資料湖倉09讀後總結與感想兼導讀
- 資料倉儲 vs 資料湖 vs 湖倉一體:如何基於自身資料策略,選擇最合適的資料管理方案?
- 資料湖表格式比較(Iceberg、Hudi 和 Delta Lake)
- 資料網格將替代資料倉儲或資料湖?- thenewstack
- 資料湖+資料中臺,金山雲大資料平臺如何攻克資料價值落地難關大資料
- 從“智慧湖倉”架構的技術演進,看現代化資料平臺的發展方向架構