點選免費下載下傳
《實時數倉技術入門一本通》>>>
也可在PC端打開
https://developer.aliyun.com/topic/download?id=961下載下傳
一、傳統資料庫痛點
傳統的資料倉庫開發方式，比如在一些使用者行為的分析，點選流的分析場景，一般來說是通過一些報表的形式去展現。這類分析背後往往需要很複雜的計算，需要計算引擎具備很強大的計算能力。另外一個場景，也是一個很強的資料驅動的場景，常見的像推薦系統的場景。推薦背後完全依賴對資料或者說對人的行為的了解，基于曆史行為的統計資訊，我們來智能化的推薦什麼事情是他當下最感興趣的。這類場景并不是傳統的分析場景，但它也是一個資料決策的場景，今天我們把它們放在一起，看一看我們的資料倉庫是如何支援不同的資料決策場景。
從行為分析到實時推薦，這兩者之間有一些關系。傳統的報表分析是一種查詢相對比較複雜，查的也比較快，要互動式體驗。但是對于實時推薦的場景，查詢往往更簡單，往往就是一張單表的查詢，但是對性能會非常的敏感，一般來說需要毫秒級響應。這兩件事過去往往是由不同的系統來做的。
傳統上，我們是如何做資料加工以及資料服務的呢？最常見的方式就是下圖所示，資料鍊路也左向右發展，有加工平台負責加工，結果資料導出到服務平台對外提供服務。這個架構在最開始應用的時候還是比較順利的，大部分公司裡面90%的場景下是這個架構。但是随着業務越來越多，越來越複雜，每天都有新的報表，每天都有新的業務場景，就會發現每一個業務調整的時候，都要從源頭一步步調整，包括表結構，加工腳本，曆史資料重刷等等，最後造成整個資料加工的鍊路會變得資料備援、成本高、開發周期長、甚至資料不一緻。于是我們就需要開始思考這個架構還能不能再有優化的空間，甚至是再簡化一些。
要解決上訴問題，可以看到市面上的選項大緻分為3個系統，以及它們之間的綜合。第一個是直接用事務系統做分析，Transaction類型，支援随機讀寫、事務、可靠，主要面向DBA。第二個系統是專業的分析系統，Analytics，适合大規模資料掃描、過濾、彙總，面向分析師。第三個系統是線上服務的系統，Serving，支援高并發、簡單、快速，面向API。三個系統各有擅長，最終落地解決問題的時候，往往多個系統一起使用，資料在系統間頻繁交換，也引起了剛剛提到的各種備援、複雜、不一緻的問題。
我們首先想到的是，能否一個系統支援盡量多的場景，簡化運維，少一些資料移動。
首先出現的是紅線和藍線交界部分，讓一個系統既可以支援分析，又可以支援事務，也就是我們常說的HTAP，它有一定的适用場景：
- 資料來源于業務系統（TP）
- 需要機制保證TP和AP的一緻性（資料、 模型，大量同步）
- 模型簡單，用于簡單分析場景。
- 局限是，事務系統的資料模型是無法直接用于分析場景的，資料需要被加工、抽象才能用于資料分析師。
再另一側，藍色和黃色交界的部分也有一個場景，分析和服務也可以做成一個系統，也有它的适用場景：
- 統一實時、離線存儲引擎
- 沒有事務需求，減少針對事務場景的開銷（鎖、同步）
- 埋點資料、機器資料，比TP高數量級
- 為多場景設計可複用數倉。
二、HSAP：服務分析一體化
我們提出HSAP（Hybrid Serving & Analytics Processing）的理念，目标做到服務分析一體化，背後的技術挑戰是非常大的：首先，離線資料和實時資料都要支援。然後我們希望資料是統一的，不要把實時和離線割裂。也希望接口是統一的，提供一套統一的接口。我們可以看到SQL接口相對來說是現在市面上表達能力最強的一種查詢語言，是以我們認為在HSAP這種理念下，如果重新做一個系統，它應該支援統一的查詢接口，一般是SQL，統一的通路控制；然後統一的存儲，實時、離線都可以存在這樣一個系統裡。
三、實時數倉：Hologres
Hologres是針對HSAP場景設計的系統，它支援資料以離線和實時的方式，從業務系統、日志系統進入Hologres。進入過程中，一種是批量導入，這種方式的資料量是很大的。另一部分實時資料會通過Flink實時計算，通過計算前置的方式，把一些計算邏輯規則通過Flink提前算好，比如流資料關聯，視窗加工，輕度彙總等，然後把計算結果存在Hologres的表裡面，然後通過Hologres作為一個服務平台對接應用層，不管是一個多元分析的報表，還是一個實時推薦的應用，都可以支撐服務。
為了實作實時和離線的一體化，Hologres與MaxCompute做到了底層打通，Hologres隸屬MaxCompute産品家族，這兩個産品合在一起為使用者提供實時、離線一體化的解決方案。資料在Hologres和MaxCompute之間以一種原生的方式互相打通，互相可以查詢對方的資料，互相可以看到對方的表，互相可以有很簡單的方式做一些資料的遷移。
上面提到Hologres既能支援分析，又能支援服務。這是因為Hologres底層會有兩種不同的存儲模式：行存和列存
，這也就意味着我們既能支援查詢的量大，又能支援查的快。下圖是Hologres行存和列存兩種模式下的對比：
同時，下面也可以給大家分享Hologres與Druid的性能對比（對比基于TPC-H 測試集），可以從圖中直覺的看到Hologres絕大多數場景下性能更優。
Hologres的另外一個場景是Serving場景，主要是對标HBase。我們看到，在同等的硬體條件下，99%的查詢延遲Hologres相對來說都是非常的穩定，小于一微秒。而對于HBase來說，查詢延遲随着吞吐量的變高，延遲有很大的擴大。Hologres的定位是同時支援分析和服務兩個場景，同時我們也有信心把這兩個場景做的都比隻做一個場景的那些過去的系統做得更好。對于一個新技術而言，必須要有更高的要求。
現在絕大多數業務都是用HBase來做服務的場景，在Hologres裡使用行存表的效果是優于HBase的。這邊給大家比較Hologres和HBase的一些差異點，主要關注紅色的部分：
1）看産品定位和高層設計
2）存儲引擎和查詢引擎的差異
3）擴充性，運維，生态，适用場景，以及開發方式的差異
四、典型應用案例
下面可以來介紹Hologres落地具體業務場景的最佳實踐。
1）阿裡巴巴搜尋推薦實時分析和算法應用
阿裡淘寶系列裡邊實時的搜尋推薦的場景下，也在使用Hologres和MaxCompute的組合。一方面資料量非常的大，我們會首先基于MaxCompute建立整個離線的數倉，它能夠處理離線全量的資料，有調動幾百上千台機器這樣并發的能力。其次推薦場景下，也是對實時要求非常高的。推薦場景的業務方會很關心使用者目前對什麼産品感興趣，目前搜尋什麼樣的關鍵詞，目前是通過什麼網絡、通過什麼裝置、在什麼地域連接配接了淘寶的一個系統等資訊。一些實時特征都會影響搜尋的一個結果，對實時特征的計算也非常的重要，是以需要有一個實時數倉的場景，通過Flink加工，把這些實時資訊加工成使用者和商品的一些特征，然後對接應用使用。最後加工的結果一部分面向分析師，一部分面向機器學習。根據剛才學到的一些知識，我們知道要完成全部的場景會利用到Hologres的列存，也會利用行存。
列存的場景，一般是面向報表的場景，一般會把我們的資料結果變成我們的資料産品，提供給我們的分析師。分析師選擇相關的次元做一些過濾組合，得到相關的一些轉化率。這相當于是把我們的資料産品作為一種服務。
2）友盟
友盟+是國内最大的移動應用統計服務商，其統計分析産品U-App&U-Mini & U-Web為開發者提供基本報表統計及自定義使用者行為分析服務，支援精細化營運。業務痛點包括：
- 業務資料量大，年新增行為資料10PB級， 個性化、自定義地互動式使用者行為分析強需 求；
- 基于MaxCompute提供異步離線的adhoc 分析和優化、以及自研引擎開發嘗試均無法 滿足業務需求 ；
- 導出到mysql/Hbase方案的二次開發和數 據導對外連結路長、成本高、操作不靈活。
在使用Hologres和MaxCompute後，客戶得到的收益包括：
- PB級資料毫秒級查詢響應
- 與MaxCompute深度內建，能夠利用range cluster索引加速，實時離線聯邦查詢，同時也可以實作冷熱資料混合查詢，有利于成本性能平衡。
- 計算資源彈性伸縮，可兼顧擴充性、穩定性、 性能、成本。
3）菜鳥的智能物流
菜鳥智能物流分析引擎是基于搜尋架建構設的物流查詢平台，日均處理包裹事件幾十億，承載了菜鳥物流資料的大部分處理任務。客戶的需求包括：
- HBase的架構下維表資料導入耗時長、資源浪 費嚴重、成本高
- HBase不能同時滿足PointQuery和OLAP分 析，資料導入導出引發資料孤島、資料同步負 擔、備援存儲、運維成本和資料不一緻等問題。
在引入Hologres互動式分析後，客戶得到的收益包括：
- 整體硬體資源成本下降60%+
- 更快的全鍊路處理速度（2億記錄端到端3分鐘）
- 一個系統，滿KV和OLAP兩個場景，沒有資料 備援
- 解決大維表實時SQL查詢需求
- 強Schema，有效避免潛在錯誤，節省時間。
4）實時推薦場合
剛才講的幾個場景，都是偏分析的場景。這邊給大家介紹一個推薦的服務的場景。這個場景是實時推薦（特征查詢、實時名額計算、向量檢索召回），提高廣告留存率，用到的主要技術有PAI+Hologres(with Proxima)。客戶收益包括：
支援2000萬日活使用者快速向量檢索，千萬級u2u，i2i均可以20ms傳回
通過SQL描述業務邏輯，無需手工編碼
加工邏輯簡化，無需額外叢集。
這是一個很典型的把資料作為服務的場景。而且資料并沒有離開我們的資料平台，還是在我們這套數倉平台裡面，還是以表的形式，是以在運維上、開發效率上都會提升很多。
五、MaxCompute+Hologres最佳實踐
通過上訴典型場景的應用，有些人可能就會有些疑問，是不是就不需要MaxCompute了呢？答案是否定的。其實MaxCompute和Hologres是最好的搭檔。這兩個産品在技術架構定位場景上是有些差異的，如下圖所示，兩個放在一起可以實作最好的效果。
最後給大家講一下MaxCompute和Hologres怎麼放在一起，實作最好的一個加工服務一體化的效果。一般來講，數倉分層為ODS、DWD、DWS、ADS，如圖所示。下面兩層放在MaxCompute是比較好的，上面兩層可以放在Hologres。總的來說，有如下特點：
- 面向主題的開發，提供可複用的數倉模型
- 加工服務一體化：減少資料移動，減少資料孤島
- 數倉模組化靈活化：減少資料層次，靈活适應需求變化，面向DWS、DWD的應用開發。
一般來講，在Hologres中加速查詢MaxCompute有兩種方式：
- 建立外表（資料還是存儲在MaxCompute中），性能會有2-5倍的提升
- 導入内表，性能相比外表大約有10-100倍的提升
當我們設計的數倉，想要它跑的快，至少做好兩件事：查詢引擎優化和索引設計優化
直接查外表的方式實際上是利用查詢引擎的優化能力來提高效率的，但是沒有利用到索引能力。是以當把外表導到内表的時候，可以根據查詢的方式指定内表的索引結構。通過這些索引能力帶來更高的查詢性能。這就是外表導入内表，内表的性能更好的原因，就是要充分發揮數倉裡邊索引優化的能力。