问题：涉及状态的信息，mysql中是update的，缺少中间状态的记录。数据分析中需要这部分数据。
思路：后端服务通过监控某张表的某个字段，根据mysql的binlog文件，还原数据，发送到kafka。我们消费kafka中的数据，最终在hive的ods层形成表更数据表。
方案设计：
- java多线程消费kafka数据直接写入hdfs
问题：
（1）会在hdfs形成大量小文件
(2) 要监控java程序，维护kafka偏移量等等 - spark streaming程序消费kafka实时写入hdfs
问题：
（1）想要支持断点续传，要自己维护kafka的偏移量
（2）线上环境spark环境资源比较吃紧，spark streaming会持续占用较多资源 - 每天定时跑批量spark任务，读取kafka，写入hbase，hive上建立hbase映射表
原因：
（1）目前配置的hbase重复写入同一条数据会覆盖前一条，如果flume挂掉，任务可以重跑
（2）可以挑选晚上资源比较充足的时候跑
问题：
（1）kafka中数据是持续写入的，所以spark程序不会自动停止，要手动停掉任务
(2) 数据写在hbase中，hive的映射表实际读取的还是hbase的数据。所以使用时，最好将数据抽到hive中 - 通过flume消费kafka数据，写入hdfs
最终选择这个方案，因为flume占用资源较少，实时处理的方式也能减少对机器的压力
并且flume支持check point kafka的偏移量被记录在制定的文件中
方案4中需要注意的问题：
- 线上新的cdh中，缺少flume组件，需要刘亚萌配合
- 状态变更最多的sale表和balance表每天会有上千万表更记录，需要对集群的压力测试
- 由于需要用到flume的check point来支持断点续传，此种模式要将kafka的channel选为文件模式，将缓存数据存到磁盘。
缓存文件有两部分，一部分是记录的偏移量，一部分是缓存到磁盘的实际数据，当batch.size达到我们设定的条数时，
sink将开始数据写到hdfs中。
（1）要考虑缓存占用的磁盘大小
（2）要考虑hdfs小文件问题。
因此要选择合适的batchd.size（数据条数）。尽量使缓存数据大于100m小于128m，让写到hdfs的每个文件和block大小相近。 - 数据写入hdfs后，需要通过脚本增加hive表的分区
待做：
（1）调研flume使用snappy压缩格式传输
（2）用双11的数据测试，选择agent个数
（如所有topic使用一个agent，每个库使用一个agent，每张表使用一个agent）
（3）设定合理的batch size（如50000...）
当然最好可以让上游给我们提供文件，每份文件写到一个日期目录下，这样是最简单的方案。