為能更好地服務使用者，DataPipeline版本支援：

1. 一個資料來源資料同時分發（實時或定時）到多個目的地；

2. 提升Hive的使用場景：

3. 定時同步關係型資料庫資料時，可自定義讀取策略來滿足各個表的同步增量需求。

本篇將首先介紹一下一對多資料分發及批次讀取模式2.0的功能，後續功能會在官微陸續釋出。

推出背景

推出「一對多資料分發」的背景

在歷史版本中，DataPipeline每個任務只允許有一個資料來源和目的地，從資料來源讀取的資料只允許寫入到一張目標表。這會導致無法完美地支援客戶的兩個需求場景：

需求場景一：

客戶從一個API資料來源或者從KafkaTopic獲取JSON資料後，透過高階清洗解析寫入到目的地多個表或者多個資料庫中，但歷史版本無法同時寫入到多個目的地，只能建立多個任務。這會導致資料來源端會重複獲取同一批資料（而且無法完全保證資料一致性），浪費資源，並且無法統一管理。

需求場景二：

客戶希望建立一個資料任務，並從一個關係型資料庫表實時（或定時）分發到多個資料目的地。在歷史版本中，使用者需要建立多個任務來解決，但建立多個任務執行該需求時會重複讀取資料來源同一張表的資料，比較浪費資源。客戶更希望只讀取一次便可直接解析為多個表，完成該需求場景。

新功能解決的問題：

1. 使用者在一個資料任務中選擇一個資料來源後，允許選擇多個目的地或者多個表作為寫入物件，而不需要建立多個任務來實現該需求。

2. 使用者在單個任務中針對每個目的地的型別和特性，可以單獨設定各個目的地表結構和寫入策略，大大減少了資料來源讀取次數和管理成本。

擴充套件Hive相關使用場景

歷史版本中，DataPipeline支援各型別資料來源資料同步到Hive目的地的需求場景。但由於每個客戶的Hive使用方式、資料儲存方式不同，兩個需求場景在歷史版本中並沒有得到支援。

需求場景一：

動態分割槽欄位。歷史版本中，使用者只允許選擇時間型別欄位作為分割槽欄位。在真實的客戶場景中除了按照時間做分割槽策略外，客戶希望指定Hive表任意欄位作為分割槽欄位。

需求場景二：

客戶希望除了以Hive作為目的地，定時寫入資料到Hive外，客戶還希望使用DataPipeline可以定時分發Hive表資料到各個應用系統，解決業務需求。

新功能解決的問題：

1. 允許使用者指定目的地Hive表中任何欄位作為分割槽欄位，並支援選擇多個分割槽欄位。

2. 新增Hive資料來源，可作為資料任務讀取物件。

推出「批次讀取模式2.0功能」的背景

需求場景：

關係型資料庫（以MySQL為例）的表沒有許可權讀取BINLOG，但在業務上客戶需要定期同步增量資料，在許可權只有SELECT情況下，需要做到增量資料的同步任務。

新版本出現之前，DataPipeline在使用者選擇批次讀取模式時提供了增量識別欄位的功能，可以選擇自增欄位或者更新時間欄位作為條件完成增量資料的同步，但部分表可能沒有這種型別的欄位，或者增量同步的邏輯不通（比如：只同步過去1小時的資料，或只同步到5分鐘前的資料等）。

新功能解決的問題：

1. 在關係型資料庫作為資料來源的情況下，允許使用者針對每一個表設定WHERE讀取條件，並提供lastmax方法。

2. 使用該函式DataPipeline會取該任務下已同步資料中某一個欄位的最大值，使用者可以使用該值作為WHERE語句讀取條件。

3. 使用者使用last_max（）函式，在首次執行該語句或對應欄位暫無數值時，則會忽略該函式相關的讀取條件。

4. 允許使用者結合其他資料庫提供的方法編輯讀取條件：

例：以時間欄位作為讀取條件，每次只同步一小時前的資料，且只同步未曾讀取的資料。

SELECT * FROMtable1 WHEREupdate_time > 'last_max(update_time)' ANDupdate_time<= DATE_SUB(NOW(), INTERVAL 24 HOUR)

相較於之前的一對一設定，新版本上線後使用者可以透過批次設定增量識別欄位、批次移除、批次修改表名稱等，批次地操作一些表，批次地做一些動態修改，減少使用者配置成本。例如，現在需要在200張表的名稱後面都加一個data_warehouse，不同於以往的逐一新增，現在可以批次新增這些字首字尾。

DataPipeline每一次版本的迭代都凝聚了團隊對企業資料使用需求的深入思索，其它新功能還在路上，很快就會跟大家見面了，希望能夠切實幫助大家更敏捷高效地獲取資料。

資料融合重磅功能丨一對多實時分發、批次讀取模式

相關文章