典型綜合場景數據流轉設計
綜合場景一 T+1數據加工
圖 4 T+1方式數據流轉
T+1是數據倉庫領域最爲常見的數據集成模式，T+1模式下數據倉庫會在每天固定時間點採集當天或者前一天交易系統數據。
根據數據類型，結構化數據來源一般爲RDB，需要將這些數據通過ETL工具全量或者增量導入到tdh的hdfs中，最後根據實際業務需求通過inceptor將數據寫入到對應的表中：
① sqoop/tdt支持全量/增量導入數據，可以裝載到hdfs中，tdt可以直接寫入orc表中。
② 需要做大量聚合分析的寫入orc表或者argodb表，有數據合併、刪除、修改操作的寫入orc事務表；高併發的精確查詢寫入hyperbase表；精確查詢、模糊查詢、多維度靈活組合查詢寫入Search表；
有時候，結構化數據可以通過原系統導出成文本，放在FTP或者其他文件系統，這種文本可以類似日誌、文檔等外部數據一樣，可以通過flume、Superput工具採集到HDFS，然後通過Inceptor寫入合適的存儲引擎。
例一：
oracle中的表 tableA，需要一次性的全量抽取全部數據，之後的業務需要對該表做精確查詢。這個時候選擇Transporter直接將數據錄入orc表中，之後根據業務的需求，將數據錄入hyperbase中。
例二：
oracle中的表tableA，該表每日有數據錄入，需要對該表的數據做統計分析。這個時候可以選擇sqoop對該表進行增量數據的抽取，放在HDFS上，之後通過inceptor將數據存入Argodb中，方便之後的統計分析。
例三：
每日的系統日誌文件，需要根據日誌進行ERROR的分析。選用flume對日誌的目錄進行數據採集，之後通過將數據存入Search中對日誌信息進行分詞，方便針對報錯信息的排查。
例四：
超大量的離線歷史數據文件，需要放入大數據平臺存儲。選用Superput將數據上傳進hdfs進行存儲。
綜合場景二 準實時數據同步
圖 5 準實時同步數據流轉
越來越多數據倉庫向準實時方向演進。
Oracle/DB2可以通過部署ogg/CDC+Transporter，實現準實時地將數據錄入到tdh集羣中，mysql特殊一些，可以基於binlog實現。之後根據業務需求參考上文圖三選擇合適的目標表：數據集市場景可以使用ArgoDB，高併發精確檢索使用Hyperbase，綜合搜索選擇Search。
例一：
Oracle中的數據需要準實時的將數據同步寫入大數據平臺中。搭建一套ogg+transporter的方式，可以將數據準實時的錄入到orc事務表中。
例二：
Mysql中的數據需要準實時的將數據同步寫入到大數據平臺中。這邊有很多的工具都可以直接將mysql數據同步到hdfs中，這邊推薦使用CDC或者MySQL Applier for Hadoop。
綜合場景三 實時流處理
圖 6 實時數據流轉
比較多的情況下實時數據通過kakfa接入，數據來源可以是kafka producer/flume等，經過slipstream的處理，之後根據實際業務需求，將數據入庫到TDH中
① 處理後的數據再次進入kafka，之後對數據在進一步處理，這樣的情況一般是kafka作爲數據總線的情況，不同的業務通過slipstream去不斷地和kafka進行數據上的交互
② 經過slipstream處理後錄入到Search/Hyperbase/Argodb的數據可以繼續通過Inceptor將表改變成其他格式，方便其他業務場景的需求，這時候就可以參考上文圖三選擇合適的目標表了。
例一：
實時數據通過kafka進來，需要在經過處理後把結果實時顯示在大屏上。這個時候的kafka擔任着數據總線的功能，數據從kafka接入，通過slipstream處理後再輸出給kafka。下游大屏顯示工具實時消費kafka數據。
例二：
實施數據通過kafka進來，對結果需要進行統計分析和批處理。可以通過Slipstream接入數據到hyperbase表，之後再通過inceptor或者Hyperbase API，將數據流轉到Inceptor ORC表中，從而滿足業務需求。
上面抽象的三種典型數據流轉綜合場景，其原理是非常一致的：數據通過工具接入，根據業務需求，選擇寫入合適的表。
實際項目中的數據流轉設計相關負責一些，數據源、客戶需求變化很多，但是萬變不離其宗，大家充分掌握平臺組件的技術特點和原理，並且深入理解客戶需求，再加以練習實踐，設計數據流轉其實並不難。
下面是一個經典的項目數據流轉方案，可以做爲練習和實踐的參考案例：
圖 7 經典數據流轉方案