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

簡介：阿里雲智慧研究員林偉：阿里巴巴從湖到倉的演進給我們帶來了湖倉一體的思考，使得湖的靈活性、資料種類豐富與倉的可成長性和企業級管理得到有機融合，這是阿里巴巴最佳實踐的寶貴資產，是大資料的新一代架構。

林偉，阿里雲智慧研究員、阿里雲智慧通用計算平臺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。在這個平臺上面有很多資料建模工具，提供資料的質量和標準、提供血緣的分析、提供程式設計助理等等。正是因為湖倉一體線上和離線的一體化的底座能力，才賦予了我們有這樣的可能性去做到大資料開發和治理平臺更加智慧化的方式。從而將更多經過驗證過有效資料治理經驗分享到我們企業客戶上。