文章实时采集(忙数据库数据同步到数据仓库的事情，不涉及具体细节)

　　文章实时采集(忙数据库数据同步到数据仓库的事情，不涉及具体细节)

　　上个月一直在忙着把数据库数据同步到数据仓库。我现在应该可以简单说一下，不涉及具体细节，纯粹是记录我们团队的所作所为。

　　背景

　　数据仓库的分层建模理论中有一层数据叫做ODS（Operational Data Store），它往往存储原创业务层数据，不做任何处理。这一层的数据来源很多，但大部分都会有来自业务数据库的数据。来自业务数据库采集的数据，然后导入HDFS，现在是数据仓库的重要组成部分。

　　来自业务数据库采集的数据分为两种形式：

　　通过JDBC协议，使用select *方式从数据库中提取所有数据并同步到HDFS。数据格式可以转成文本然后以Load的形式导入，也可以直接通过DataX、Sqoop等数据传输工具登陆HDFS。数据库将数据更改消息发送到某个消息中间件，然后使用某个流处理工具将数据更改消息一一重现。

　　第一种方法的实现简单，但缺点也很明显：

　　如果选择第二种方式，实现比较复杂，目前HDFS上层计算引擎大多不支持数据更新、删除等SQL原语，导致需要分布式数据库（参考文章:) 或者使用CDC（Change Data Capture）+merge方法（参考文章:）。

　　遇到的困难

　　在我们的团队中，一些数据是直接从外部系统访问的。它只提供某种形式的数据更新消息，类似于MySQL的binlog，但是使用的协议完全不同，细节不详。消息收录四种不同的数据更新操作：插入（插入一条新数据）、非主键更新（根据主键更新一条数据的非主键字段）、主键更新（更新一条数据的主键字段基于主键））和delete（删除一条数据）。

　　之前我们使用 Kudu 来接受这部分数据：使用 Spark Streaming 从 Kafka 中一一读取数据，对 Kudu 中的数据进行插入、非主键更新、删除、主键更新等操作。数据更新操作。主键更新操作比较复杂，分为四个步骤：将旧主键数据读入内存，更新内存中旧主键数据，删除旧主键数据，插入新主键数据。

　　当数据量很小的时候，所有的问题都不是问题。当数据量很大的时候，尤其是主键更新的消息很多的时候，上面描述的过程就有问题了。例如，每次主键更新都需要与 Kudu 交互四次。

　　所以我们参考美团的文章实现CDC（Change Data Capture）+merge来处理数据。

　　同步

　　目前网上所有的文章都只提到了插入、非主键更新和删除的操作，但是对于主键和非主键的一些字段的更新并没有很好的答案。而这也是本月工作的核心。读者可以思考如何处理主键更新操作，以及如何更新一些不是主键的字段。

　　经验

　　经过一个多月的努力，这项工作即将结束，为此增加了很多课程。目前我们注意到，主流分布式数据库在遇到数百亿表的实时更新操作时，仍然存在很多问题，尤其是消息中大量的主键更新操作。与流处理相比，成熟的批量计算引擎和HDFS存储在遇到*敏*感*词*数据处理时更加可靠。