點選免費下載下傳
《實時數倉技術入門一本通》>>>
也可在PC端打開
https://developer.aliyun.com/topic/download?id=961下載下傳
一、Hologres生态
從前面幾篇的内容，相信大家已經了解到Hologres是一款相容PostgreSQL協定的實時互動式分析産品。在生态的相容性上，Hologres有着非常龐大的生态家族，如下圖所示，
- 對于開源大資料領域，Hologres支援當下最流行的大資料開源元件，其中包括
- 對于埋點類資料，支援Blink/Flink/Spark/資料內建等大資料工具進行高性能的實時導入和批量導入
- 對于資料庫類的資料，通過和Dataworks資料內建（DataX和StreamX）共建實作友善高效的資料庫整庫實時鏡像到Hologres中，并滿足金融企業對可管理性、監控、網絡等的需求
無論是實時資料，還是離線資料接入Hologres之後，接下來就能使用Hologres對資料進行分析。最常見的就是使用JDBC或者ODBC對資料進行查詢、分析、監控，然後承接上遊的業務，比如說大屏、報表、應用等各種場景。
同時再為大家介紹一下DataWorks，它是阿裡雲的一個資料開發平台，提供了資料內建、資料地圖、資料服務等功能。資料內建主要功能可以将資料庫的資料導入Hologres，其中同步的方式包括離線同步和實時同步，離線同步支援幾十種異構資料源同步至Hologres，而實時同步目前主要支援以下幾種：
- Mysql Binlog：通過訂閱Biblog的方式将mysql資料實時寫入Hologres
- Oracle CDC：全稱是Change Data Capture，也是一個類似Mysql Binlog的用來擷取Oracle表change log的方式
- Datahub：是阿裡巴巴自研的一個分布式高性能消息隊列，值得一提的是，Datahub自身也提供了直接将資料實時導入至Hologres的功能，無需經過Dataworks
- PolarDB：是阿裡巴巴自主研發的關系型分布式雲原生資料庫
二、Hologres實時導入接口介紹
接下來為大家介紹一下Hologres提供的一個實時導入的接口，以及接口的技術原理。
1）實時導入接口
Hologres實時導入接口的具備以下特性：
- 行存&列存都支援
- 支援根據主鍵去重 (Exactly once)
- 支援整行資料局部更新
- 導入即可見，毫秒級延遲
- 單Core 2W+ RPS (TPCH PartSupp表)
- 性能随資源線性擴充
- 支援分區表寫入
2）實時導入原理
實時導入的原理如下圖所示，首先我們看一下該圖的最上面的幾個節點，代表了資料的上遊，也就是業務層。如何将資料導入Hologres，主要有兩種場景：
- 使用SQL進行資料的導入（最常見）
例如使用JDBC執行insert語句，該insert語句會經過一個負載均衡伺服器路由分發至我們的Frontend節點，對該insert語句進行SQL的解析優化，然後生成一個優化後的執行計劃，并将該執行計劃分發至後端的worker節點。worker節點收到該執行計劃之後，就會将該資料完成寫入。
- Connector寫入
另外一條鍊路為左邊的Private API鍊路，也就是目前Apache Flink或者Apache Spark Connector所使用的Hologres的實時導入接口。該Private API提供的資料接口和普通sql請求不一樣，而是我們稱之為Fixed Plan的請求接口，這些請求被分發至負載均衡伺服器之後，負載均衡伺服器會将資料路由分發至一個叫做Private API Service的節點。該節點将資料寫入請求分發至worker節點，也就是後端的節點。當worker節點收到，無論是Fixed Plan，還是執行計劃之後，會對資料進行持久化，最終資料完成寫入。
接着來更進一步了解Private API Service的一個資料分發功能。如下圖所示，一張表的資料分布在多個Shard上，一條記錄隻會屬于一個Shard，根據Distribution key屬性進行Hash。
當實時寫入的資料請求到達後端的worker節點之後，worker節點是怎麼處理的。如下圖所示，這一塊有如下特點：
- Log Structured Merge Tree(LSM)
- 全異步架構，協程(Coroutine)
- 基于Masstree的Memtable
同時上面也提到通過SQL來進行資料的寫入是最常見的場景，Hologres也在後端優化了整個SQL的寫傳入連結路。例如對于Insert into values，Insert into on conflict do update，Select from where pk = xxx等場景簡單的SQL，Hologres會進行優化，減少SQL的解析和優化過程，提升整個資料寫入和查詢的性能。
三、Hologres實時讀寫場景
前面介紹了Hologres通過connector寫的原理，下面将會介紹Flink+Hologres最常見的寫入場景。
1）實時寫入場景
最常見的第一種就是實時寫入場景。實時寫入分為幾種。
- 第一種，Hologres的結果表沒有設定主鍵，這樣Flink實時接入就是一種Append Only的模式進行寫入。當上遊資料發生重複，或者Flink任務作業失敗，上遊資料會需要進行回溯，這時候下遊資料錄入到Hologres中就會産生重複的資料。這種情形對于日志型資料是比較合理的，因為使用者并不需要關心資料是否需要進行去重
- 第二種，Hologres的結果表設定了主鍵。Flink或者其它實時寫入就會按照行的主鍵進行更新。主鍵更新的意思就是說對于相同主鍵的兩行資料，後到的資料會完全覆寫掉之前已經到達的資料。
- 第三種，是按照主鍵去重。就是說後到的資料會被忽略掉，隻保留最早到的一條記錄。這種場景使用者并不關心主鍵的更新情況，隻需要保證主鍵的去重。
2）寬表Merge場景
例如一個使用者的結果表有非常多的字段，會有上百列，而該表的許多字段可能同時分布在不同的資料上遊，例如，Column C和D分布在一個kafka的topic A上面，Column E和F分布在kafka的topic B上面，使用者希望消費兩個kafka topic，并将資料merge成Hologres的一張結構表。最常見的解決辦法是，進行流場景的一個雙流Join。這種實作對于開發人員來說相對比較複雜，需要實作一個雙流Join，而且理論上來說會對計算資源要求非常大，也加劇了運維人員的負擔。
而Hologres針對這種場景是如何實作的呢？
Hologres支援局部更新的功能。如下圖所示，按照這種實作方式，隻需要兩個流各自寫入Hologres結果表。第一個流消費ABCD四個字段，将資料寫入到最終的結果表中。第二個流消費ABEF四個字段，最終将資料寫入到結果表，并不需要進行雙流的Join，最終Hologres會自己進行一個資料的組裝。第一個流寫入ABCD的時候并不會去更新已經存在的EF字段，同樣，第二個流寫入ABEF字段的時候，C和D字段已經存在，不會被更新，最終達到完整的一個資料Merge的功能。使用這種功能，可以大大提升流作業的開發效率，以及減少流作業所需要的資源消耗，也能夠更容易的維護各個流作業。
3）實時維表Join場景
除了寫場景，Hologres也支援讀場景，最常見的是使用Hologres的行存表來進行點查。如下圖所示，是一個實時維表的Join場景。主要邏輯是生成一個資料源，會不停的生成一個資料流，和Hologres的維表進行Join，打寬資料流，最終将資料寫入到一個結果表中。在實際業務中，這種使用場景通常會用來替換HBase，以達到更好的性能和更低的成本。
4）Hologres Binlog場景
如下圖所示，以消息隊列方式讀取Hologres資料的Change log。 其中：
- Binlog系統字段，表示Binlog序号，Shard内部單調遞增不保證連續，不同Shard之間不保證唯一和有序
- Binlog系統字段，表示目前 Record 所表示的修改類型
- UPDATE操作會産生兩條Binlog記錄，一條更新前，一條更新後的。訂閱Binlog功能會保證這兩條記錄是連續的且更新前的Binlog記錄在前，更新後的Binlog記錄在後