典型综合场景数据流转设计
综合场景一 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 经典数据流转方案