在4月21日的Kafka Beijing Meetup第四場活動上，DataPipeline CTO陳肅分享了DataPipeline是如何基於Kafka Connect框架構建實時資料整合平臺的應用實踐。以下內容是基於現場錄音整理的文字，供大家參考。
什麼是資料整合？最簡單的應用場景就是：一個資料來源，一個資料目的地，資料目的地可以是個資料倉儲，把關係型資料庫的資料同步到資料倉儲裡，就形成了一次資料整合。
企業資料整合面臨的4個挑戰
我們先來看一個真實的資料整合案例。
G公司是DataPipeline的一個典型客戶，擁有近千個資料來源，型別主要包括Oracle、SQL Server、MySQL等。根據業務的需要和現有的基礎設施情況，這些資料來源分別需要同步到不同的目的端，型別主要包括MySQL、HDFS、Kafka等。基於以上背景，G公司的具體要求如下：
1. 需要支援約5TB日新增資料量的同步，今年將增長5-10倍。
2. 這些資料一部分資料來源要求實時同步，另一部分可接受定時同步。
3. 缺乏強大的運維人才，現有資料來源的業務承載壓力有限，對壓力非常的敏感，要求進行限流。
4. 從這些資料來源到目的地的同步都是Kettle寫指令碼實現的，管理起來比較混亂，要求透過一個管理平臺對任務進行集中化的配置和管理。
5. 上游的資料來源和下游的資料目的都不穩定，隨時可能出現各種問題，要求透過一個高可用的平臺以減少資料傳輸中斷的影響。
6. 當資料同步任務被隨機的暫停/恢復時，要求可以保證資料的完整性。
7. 當資料來源和目的地隨機出現故障和過載時，要求可以保證資料的完整性。
8. 當資料來源Schema發生變化時，要求可以根據業務需求靈活配置目的地策略。
G公司的案例只是當前企業資料整合需求的一個典型應用場景。事實上，無論是網際網路企業還是傳統企業，在面臨資料整合的時候都會遇到以下4個挑戰：
1. 資料來源的異構性：傳統ETL方案中，從資料來源到目的地的同步都是指令碼實現的，異構資料來源就意味著企業要做大量的適配工作。
2. 資料來源的動態性：在資料整合時，上游的資料來源端經常會發生各種變化，有些資料來源可能被刪掉一些結構，這可能會影響到後續資料分析的結果。
3. 任務的可伸縮性：當資料整合只有幾個資料來源，系統壓力的問題不太突出。當資料整合面臨的是成百上千個資料來源時，多工並行就需要進行一些限速與緩衝的排程，讓讀寫速度相互匹配。
4. 任務的容錯性：當資料在傳輸過程中出現問題的時候，是否可以實現斷點重傳，且不產生重複的資料。
以上也是DataPipeline要為企業資料整合過程中解決的最關鍵的4個問題。
為什麼選擇Kafka Connect作為底層框架
Kafka Connect是一種用於在Kafka和其他系統之間可擴充套件的、可靠的流式傳輸資料的工具，可以更快捷和簡單地將大量資料集合移入和移出Kafka的聯結器。Kafka Connect為DataPipeline提供了一個相對成熟穩定的基礎框架，還提供了一些開箱即用的工具，大大地降低研發的投入和提升應用的質量。
下面，我們看一看Kafka Connect的具體優勢。
首先，Kafka Connect提供的是以資料管道為中心的業務抽象。在Kafka Connect裡有兩個核心概念：Source和Sink。Source負責匯入資料到Kafka，Sink負責從Kafka匯出資料，它們都被稱為Connector。比如Source Connector，Sink Connector，其實就是提供了資料讀取和寫入的高度業務抽象，可以簡化很多生命週期的管理工作。
當然，Source Connector會去初始化Source Task，Sink Connector會去初始化Sink Task。這些都是標準的封裝。對於資料方面，透過Source & Sink Record把資料的結構進行標準化的抽象。另外，企業客戶在做資料整合的時候，資料在很多應用場景下都要求有一定的格式，所以在Kafka Connect裡用Schema Registry & Projector來解決資料格式驗證和相容性的問題。當資料來源產生變化的時候，會生成新的Schema版本，透過不同的處理策略用Projector來完成對資料格式的相容。
第二，Kafka Connect具有良好的可伸縮性、與容錯性。這些特性是與Kafka是一脈相承的。在流式處理和批次處理模式裡，更多取決於Source端如何去讀取資料，Kafka Connect天然支援流式處理和批次傳輸方式。單節點和叢集水平擴充套件功能都是由Kafka Connect框架直接支援。而任務恢復和狀態保持方面，目的端任務的寫入進度資訊透過Kafka Connect框架自動管理、源端任務可以根據需要往Kafka裡面放讀取進度資訊，節省很多精力去管理任務重啟後的進度。
對於資料整合這樣一個通用的應用場景裡，大家肯定都不希望重複發明輪子。目前，在Kafka Connect生態系統下，擁有可以直接使用的Connector共84個，絕大部分都是開源的。其中，一部分是Kafka官方提供的，另外一些是Confluent認證的，還有一些是第三方提供的。根據需求適當裁剪後，這些Connector都可以應用到自己的系統平臺中。
DataPipeline解決哪些資料整合的核心難題
基於Kafka Connect 框架，DataPipeline已經完成了很多最佳化和提升工作，可以很好地解決當前企業資料整合面臨的很多核心難題。
1. 任務的獨立性與全域性性。
從Kafka設計之初，就遵從從源端到目的的解耦性。下游可以有很多個Consumer，如果不是具有這種解耦性，消費端很難擴充套件。企業做資料整合任務的時候，需要源端到目的端的協同性，因為企業最終希望把握的是從源端到目的端的資料同步擁有一個可控的週期，並能夠持續保持增量同步。在這個過程中，源端和目的端相互獨立的話，會帶來一個問題，源端和目的端速度不匹配，一快一慢，造成資料堆積現象嚴重。所以，企業使用者在建立一個資料任務之後，我們希望對任務進行緩衝的控制，避免資料丟失。
2. 任務並行化的方式。
如果企業客戶有1000張資料表需要建立資料整合的任務，就要考慮用什麼方式進行任務切分最佳。其中一種方式是把1000張表切分成若干個任務。這種情況下，Source Task的負載很難做到均衡，Sink Task可以消費多個Topics，依然存在負載不均的問題，每個任務負載多少張表其實是很難均衡的。每增加一個任務都會觸發Rebalance機制。可以想象，每一張表都透過Source Connector和Sink Connector初始化一個源端和目的端任務，會大大增加Rebalance的開銷。
3. 異構資料的對映。
在給企業客戶做資料整合的時候，50%機率都會遇到一些髒活累活——異構資料來源的對映（Mapping）。這個對映對很多網際網路公司來說不是那麼嚴重什麼事兒，因為資料庫設計的都比較符合規範，對欄位的命名方式等都會比較“優雅”（統一）。但是在傳統企業裡，由於很多業務系統都會外包，還有一些意識的原因，導致資料庫設計的沒有那麼規範和統一。用Kafka Connect做資料整合的時候，需要儘可能做到異構資料精準的還原，尤其金融行業客戶對此要求比較高。另外，當確實遇到資料之間不匹配的情況時，可以在業務資料之間進行比較合理的對映。
另外，源端的Source Record包含了每一列的基本資料型別（INT16、STRING等）以及可選的meta資訊（例如“name”）。目的端處理Sink Record的時候，需要依據基本資料型別以及meta資訊決定對映關係。
4. Schema變化的處理策略。
給企業做資料整合的時候，需要根據資料來源Schema的變化給出對應的處理策略。基於Kafka Connect框架，我們提供了以下幾種處理策略：
（1）Backward Compatibility：可使用最新的Schema一致訪問所有資料，e.g. 刪除列、新增具有預設值的列。
（2）Forward Compatibility：可使用最舊的Schema一致訪問所有資料，e.g. 刪除具有預設值的列。
（3）Full Compatibility：可任意使用新舊Schema訪問所有資料。
Kafka Connect推薦使用Backward Compatibility，這也是Schema Registry的預設值。另外，企業使用者還會提出源端刪除列，目的端需要忽略，源端新增具有預設值列，目的端需要跟隨等需求，都以Task為單位進行配置和實現。
DataPipeline基於Kafka Connect做了哪些提升
在不斷滿足當前企業客戶資料整合需求的同時，DataPipeline也基於Kafka Connect 框架做了很多非常重要的提升。
1. 系統架構層面。
DataPipeline引入DataPipeline Manager的概念，主要用於最佳化Source和Sink的全域性化生命週期管理。當任務出現異常時，可以實現對目的端和全域性生命週期的管理。例如，處理源端到目的端讀取速率不匹配以及暫停等狀態的協同。
為了加強系統的健壯性，我們把Connector任務的引數儲存在ZooKeeper中，方便任務重啟後讀取配置資訊。
DataPipeline Connector透過JMX Client將統計資訊上報Dashboard。在Connector中在技術上進行一些封裝，把一些通用資訊，比如說Connector歷史讀取資訊，跟管理相關的資訊都採集到Dashboard裡面，提供給客戶。
2. 任務並行模式。
DataPipeline在任務並行方面做了一些加強。我們在具體服務客戶的時候也遇到這樣的問題，需要同步數十張表。在DataPipeline Connector中，我們允許每個Task內部可以定義和維護一個執行緒池，透過控制執行緒併發數，並且每個Task允許設定行級別的IO控制。而對於JDBC型別的Task，我們額外允許配置連線池的大小，減少上游和下游資源的開銷。
3. 規則引擎。
DataPipeline在基於Kafka Connect做應用時的基本定位是資料整合。資料整合過程中，不應當對資料進行大量的計算，但是又不可避免地要對一些欄位進行過濾，所以在產品中我們也在考慮怎樣提供一種融合性。
雖然Kafka Connect提供了一個Transformation介面可以與Source Connector和Sink Connector進行協同，對資料進行基本的轉換。但這是以Connector為基本單位的，企業客戶需要編譯後部署到所有叢集的節點，並且缺乏良好的視覺化動態編譯除錯環境支援。
基於這種情況，DataPipeline產品提供了兩種視覺化配置環境：基本編碼引擎（Basic Code Engine）和高階編碼引擎（Advanced Code Engine）。前者提供包括欄位過濾、欄位替換和欄位忽略等功能，後者基於Groovy可以更加靈活地對資料處理、並且校驗處理結果的Schema一致性。對於高階編碼引擎，DataPipeline還提供了資料取樣和動態除錯能力。
4. 錯誤佇列機制。
我們在服務企業客戶的過程中也看到，使用者源端的資料永遠不會很“乾淨”。不“乾淨”的資料可能來自幾個方面，比如當檔案型別資料來源中的“髒記錄”、規則引擎處理特定資料產生未預期的異常、因為目的端Schema不匹配導致某些值無法寫入等各種原因。
面對這些情況，企業客戶要麼把任務停下來，要麼把資料暫存到某處後續再處理。而DataPipeline採取的是第二種方式，透過產品中錯誤佇列預警功能指定面對錯誤佇列的策略，支援預警和中斷策略的設定和實施等，比如錯誤佇列達到某個百分比的時候任務會暫停，這樣的設定可以保證任務不會因少量異常資料而中斷，被完整記錄下來的異常資料可以被管理員非常方便地進行追蹤、排查和處理。企業客戶認為，相比以前透過日誌來篩查異常資料，這種錯誤佇列視覺化設定功能大大提升管理員的工作效率。
在做資料整合的過程中，確實不應該對原始資料本身做過多的變換和計算。傳統ETL方案把資料進行大量的變換之後，雖然會產生比較高效的輸出結果，但是當使用者業務需求發生變化時，還需要重新建立一個資料管道再進行一次原始資料的傳輸。這種做法並不適應當前大資料分析的需求。
基於這種考慮，DataPipeline會建議客戶先做少量的清洗，儘量保持資料的原貌。但是，這並不是說，我們不重視資料質量。未來的重要工作之一，DataPipeline將基於Kafka Streaming將流式計算用於資料質量管理，它不對資料最終輸出的結果負責，而是從業務角度去分析資料在交換過程中是否發生了改變，透過滑動視窗去判斷到底資料發生了什麼問題，判斷條件是是否超出一定比例歷史均值的記錄數，一旦達到這個條件將進一步觸發告警並暫停同步任務。
總結一下，DataPipeline經過不斷地努力，很好地解決了企業資料整合過程需要解決異構性、動態性、可伸縮性和容錯性等方面的問題；基於Kafka Connect的良好基礎支撐構建了成熟的企業級資料整合平臺；基於Kafka Connect進行二次封裝和擴充套件，最佳化了應用Kafka Connect時面臨的挑戰：包括Schema對映和演進，任務並行策略和全域性化管理等。未來，Datapipeline將會基於流式計算進一步加強資料質量管理。