導讀： 作爲現代企業和組織機構的重要資源，信息是進行科學管理與決策分析的基礎。ETL 則是把數據轉換爲信息、知識的關鍵步驟之一。在 AI 應用場景下，數據集成有哪些特點？隨着 AI 應用場景越來越多，爲什麼我們需要從 ETL 轉換到 ELT？又會遇到哪些問題和挑戰？
本週三，陳肅博士與我們分享了《從 ETL 到 ELT——AI 時代數據集成的問題與解決方案》，AI 前線將分享內容整理成文，方便大家回顧參考。
大家好！很高興今天有機會和大家分享一些數據集成方面的看法和應用經驗。先自我介紹一下。我叫陳肅，博士畢業於中國科學院大學，數據挖掘研究方向。現在北京數見科技（DataPipeline）任 CTO。之前曾經在中國移動研究院任職算法工程師和用戶行爲實驗室技術經理，之後作爲合夥人加入過一家互聯網教育公司，從事智能學習方面的研發工作。
在畢業後工作的這多年以來，我大部分時候在做大數據和機器學習相關的應用系統研發工作，數據的整合是其中一個非常重要的環節。加入 DataPipeline 後，公司研發的是一款企業級的數據集成產品，旨在幫助企業一站式解決數據集成和元數據管理問題。
ELT 和 ETL 是數據集成的兩種基本方式。前者專注於大數據的實時抽取和可靠傳輸，後者則包含了更豐富的數據轉換功能。 由於今天是和 AI 前線的朋友們一起探討數據集成，我主要結合 AI 應用的場景談談：爲什麼 ELT 是更適合 AI 應用場景的數據集成方案、採用 Kafka 技術棧來構建 ELT 平臺所具備的優勢和問題以及我們所做的一些優化工作。希望能夠對大家的工作和學習有所幫助。
今天我的分享主要內容如上圖：
首先，我會介紹一下 AI 應用中數據集成的典型場景，ETL 和 ELT 兩種數據集成模式的異同點，以及爲什麼 AI 應用下更適合採用 ELT 模式。然後，我會花一些篇幅介紹數據集成中需要重點考慮的基本問題，以及我們所採用的底層平臺——Kafka Connect 在解決這些問題上的優勢和侷限。
接下來，我會介紹 DataPipeline 對於 Kafka Connect 一些優化。有的是從底層做的優化，例如線程池的優化。有的則是從產品特性上的優化，例如錯誤數據隊列。
最後，我們談一談 Kafka Connect 和 Kafka Stream 的結合，以及我們用 Kafka Stream 做數據質量預警方面的一個應用 Case。
一、AI 應用場景下的數據集成
數據集成是把不同來源、格式、特點性質的數據在邏輯上或物理上有機地集中，爲企業提供全面的數據共享。AI 是典型的數據驅動應用，數據集成在其中起着關鍵的基礎性作用。
以一個大家所熟悉的在線推薦服務爲例，通常需要依賴三類數據：用戶的屬性 (年齡、性別、地域、註冊時間等）、商品的屬性（分類、價格、描述等）、用戶產生的各類行爲（登錄、點擊、搜索、加購物車、購買、評論、點贊、收藏、加好友、發私信等）事件數據。
隨着微服務框架的流行，這三類數據通常會存在於不同的微服務中：“用戶管理服務”儲存着用戶的屬性、好友關係、登錄等數據；“商品管理服務”存儲的商品信息；“訂單服務”存儲着用戶的訂單數據；“支付服務”存儲用戶的支付數據；“評論服務”記錄着用戶的評論和點贊數據。爲了實現一個推薦服務，我們首先需要讓服務能夠訪問到這些數據。這種數據訪問應該是非侵入式的，也就是說不能對原有系統的性能、穩定性、安全性造成額外的負擔。因此，推薦服務不應當直接訪問這些分散的數據源，而是應該通過某種方式將這些數據從各個業務子系統中提取出來，彙集到一個邏輯上集中的數據庫 / 倉庫，然後才能方便地使用機器學習框架（例如 Spark MLlib）來讀取數據、訓練和更新模型。
ETL 和 ELT 的區別與聯繫
數據集成包含三個基本的環節：Extract（抽取）、Transform（轉換）、Load（加載）。
抽取是將數據從已有的數據源中提取出來，例如通過 JDBC/Binlog 方式獲取 MySQL 數據庫的增量數據；轉換是對原始數據進行處理，例如將用戶屬性中的手機號替換爲匿名的唯一 ID、計算每個用戶對商品的平均打分、計算每個商品的購買數量、將 B 表的數據填充到 A 表中形成新的寬表等；加載是將數據寫入目的地。
根據轉換轉換髮生的順序和位置，數據集成可以分爲 ETL 和 ELT 兩種模式。ETL 在數據源抽取後首先進行轉換，然後將轉換的結果寫入目的地。ELT 則是在抽取後將結果先寫入目的地，然後由下游應用利用數據庫的聚合分析能力或者外部計算框架，例如 Spark 來完成轉換的步驟。
爲什麼 ELT 更適合 AI 應用場景
爲什麼說 ELT 更適合 AI 的應用場景呢？
首先這是由 AI 應用對數據轉換的高度靈活性需求決定的。 絕大多數 AI 應用使用的算法模型都包括一個特徵提取和變換的過程。根據算法的不同，這個特徵提取可能是特徵矩陣的簡單的歸一化或平滑處理，也可以是用 Aggregation 函數或 One-Hot 編碼進行維度特徵的擴充，甚至特徵提取本身也需要用到其它模型的輸出結果。這使得 AI 模型很難直接利用 ETL 工具內建的轉換功能，來完成特徵提取步驟。此外，企業現在很少會從零構建 AI 應用。當應用包括 Spark/Flink MLlib 在內的機器學習框架時，內建的模型庫本身往往包含了特徵提取和變換的邏輯，這使得在數據提取階段就做複雜變換的必要性進一步降低；
其次，企業經常會基於同樣的數據構建不同應用。 以我之前所在的一家在線教育公司爲例，我們構建了兩個 AI 的應用：其中一個是針對各類課程的推薦應用，主要用於增加用戶的購買轉化率。另外一個是自適應學習系統，用於評估用戶的知識掌握程度和題目的難度和區分度，從而爲用戶動態地規劃學習路徑。兩個應用都需要用戶屬性、做題記錄、點擊行爲以及學習資料文本，但採用的具體模型的特徵提取和處理方式完全不同。如果用 ETL 模式，我們需要從源端抽取兩遍數據。而採用 ELT 模式，所有數據存儲在 HBase 中，不同的應用根據模型需要過濾提取出所需的數據子集，在 Spark 集羣完成相應的特徵提取和模型計算，降低了對源端的依賴和訪問頻次；
最後，主流的機器學習框架，例如 Spark MLlib 和 Flink MLlib，對於分佈式、並行化和容錯都有良好的支持，並且易於進行節點擴容。 採用 ELT 模式，我們可以避免構建一個專有數據轉換集羣（可能還伴隨着昂貴的 ETL 產品 License 費用），而是用一個通用的、易於創建和維護的分佈式計算集羣來完成所有的工作，有利於降低總體擁有成本，同時提升系統的可維護性和擴展性。
二、從 ETL 和 ELT 面臨的主要問題
採用 ELT 模式，意味着可以較少的關注數據集成過程中的複雜轉換，而將重點放在讓數據儘快地傳輸上。然而，一些共性的問題依然需要得到解決:
1. 數據源的異構性： 傳統 ETL 方案中，企業要通過 ETL 工具或者編寫腳本的方式來完成數據源到目的地同步工作。當數據源異構的時候，需要特別考慮 Schema（可以簡單理解爲數據字段類型）兼容性帶來的影響。無論是 ETL 還是 ELT，都需要解決這一問題。
2. 數據源的動態性： 動態性有兩方面含義。一是如何獲取數據源的增量；二是如何應對數據源端的 Schema 變化，例如增加列和刪除列。
3. 任務的可伸縮性： 當面對少量幾個數據源，數據增量不過每日幾百 MB 的時候，ELT 平臺的可伸縮性不是什麼大問題。當 ELT 面對的是成百上千個數據源，或者數據源數據增速很快時，ELT 平臺的任務水平切分和多任務並行處理就成爲一個必備的要求。平臺不僅要支持單節點的多任務並行，還需要支持節點的水平擴展。此外，ELT 的上游通常會遇到一些吞吐能力較差的數據源，需要能夠對讀取進行限速，避免對現有業務產生影響。
4. 任務的容錯性：ELT 平臺某些節點出現故障的時候，失敗的作業必須能夠遷移到健康的節點上繼續工作。同時，作業的恢復需要實現斷點重傳，至少不能出現丟失數據，最好能夠做到不產生重複的數據。
三、Kafka Connect 的架構
Kafka Connect：基於 Kafka 的 ELT 框架
可用於構建 ELT 的開源數據集成平臺方案不止一種，較廣泛採用的包括 Kafka Connect、DataX 等，也有公司直接採用 Flink 等流式計算框架。DataPipeline 作爲一家提供企業數據集成產品的公司，我們在 Kafka Connect 之上踩了許多坑並且也做了許多優化。
四、踩過的坑與優化的點
Kafka Connect 應用於 ELT 的關鍵問題 1
下面我們聊一聊 Kafka Connect 應用過程中的幾個關鍵問題。
首先是 任務的限速和數據緩存問題。從 Kafka Connect 設計之初，就遵從從源端到目的地解耦性。當 Source 的寫入速度長時間大於 Sink 端的消費速度時，就會產生 Kafka 隊列中消息的堆積。如果 Kafka 的 Topic Retention 參數設置不當，有可能會造成數據在消費前被回收，造成數據丟失。Kafka Connect 框架本身並沒有提供 Connector 級別的限速措施，需要進行二次開發。
Kafka Connect 應用於 ELT 的關鍵問題 2
當用戶有多個數據源，或者單一數據源中有大量的表需要進行並行同步時，任務的並行化問題 就產生了。Kafka Connect 的 rebalance 是牽一髮動全身，一個新任務的開始和停止都會導致所有任務的 reload。當任務數很多的時候，整個 Kafka Connect 集羣可能陷入長達數分鐘的 rebalance 過程。
解決的方法，一是用 CDC（Change Data Capture）來捕獲全局的數據增量；二是 在任務內部引入多線程輪詢機制，減少任務數量並提高資源利用率。
Kafka Connect 應用於 ELT 的關鍵問題 3
異構數據源同步會遇到 Schema 不匹配 的問題。在需要精確同步的場景下（例如金融機構的異構數據庫同步），通常需要 Case by Case 的去定義映射規則。而在 AI 應用場景下，這個問題並不是很突出，模型訓練對於損失一點精度通常是可容忍的，一些數據庫獨有的類型也不常用。
Kafka Connect 應用於 ELT 的關鍵問題 4
Source 端需要能夠檢測到 Schema 的變化，從而生成具有正確 Schema 格式的 Source Record。CDC 模式下，通過解析 DDL 語句可以獲取到。非 CDC 模式下，需要保存一個快照才能夠獲取到這種變化。
下面我用一些時間對 DataPipeline 所做的優化和產品特性方面的工作。
DataPipeline 是一個底層使用 Kafka Connect 框架的 ELT 產品。首先，我們在底層上引入了 Manager 來進行全局化的任務管理。Manager 負責管理 Source Connector 和 Sink Connector 的生命週期，與 Kafka Connect 的管理 API 通過 REST 進行交互。
系統的任何運行異常，都會進行統一的處理，並由通知中心發送給任務的負責人和運維工程師。我們還提供了一個 Dashboard，用於圖形化方式對任務進行生命週期管理、檢索和狀態監控。用戶可以告別 Kafka Connect 的命令行。
DataPipeline 的任務並行模型
DataPipeline 在任務並行方面做了一些加強。在 DataPipeline Connector 中，我們在每個 Task 內部定義和維護一個線程池，從而能夠用較少的 Task 數量達到比較高的並行度，降低了 rebalance 的開銷。 而對於 JDBC 類型的 Connector，我們額外允許配置連接池的大小，減少上游和下游資源的開銷。此外，每個 Connector 還可以定義自己限速策略，以適應不同的應用環境需求。
DataPipeline 的錯誤隊列機制
通過產品中錯誤隊列預警功能，用戶可以指定面對錯誤數據暫存和處理邏輯，比如錯誤隊列達到某個百分比的時候任務會暫停，這樣的設置可以保證任務不會因少量異常數據而中斷，被完整記錄下來的異常數據可以被管理員非常方便地進行追蹤、排查和處理。
相比以前通過日誌來篩查異常數據，這種錯誤隊列可視化功能能夠大大提升管理員的工作效率。
DataPipeline 的數據轉換
DataPipeline 實現了自己的 動態加載機制。提供了兩種 可視化的轉換器：基本轉換器和高級轉換器。前者提供包括字段過濾、字段替換和字段忽略等功能；後者基於 Java，可以更加靈活地對數據處理，並且校驗處理結果的 Schema 一致性。DataPipeline 還提供了數據採樣和動態調試能力，方便用戶進行表級別的轉換規則開發。
值得注意的是，Kafka 不僅僅是一個消息隊列系統，本身也提供了持久化能力。一個很自然的問題就是：能否不額外引入 Sink 端的外部存儲，直接從 Kafka 中獲取訓練數據？
如果模型本身要用到某個 Topic 的全量數據或者最近一段時間的數據，那麼通過設置合適的 retention 參數，可以直接將 Kafka 作爲訓練數據的來源。Kafka 的順序讀模式可以提供非常高的讀取速度；如果模型要根據消息的內容做數據篩選，那麼由於 Kafka 本身並不提供檢索能力，需要遍歷所有消息，這樣就顯得比較低效了。
當模型用於線上時，可能還需要引入流式計算來完成實時特徵的提取工作。Kafka 本身就提供了這種流式計算能力。
流式計算在 ELT 中的作用 - 數據質量預警
DataPipeline 也將流式計算引入到平臺的質量預警功能中。在我們的未來版本中，用戶可以定義 Topic 級別的質量預警規則模型，例如“在 5 分鐘時間內，數據記錄的字段 1 均值超過歷史均值記錄的比率超過 70%”爲異常，採取策略爲“告警並暫停同步”。通過這種方式，可以在 ELT 的過程中，儘早發現數據中的異常現象，避免大量異常數據進入數據目的地。
五、總結與展望
最後總結一下。數據集成並不是什麼新的概念，在過去二十多年間已經廣泛應用於各個行業的信息系統。ELT 和 ETL 相比，最大的區別是“重抽取和加載，輕轉換”，從而可以用更簡單的技術棧、更輕量的方案搭建起一個滿足現代企業應用的數據集成平臺。AI 應用內在的特點也使得 ELT 特別適合這個場景。
Kafka Connect 本身是一個業界被廣泛採用的 ELT 框架，針對容錯、分佈式、Schema 一致性等方面都提供了良好的支持，同時有大量的社區和商業資源可供參考和選擇。DataPipeline 基於 Kafka Connect 做了大量數據集成場景下的優化，與 Kafka Stream 相結合，能夠爲包括 AI 在內的各種應用場景構建起一個完整的數據層支撐方案。
有其它關於數據集成的技術問題，也歡迎一起探討、共同提高。
參考資料
How to Build and Deploy Scalable Machine Learning in Production with Apache Kafka
https://www.confluent.io/blog/
Kafka Connect 官方文檔
https://docs.confluent.io/current/connect/index.html
Machine Learning + Kafka Streams Examples
https://github.com/kaiwaehner
PredictionIO- 基於 Spark 的機器學習框架
http://predictionio.apache.org
Q & A
Q1：DataPipeline 避開了數據處理這個過程，並以此提高性能，這個思路很認可。但是有個問題：從數據生產到數據利用的環節中，總要有一步數據處理的步驟的，這個步驟，從產品角度，DataPipeline 是如何考慮的？
A1：ELT 的核心思想就是要利用下游數據存儲性能大幅提升和機器學習應用的靈活性的優勢，在數據流轉的過程中不做過於複雜的計算。如果真的需要做處理，也可以基於我們的產品可以去寫轉換的代碼。但這種處理都是無狀態的。有狀態處理，建議放到下游去做。這樣才更符合 ELT 的理念。
Q2：請問數據的落地是自動的嗎？
A2： 基於原生 Kafka Connector，需要命令行啓動目標端類型的 Sink Connector，指定消費的 topic 列表，通過代碼完成數據落地。基於 DataPipeline 產品，通過界面配置源和目的地後，落地是完全自動的。
Q3：多線程讀，對源端的數據表或用戶權限有沒有特定的要求？
A3：JDBC 模式的 Source Connector 使用的 RDBMS 用戶，需要具有選擇同步表的 select 權限。CDC 模式的各不相同，參照產品內詳盡的權限配置說明。
Q4：如何保證生產和消費的 EOS 剛好一次語義？
A4： Kafka Connect 下的 Exactly Once Semantic 依賴於具體 Connector 實現，Kafka Connect 框架本身對此只提供了必要非充分的支持。我們先來看 Source 端：假定 Source Connector 是從 MySQL 的 Binlog 中抽取數據到 Kafka，爲了實現 EOS，首先 Source Connector 在每次提交記錄到 Kafka 的時候，需要原子化的記錄下來對應的 binlog position，這樣才能保證任務異常中斷、重啓後能夠從這個 position 繼續讀取。Kafka Connect 框架在 Source 端封裝了 offset storage 的存儲更新邏輯。offset storage 本質上是一個 Kafka 的 topic，利用 Kafka 的事務機制，理論上可以保證 offset 的修改和消息發送的原子性。再來看 Sink 端：如果 Sink Connector 可以將數據的輸出和 Offset 的記錄進行原子化操作，那麼同理也能夠做到 EOS。但這個原子化操作需要 Sink 端自己用某種機制實現，例如 Confluent 的 HDFS Connector 就用 WAL 日誌保證了寫入的 EOS。