天天看點

離線實時一體化數倉與湖倉一體—雲原生大資料平台的持續演進

離線實時一體化數倉與湖倉一體—雲原生大資料平台的持續演進

林偉,阿裡雲智能研究員、阿裡雲智能通用計算平台MaxCompute、機器學習PAI平台技術負責人

本篇内容将從三個部分為讀者講述離線實時一體化數倉與湖倉一體—雲原生大資料平台的持續演進。通過從資料湖到數倉的曆史,反思為什麼要做湖倉一體,以及湖倉一體在今天這個階段為什麼開始做離線和實時湖倉一體化的數倉。

  • 湖倉一體
  • 離線線上數倉一體化
  • 智能數倉

希望這次的分享讓大家進一步了解我們為什麼做湖倉一體。

一、湖倉一體

(1)   阿裡巴巴從資料湖到數倉曆程

2007年的甯波戰略會議确定建立一個開發、協同、繁榮的電子商務生态系統,其中生态系統的核心是資料。但這個時候各個業務部門都在垂直式發展資料能力,用資料支撐商業的決策服務。這些資料中台支撐了業務部門的發展。但我們發展到一個階段的時候,希望進一步挖掘出各個業務部門資料之間的關聯性,進而利用這些高階資料分析挖掘更高商業價值,我們遇到了很多的困難,因為資料來自不同的部門,不同的人會提供你不同的資料集,沒有清晰資料品質監控,你也不知道這些資料是不是完整的,你就需要花費很多時間不停的去校準資料。這個過程耗時太長且多數情況會做了非常多的無用功,這樣其實整體下降了公司的效率。

是以到了2012年,我們決定将所有的業務部門的資料都關聯起來,決心做『One Data,One Service』。其實這個過程就是典型一個資料湖更新到數倉的過程,但是因為我們缺乏很好湖倉一體的系統沉澱,這個過程非常艱難,我們稱之這個過程為“登月”。大家可以從這個名字可見中間的艱難。在這個時間段,各個團隊甚至需要停下日常的自身業務發展來配合整理資料,把是以原來已有的資料分析過程,搬到統一一套數倉系統上面。最終我們曆經18個月,在花了非常大的代價,于2015年的12月完成建立了統一大資料倉庫平台建立,這就是阿裡巴巴的MaxCompute。通過這個統一數倉平台,無論是業務團隊、服務商家還是物流或其它環節都可以友善,迅捷,更好的挖掘商機。是以大家可以看到在阿裡巴巴統一的大資料平台完成後,業務成長也進入了快車道。這正是因為有更好的資料支撐,才使得商家、客戶都能快速的進行一些商業決策。

(2)  資料倉庫和資料湖的關系

從開發人員的角度看,資料湖更為靈活,更喜歡這種随心所欲的模式,任意的引擎都可以去讀、寫,沒有限制,啟動也非常容易。

從資料管理者角度看,資料湖能作為起步,但達到特定規模時,把資料當作資産或者需要做更大的商業決策的時候,都希望有一個很好的數倉。

離線實時一體化數倉與湖倉一體—雲原生大資料平台的持續演進

(3)  資料倉庫和資料湖系統的增長曲線

離線實時一體化數倉與湖倉一體—雲原生大資料平台的持續演進

上圖的增長曲線,基本上也是阿裡發展的曲線,最開始也是資料湖狀态,各個業務部門獨立發展,起步快、靈活性強。但當達到特定規模時,資料無人管理、每個業務部門的資料的邏輯語言不一緻,很難對齊。是以當時花了50%、80%的無效時間在校驗資料,随着規模的不斷擴大,這樣的損耗越來越大,迫使我們推動公司統一資料倉庫的建立。

(4)  湖倉一體

正是因為我們經曆過堪比“登月”的痛苦,是以我們不希望MaxCompute未來的企業客戶也經曆這麼痛苦過程,是以我們建構湖倉一體的開發平台。當公司規模較小的時候,可以運用資料湖能力更快定制自己的分析。公司成長到一定的階段,需要更好的資料管理和治理方式的時候,湖倉一體平台可以無縫把資料以及資料分析進行有效的更新管理,使得公司對于資料管理更加規範。這就是湖倉一體整體設計背後的核心思想。

離線實時一體化數倉與湖倉一體—雲原生大資料平台的持續演進

我們把湖的系統和倉的系統有機結合在一起,一開始是沒有中繼資料,你想要建立數倉的時候,我們有可以在湖上面來抽取這個中繼資料,這個中繼資料是和倉的中繼資料放在一個一體化的中繼資料的分析平台上面。在這個中繼資料之上可以建立很多資料倉庫的資料管理平台。

同時,在資料倉庫湖倉一體的平台上面,我們有效支援很多分析引擎,有任務型的計算引擎,包括像MaxCompute是批處理、Flink是流式處理、機器學習等,還有開源的元件可以分析我們的資料;也有服務性質資料引擎可以支援互動式查詢服務,能夠去更加實時性很好的展示我們的資料,進而使得使用者可以在這個服務性引擎上去建構自己資料服務應用。

在引擎之上我們建構豐富資料管理工具進而能夠讓業務部門能夠進行高效整體的資料治理。而這都得益于我們把湖和倉的資料打通,這也是整體湖倉一體設計的核心。

二、離線線上數倉一體化

現今社會越來越便捷,客戶需要更快的做出商業決策。在雙十一GMV實時大屏、春晚直播實時大屏等資料分析,以及機器學習從離線模型走向線上模型的趨勢中我們都可以看到。這些需求推動了實時數倉的發展。

其實實時數倉和離線數倉有着相似的發展過程。當時實時系統發展的早期,我們首先考慮的是引擎,因為隻有先有引擎了你才可以進行實時資料分析,是以阿裡巴巴把研發精力放在Flink這樣的流計算引擎上。但是隻有流計算引擎,類似資料湖的階段,我們缺乏将分析出來的結果資料進行管理,是以到了第二階段,我們利用我們離線數倉産品來管理這些分析結果,進而把分析結果納管到我們整體資料倉庫和資料管理中。但是把實時分析之後的結果放在離線數倉裡面,顯然這樣是對于實時商業決策是不夠的及時。是以我們現在發展第三個階段:實時數倉。

離線實時一體化數倉與湖倉一體—雲原生大資料平台的持續演進

我們會把流式引擎的分析結果結果實時的寫到實時數倉Hologres裡面,進而能夠讓分析的結果更實時的進行BI的分析,進而有效的支援客戶實時商業決策。

這就是離線和線上數倉一體化的設計。

離線實時一體化數倉與湖倉一體—雲原生大資料平台的持續演進

總結一下,原有的分析在離線和線上的數倉一體化之前是一個很紛繁的過程,有離線、有線上的、有很多不同的引擎,現在把它總結到或者簡化成上圖的架構。我們會用實時的引擎做預處理,做完預處理後,我們把這些資料寫入到MaxCompute離線的數倉,也可以同時寫入到Hologres實時數倉中裡面,進而可以做更加實時的服務化的BI分析。而MaxCompute離線的數倉存儲的成本更低,吞吐的性能更好,可以做大量的離線資料分析,這就是離線上數倉一體化的設計。

有了一體化的設計,就可以給客戶帶來一個非常平衡的系統。根據資料的場景或者是業務的場景,你可以用批處理。并且通過資料的壓縮、冷存,資料根據熱和冷的方式做不同梯度的存儲,就可以得到更低成本的離線分析。

當對于資料的實時性的價值更加重視,可以用流計算的引擎去做。同時又希望有很快的互動式,希望快速通過各種方式的、各種次元、角度去觀察已生成好的報表。這時候可以利用互動式引擎,在高度提純過資料後的進行各個次元的洞察。

希望用湖倉一體化平台就能夠達到一個好的平衡,根據實際的業務體量、要求、規模成本達到更好點。

離線實時一體化數倉與湖倉一體—雲原生大資料平台的持續演進

總的來說,希望湖倉一體系統上,不管是離線還是線上。通過不同的分析引擎,支援各類分析,同時通過線上服務型引擎能夠實時進行BI,能夠達到低成本、自定義能力,以及實時和線上服務的各種平衡。讓客戶能夠根據實際業務場景選擇。

三、智能數倉

有了統一的數倉平台,我們就可以在此之上建立強大的資料治理或者是分析平台,這個就是我們的DataWorks。在這個平台上面有很多資料模組化工具,提供資料的品質和标準、提供血緣的分析、提供程式設計助理等等。正是因為湖倉一體線上和離線的一體化的底座能力,才賦予了我們有這樣的可能性去做到大資料開發和治理平台更加智能化的方式。進而将更多經過驗證過有效資料治理經驗分享到我們企業客戶上。

離線實時一體化數倉與湖倉一體—雲原生大資料平台的持續演進

更多關于大資料計算、雲資料倉庫技術交流,歡迎掃碼檢視咨詢。

離線實時一體化數倉與湖倉一體—雲原生大資料平台的持續演進

繼續閱讀