mysql变更数据的捕获和入库

问题:涉及状态的信息,mysql中是update的,缺少中间状态的记录。数据分析中需要这部分数据。

思路:后端服务通过监控某张表的某个字段,根据mysql的binlog文件,还原数据,发送到kafka。我们消费kafka中的数据,最终在hive的ods层形成表更数据表。

方案设计

  1. java多线程消费kafka数据直接写入hdfs
    问题:
             (1)会在hdfs形成大量小文件
               (2)   要监控java程序,维护kafka偏移量等等
  2. spark streaming程序消费kafka实时写入hdfs
    问题:
             (1)想要支持断点续传,要自己维护kafka的偏移量
             (2)线上环境spark环境资源比较吃紧,spark streaming会持续占用较多资源
  3. 每天定时跑批量spark任务,读取kafka,写入hbase,hive上建立hbase映射表
    原因:
             (1)目前配置的hbase重复写入同一条数据会覆盖前一条,如果flume挂掉,任务可以重跑
             (2)可以挑选晚上资源比较充足的时候跑
    问题:
             (1)kafka中数据是持续写入的,所以spark程序不会自动停止,要手动停掉任务
               (2)  数据写在hbase中,hive的映射表实际读取的还是hbase的数据。所以使用时,最好将数据抽到hive中
  4. 通过flume消费kafka数据,写入hdfs
    最终选择这个方案,因为flume占用资源较少,实时处理的方式也能减少对机器的压力
    并且flume支持check point kafka的偏移量被记录在制定的文件中

方案4中需要注意的问题:

  1. 线上新的cdh中,缺少flume组件,需要刘亚萌配合
  2. 状态变更最多的sale表和balance表每天会有上千万表更记录,需要对集群的压力测试
  3. 由于需要用到flume的check point来支持断点续传,此种模式要将kafka的channel选为文件模式,将缓存数据存到磁盘。
    缓存文件有两部分,一部分是记录的偏移量,一部分是缓存到磁盘的实际数据,当batch.size达到我们设定的条数时,
    sink将开始数据写到hdfs中。
    (1)要考虑缓存占用的磁盘大小
    (2)要考虑hdfs小文件问题。
    因此要选择合适的batchd.size(数据条数)。尽量使缓存数据大于100m小于128m,让写到hdfs的每个文件和block大小相近。
  4. 数据写入hdfs后,需要通过脚本增加hive表的分区

待做:
          (1)调研flume使用snappy压缩格式传输
          (2)用双11的数据测试,选择agent个数
                 (如所有topic使用一个agent,每个库使用一个agent,每张表使用一个agent)
          (3)设定合理的batch size(如50000...)

当然最好可以让上游给我们提供文件,每份文件写到一个日期目录下,这样是最简单的方案。

上一篇:xml 解析 java 基础复习


下一篇:maven依赖查找方法