隨着企業應用複雜性的上升和微服務架構的流行，數據正變得越來越以應用爲中心。
服務之間僅在必要時以接口或者消息隊列方式進行數據交互，從而避免了構建單一數據庫集羣來支撐不斷增長的業務需要。以應用爲中心的數據持久化架構，在帶來可伸縮性好處的同時，也給數據的融合計算帶來了障礙。
由於數據散落在不同的數據庫、消息隊列、文件系統中，計算平臺如果直接訪問這些數據，會遇到可訪問性和數據傳輸延遲等問題。在一些場景下，計算平臺直接訪問應用系統數據庫會對系統吞吐造成顯著影響，通常也是不被允許的。
因此，在進行跨應用的數據融合計算時，首先需要將數據從孤立的數據源中採集出來，彙集到可被計算平臺高效訪問的目的地，此過程被稱爲 ETL，即數據的抽取（Extract）、轉換（Transform）和加載（Load）。
ETL 並不是什麼新鮮事物。
該領域的傳統公司，例如 Informatica，早在 1993 年就已經成立，並且提供了成熟的商業化解決方案。開源工具，例如 Kettle、DataX 等，在很多企業中也得到了廣泛的應用。
【大數據開發學習資料領取方式】：加入大數據技術學習交流羣458345782，點擊加入羣聊，私信管理員即可免費領取
傳統上，ETL 是通過批量作業完成的。即定期從數據源加載（增量）數據，按照轉換邏輯進行處理，並寫入目的地。根據業務需要和計算能力的不同，批量處理的延時通常從天到分鐘級不等。在一些應用場景下，例如電子商務網站的商品索引更新，ETL 需要儘可能短的延遲，這就出現了實時 ETL 的需求。
在實時 ETL 中，數據源和數據目的地之間彷彿由管道連接在一起。數據從源端產生後，以極低的延遲被採集、加工，並寫入目的地，整個過程沒有明顯的處理批次邊界。
實時 ETL，又被稱爲 Data Pipeline 模式。
阿里在 2018 年提出了“數據中臺”的概念。即數據被統一採集，規範數據語義和業務口徑形成企業基礎數據模型，提供統一的分析查詢和新業務的數據對接能力。
數據中臺並不是新的顛覆式技術，而是一種企業數據資產管理和應用方法學，涵蓋了數據集成、數據質量管理、元數據 + 主數據管理、數倉建模、支持高併發訪問的數據服務接口層開發等內容。
在數據中臺建設中，結合企業自身的業務需求特點，架構和功能可能各不相同，但其中一個最基本的需求是數據採集的實時性和完整性。數據從源端產生，到被採集到數據彙集層的時間要儘可能短，至少應做到秒級延遲，這樣中臺的數據模型更新纔可能做到近實時，構建在中臺之上依賴實時數據流驅動的應用（例如商品推薦、欺詐檢測等）才能夠滿足業務的需求。
以阿里雙十一爲例，在極高的併發情況下，訂單產生到大屏統計數據更新延遲不能超過 5s，一般在 2s 內。
中臺對外提供的數據應該是完整的，源端數據的 Create、Update 和 Delete 都要能夠被捕獲，不能少也不能多，即數據需要有端到端一致性的能力（Exactly Once Semantic，EOS）。
當然，EOS 並非在任何業務場景下都需要，但從平臺角度必須具備這種能力，並且允許用戶根據業務需求靈活開啓和關閉。
在構建實時數據集成平臺時，就一些技術選型問題，建議做以下考量：
一、數據源變化捕獲
源數據變化捕獲是數據集成的起點，獲取數據源變化主要有三種方式：
基於日誌的解析模式；
基於增量條件查詢模式；
數據源主動 Push 模式。
基於日誌的解析模式常用於各種類型的數據庫，例如 MySQL 的 Binlog、Oracle 的 Redo&Achieve Log、SQL Server Change Tracking & CDC 等。
不同數據庫日誌解析的原理差別很大，以 MySQL Binlog 模式爲例，解析程序本身是一個 Slave，能夠實時收到 MySQL Master 的數據流推送，並解析還原成 DDL 和 DML 操作。而 SQL Server 的 CT 模式下，增量是通過定期查詢 Change Tracking 表實現的。
基於增量條件的查詢模式不依賴於源端開啓日誌記錄，但對於數據源通常有額外的格式要求。例如，數據庫表或文檔對象需要有標誌更新時間的字段，這在一些業務系統中是無法滿足的。
數據源主動 Push 模式的常見形式爲業務插碼，即應用系統通過打點或者配置切面的方式，將數據變化封裝爲事件，額外發送一份給數據集成平臺。這種方式一般需要對源端系統代碼進行一定程度的修改。
通常而言，基於數據庫的日誌進行增量捕獲應當被優先考慮。其具備以下幾個顯著優點：
能夠完整獲取數據變化的操作類型，尤其是 Delete 操作，這是增量條件查詢模式很難做到的；
不依賴特別的數據字段語義，例如更新時間；
多數情況下具備較強的實時性。
當然，事物都具有兩面性。開啓數據庫日誌通常會對源庫性能產生一定的影響，需要額外的存儲空間，甚至一些解析方法也會對源庫資源造成額外消耗。因此，實施過程中需要在 DBA 的配合下，根據數據庫特點和解析原理進行 DB 部署規劃。
推薦使用數據庫的複製和災備能力，在獨立服務器對從庫進行日誌解析。此外，當數據庫產生批量更新時，會在短時間內產生大量日誌堆積，如果日誌留存策略設置不當，容易出現數據丟失。這些都需要根據具體的業務數據增長特點，在前期做好規劃，並在上線後根據業務變化定期進行評估和調整。
數據源主動 push 模式下，由於事件發送和業務處理很難做到事務一致性，所以當出現異常時，數據一致性就無從保證，比較適合對於數據一致性要求不高的場景，例如用戶行爲分析。
二、運行環境
無論採用何種數據變化捕獲技術，程序必須在一個可靠的平臺運行。該平臺需要解決分佈式系統的一些共性問題，主要包括：水平擴展、容錯、進度管理等。
1. 水平擴展
程序必須能夠以分佈式 job 的形式在集羣中運行，從而允許在業務增長時通過增加運行時節點的方式實現擴展。
因爲在一個規模化的企業中，通常要同時運行成百上千的 job。隨着業務的增長，job 的數量以及 job 的負載還有可能持續增長。
2. 容錯
分佈式運行環境的執行節點可能因爲過載、網絡連通性等原因無法正常工作。
當節點出現問題時，運行環境需要能夠及時監測到，並將問題節點上的 job 分配給健康的節點繼續運行。
3. 進度管理
job 需要記錄自身處理的進度，避免重複處理數據。另外，job 會因爲上下游系統的問題、網絡連通性、程序 bug 等各種原因異常中止，當 job 重啓後，必須能夠從上次記錄的正常進度位置開始處理後繼的數據。
有許多優秀的開源框架都可以滿足上述要求，包括 Kafka Connect、Spark、Flink 等。
Kafka Connect 是一個專注數據進出 Kafka 的數據集成框架。Spark 和 Flink 則更爲通用，既可以用於數據集成，也適用於更加複雜的應用場景，例如機器學習的模型訓練和流式計算。
就數據集成這一應用場景而言，不同框架的概念是非常類似的。
首先，框架提供 Source Connector 接口封裝對數據源的訪問。應用開發者基於這一接口開發適配特定數據源的 Connector，實現數據抽取邏輯和進度（offset）更新邏輯。
其次，框架提供一個分佈式的 Connector 運行環境，處理任務的分發、容錯和進度更新等問題。
不同之處在於，Kafka Connect 總是將數據抽取到 Kafka，而對於 Spark 和 Flink，Source Connector 是將數據抽取到內存中構建對象，寫入目的地是由程序邏輯定義的，包括但不限於消息隊列。
但無論採用何種框架，都建議首先將數據寫入一個彙集層，通常是 Kafka 這樣的消息隊列。
單就數據源採集而言，Kafka Connect 這樣專注於數據集成的框架是有一定優勢的，這主要體現在兩方面：
首先是 Connector 的豐富程度，幾乎所有較爲流行的數據庫、對象存儲、文件系統都有開源的 Connector 實現。
尤其在數據庫的 CDC 方面，有 Debezium 這樣優秀的開源項目存在，降低了應用的成本。
其次是開發的便捷性，專有框架的設計相較於通用框架更爲簡潔，開發新的 Connector 門檻較低。Kafka Connect 的 runtime 實現也較爲輕量，出現框架級別問題時 debug 也比較便捷。
儘管目前版本的 Kafka Connect 還不支持數據採集後進入 Kafka 的 EOS 保證，但通過對 runtime 的修改，利用 Kafka 事務消息也能夠實現這一點。相信 Kafka Connect 未來的版本也會很快提供官方的支持。
三、數據彙集層
當各類數據從源端抽取後，首先應當被寫入一個數據彙集層，然後再進行後繼的轉換處理，直至將最終結果寫入目的地。數據彙集層的作用主要有兩點：
首先，數據彙集層將異構的數據源數據存儲爲統一的格式，並且爲後繼的處理提供一致的訪問接口。這就將處理邏輯和數據源解耦開來，同時屏蔽了數據抽取過程中可能發生的異常對後繼作業的影響。
其次，數據彙集層獨立於數據源，可被多次訪問，亦可根據業務需要緩存全部或一定期限的原始數據，這爲轉換分析提供了更高的靈活度。當業務需求發生變化時，無需重複讀取源端數據，直接基於數據彙集層就可以開發新的模型和應用。數據彙集層可基於任意支持海量 / 高可用的文件系統、數據倉庫或者消息隊列構建，常見的方案包括 HDFS、HBase、Kafka 等。
針對實時 ETL 場景，推薦使用 Kafka 或類似具有海量數據持久化能力的消息隊列來做數據彙集層，這會爲後繼的流式處理提供便捷。同時，利用 Kafka 的數據回收機制，可以根據業務需要自動保留一定時間或大小的原始數據。
四、數據轉換
數據轉換是一個業務性很強的處理步驟。
當數據進入彙集層後，一般會用於兩個典型的後繼處理場景：數倉構建和數據流服務。
數倉構建包括模型定義和預計算兩部分。數據工程師根據業務分析需要，使用星型或雪花模型設計數據倉庫結構，利用數據倉庫中間件完成模型構建和更新。
開源領域，Apache Kylin 是預聚合模式 OLAP 代表，支持從 HIVE、Kafka、HDFS 等數據源加載原始表數據，並通過 Spark/MR 來完成 CUBE 構建和更新。
Druid 則是另一類預聚合 OLAP 的代表。在 Druid 的表結構模型中，分爲時間列、維度列和指標列，允許對任意指標列進行聚合計算而無需定義維度數量。Druid 在數據存儲時便可對數據進行聚合操作，這使得其更新延遲可以做到很低。在這些方面，Baidu 開源的 Palo 和 Druid 有類似之處。
一個普遍的共識是，沒有一個 OLAP 引擎能同時在數據量，靈活性和性能這三個方面做到完美，用戶需要基於自己的需求進行取捨和選型。預計算模式的 OLAP 引擎在查詢響應時間上相較於 MPP 引擎（Impala、SparkSQL、Presto 等）有一定優勢，但相對限制了靈活性。
如前文所述，源端採集的數據建議放入一個彙集層，優選是類似 Kafka 這樣的消息隊列。包括 Kylin 和 Druid 在內的數據倉庫可以直接以流式的方式消費數據進行更新。
一種常見的情形爲：原始採集的數據格式、粒度不一定滿足數據倉庫中表結構的需要，而數倉提供的配置靈活度可能又不足夠。這種情況下需要在進入數倉前對數據做額外的處理。
常見的處理包括過濾、字段替換、嵌套結構一拆多、維度填充等，以上皆爲無狀態的轉換。有狀態的轉換，例如 SUM、COUNT 等，在此過程中較少被使用，因爲數倉本身就提供了這些聚合能力。
數據流服務的構建則是基於流式計算引擎，對彙集層的數據進一步加工計算，並將結果實時輸出給下游應用系統。這涉及到流式計算引擎的選擇：Spark Streaming、Flink、還是 Kafka Streams？
關於三個引擎的對比，網上有很多資料，在此不再贅述。
選型過程中有幾點值得特別關注：
1. 延遲性
Spark 對流的支持是 MicroBatch，提供的是亞秒級的延遲，相較於 Flink 和 Kafka Streams 在實時性上要差一些。
2. 應用模式
Spark 和 Flink 都是將作業提交到計算集羣上運行，需要搭建專屬的運行環境。
Kafka Streams 的作業是以普通 Java 程序方式運行，本質上是一個調用 Kafka Streaming API 的 Kafka Consumer，可以方便地嵌入各種應用。
但相應的，用戶需要自己解決作業程序在不同服務器上的分發問題，例如通過 K8s 集羣方案進行應用的容器化部署。如果使用 KSQL，還需要部署 KSQL 的集羣。
3. SQL 支持
三者都提供 Streaming SQL，但 Flink 的 SQL 支持要更爲強大些，可以運行更加複雜的分組聚合操作。
4. EOS
Flink 對於數據進出計算集羣提供了框架級別的支持，這是通過結合 CheckPoint 機制和 Sink Connector 接口封裝的二階段提交協議實現的。
Kafka Streams 利用 Kafka 事務性消息，可以實現“消費 - 計算 - 寫入 Kafka“的 EOS，但當結果需要輸出到 Kafka 以外的目的地時，還需要利用 Kafka Connect 的 Sink Connector。
遺憾的是，Kafka Connect 不提供 Kafka 到其它類型 Sink 的 EOS 保證，需要用戶自己實現。
Spark Streaming 與 Kafka Streams 類似，在讀取和計算過程中可以保證 EOS，但將結果輸出到外部時，依然需要額外做一些工作來確保數據一致性。常見的方式包括：利用數據庫的事務寫入機制將 Offset 持久化到外部、利用主鍵保證冪等寫入、參考二階段提交協議做分佈式事務等。
小 結
本文簡要討論了一些構建面向實時數據的集成平臺在技術選型方面的考量點。
數據源變化捕獲是數據集成的起點，結合日誌的解析、增量條件查詢模式和數據源主動 Push 模式，最終構建出一個數據彙集層。在這個階段，推薦考慮 Kafka Connect 這類面向數據集成的專有框架，可以有效縮短研發週期和成本。
數據彙集層建議構建在消息隊列之上，爲後繼的加工處理提供便利。如果需要全量持久化長期保存，建議結合使用消息隊列和分佈式文件系統分別做實時數據和全量數據的存儲。
流式處理能力是實時數據集成平臺必要的組件。結合企業技術棧特點，選用包括 Flink、Spark Streaming、Kafka Streams 等流行的引擎在多數情況下都能夠滿足要求。
端到端數據的 EOS 是數據集成中的一個難題，需要用戶根據業務實際需求、數據本身的特性、目的地特點 case by case 去解決。