Hadoop数仓建设之数据同步

💗大数据道漫漫，其修远兮，今天继续我们数仓建设的第三篇文章，关于数据同步的知识，没有看过前面文章的同学可以参考下面的链接👇：

第一篇: Hadoop之数据仓库概述.
第二篇: hadoop数仓建设之日志采集.

💐数仓的数据同步在数仓中的重要性不言而喻，数据同步通俗的解释就是不同系统间的数据流转，数据备份，数据传输交换等等。

1.数据同步基础

源业务系统的数据类型多种多样，有来源于关系型数据库的结构化数据，如 MySQL 、Oracle 、DB2、SQL Server 等；也有来源于非关系型数据库的非结构化数据，如 OceanBase、HBase、MongoDB 等，这类数据通常存储在数据库表中；还有来源于文件系统的结构化或非结构化数据，如阿里云对象存储 oss、文件存储 NAS 等，这类数据通常以文件形式进行存储。数据同步需要针对不同的数据类型及业务场景选择不同的同步方式。总的来说，同步方式可以分为三种：直连同步、数据文件同步和数据库日志解析同步。

1.1 直连同步

直连同步是指通过定义好的规范接口API 和基于动态链接库的方式直接连接业务库，如 ODBC/JDBC 等规定了统一规范的标准接口，不同的数据库基于这套标准接口提供规范的驱动，支持完全相同的函数调用和 SQL 实现。

这种方式配置简单，实现容易，比较适合操作型业务系统的数据同步。但是业务库直连的方式对源系统的性能影响较大，当执行大批量数据同步时会降低甚至拖垮业务系统的性能。如果业务库采取主备策略，则可以从备库抽取数据，避免对业务系统产生性能影响。但是当数据量较大时，采取此种抽取方式性能较差，不太适合从业务系统到数据仓库系统的同步。

1.2 数据文件同步

数据文件同步通过约定好的文件编码、大小、格式等，直接从源系统生成数据的文本文件，由专门的文件服务器，如 FTP 服务器传输到目标系统后，加载到目标数据库系统中。当数据源包含多个异构的数据库系统(如 MySQL、 Oracle、 SQL Server、 DB2 等)时，用这种方式比较简单、实用。另外，互联网的日志类数据，通常是以文本文件形式存在的，也适合使用数据文件同步方式。

由于通过文件服务器上传、下载可能会造成丢包或错误，为了确保数据文件同步的完整性，通常除了上传数据文件本身以外，还会上传一个校验文件，该校验文件记录了数据文件的数据量以及文件大小等校验信息，以供下游目标系统验证数据同步的准确性。
另外，在从源系统生成数据文件的过程中，可以增加压缩和加密功能，传输到目标系统以后，再对数据进行解压缩和解密，这样可以大大提高文件的传输效率和安全性。

1.3 数据库日志解析同步

目前，大多数主流数据库都已经实现了使用日志文件进行系统恢复 ，因为日志文件信息足够丰富，而且数据格式也很稳定，完全可以通过解析日志文件获取发生变更的数据，从而满足增量数据同步的需求。
以 Oracle 为例，可以通过源系统的进程，读取归档日志文件用以收集变化的数据信息，并判断日志中的变更是否属于被收集对象，将其解析到目标数据文件中。这种读操作是在操作系统层面完成的，不需要通过数据库，因此不会给源系统带来性能影响。
然后可通过网络协议，实现源系统和目标系统之间的数据文件传输。相关进程可以确保数据文件的正确接收和网络数据包的正确顺序，并提供网络传输冗余，以确保数据文件的完整性。
数据文件被传输到目标系统后，可通过数据加载模块完成数据的导入，从而实现数据从源系统到目标系统的同步。

数据库日志解析同步方式实现了实时与准实时同步的能力，延迟可以控制在毫秒级别，并且对业务系统的性能影响也比较小，目前广泛应用于从业务系统到数据仓库系统的增量数据同步应用之中。
由于数据库日志抽取一般是获取所有的数据记录的变更(增、删、改)，落地到目标表时我们需要根据主键去重按照日志时间倒排序获取最后状态的变化情况。对于删除数据这种变更情况，针对不同的业务场景可以采用一些不同的落地手法。
我们以具体的实例进行说明。如表 3.1 所示为源业务系统中某表变更日志流水表。其含义是:存在5条变更日志，其中主键为1 的记录有3 条变更日志，主键为2的记录有2条变更日志。

针对删除数据这种变更，主要有三种方式，下面以实例进行说明。假设根据主键去重，按照流水倒序获取记录最后状态生成的表为delta表。

• 第一种方式，不过滤删除流水。不管是否是删除操作，都获取同一主键最后变更的那条流水。
  
• 第二种方式，过滤最后一条删除流水。如果同一主键最后变更的那条流水是删除操作，就获取倒数第二条流水。
  
• 第三种方式，过滤删除流水和之前的流水。如果在同一主键变更的过程中有删除操作，则根据操作时间将该删除操作对应的流水和之前的流水都过滤掉。
  
  对于采用哪种方式处理删除数据，要看前端是如何删除无效数据的。前端业务系统删除数据的方式一般有两种正常业务数据删除和手工批量删除。手工批量删除通常针对类似的场景，业务系统只做逻辑删除，不做物理删除，DBA 定期将部分历史数据直接删除或者备份到备份库。

一般情况下，可以采用不过滤的方式来处理，下游通过是否删除记录的标识来判断记录是否有效。如果明确业务数据不存在业务上的删除，但是存在批量手工删除或备份数据删除，例如淘宝商品、会员等，则可以采用只过滤最后一条删除流水的方式，通过状态字段来标识删除记录是否有效。

通过数据库日志解析进行同步的方式性能好、效率高，对业务系统
的影响较小。但是它也存在如下 一些问题：

• 数据延迟。例如，业务系统做批量补录可能会使数据更新量超出系统处理峰值，导致数据延迟。
• 投人较大。采用数据库日志抽取的方式投入较大，需要在源数据库与目标数据库之间部署一个系统实时抽取数据。
• 数据漂移和遗漏。数据漂移，一般是对增量表而言的，通常是指该表的同一个业务日期数据中包含前一天或后一天凌晨附近的数据或者丢失当天的变更数据。

2.阿里数据仓库的同步方式

数据仓库的特性之一是集成，将不同的数据来源、不同形式的数据
整合在一起，所以从不同业务系统将各类数据源同步到数据仓库是一切 的开始。那么阿里数据仓库的数据同步有什么特别之处呢?
阿里数据仓库的数据同步的特点之一是数据来源的多样性。在传统的数据仓库系统中，一般数据来源于各种类型的关系型数据库系统，比如MySQL、SQL Server、Oracle、DB2 等，这类数据的共同特点便是高度结构化，易于被计算机系统处理。而在大数据时代 ，除了结构化数据， 还有大量非结构化数据，比如 Web 服务器产生的日志、各类图片、视频等。特别是日志数据，记录了用户对网站的访问情况，这类数据通常直接以文本文件形式记录在文件系统中，对于数据的分析、统计、挖掘等各类数据应用有极大的价值。以淘宝网为例，我们可以从用户浏览、点击页面的日志数据分析出用户的偏好和习惯，进而推荐适合的产品以提高成交率。
阿里数据仓库的数据同步的特点之 二则体现在数据量上。传统的数 据仓库系统每天同步的数据量一般在几百 GB 甚至更少，而一些大型互 联网企业的大数据系统每天同步的数据量则达到 PB 级别。目前间里巴 巴的大数据处理系统 MaxCompute 的数据存储达到 EB 级别，每天需要 同步的数据量达到 PB 级别，这种量级上的差距是巨大的。

数据源的类型是多样的，需要同步的数据是海量的，那该如何准确、
高效地完成数据同步呢?这里就需要针对不同的数据源类型和数据应用的时效性要求而采取不同的策略。

2.1 批量数据同步

对于离线类型的数据仓库应用，需要将不同的数据源批量同步到数据仓库，以及将经过数据仓库处理的结果数据定时同步到业务系统。
当前市场上的数据库系统种类很多 ，有行存储的和列存储的，有开 源的和非开源的，每一种数据库的数据类型都略有不同，而数据仓库系统则是集成各类数据源的地方，所以数据类型是统一的。要实现各类数据库系统与数据仓库系统之间的批量双向数据同步，就需要先将数据转换为中间状态，统一数据格式。由于这类数据都是结构化的，且均支持标准的SQL语言查询，所以所有的数据类型都可以转换为字符串类型。 因此，我们可以通过将各类源数据库系统的数据类型统一转换为字符串类型的方式，实现数据格式的统一。
阿里巴巴的 DataX 就是这样一个能满足多方向高自由度的异构数据交换服务产品。对于不同的数据源， DataX 通过插件的形式提供支持， 将数据从数据源读出并转换为中间状态，同时维护好数据的传输、缓存等工作。数据在 DataX 中以中间状态存在， 并在目标数据系统中将中间状态的数据转换为对应的数据格式后写人。目前 DataX 每天都需要处理2PB 左右的批量数据同步任务，通过分布式模式,同步完所有的数据所需要的时间一般在3小时以内，有力保障了大数据同步的准确性及高效性。

DataX采用Framework+Plugin的开放式框架实现，Framework处理缓冲、流程控制、并发、上下文加载等高速数据交换的大部分技术问题，并提供简单的接口与插件接入。插件仅需实现对数据处理系统的访问，编写方便，开发者可以在极短的时间内开发一个插件以快速支持新的数据库或文件系统。数据传输在单进程(单机模式)/多进程 (分布式模式)下完成，传输过程全内存操作，不读写磁盘，也没有进程间的通信，实现了在异构数据库或文件系统之间的高速数据交换。

DataX架构：

• Job：数据同步作业
• Splitter：作业切分模式，将一个大任务分解成多个可以并行的小任务。
• Sub-Job：数据同步作业切分后的小任务，称之为task
• Reader: 数据读人模块，负责运行切分后的小任务，将数据从源系统装载到DataX
• Channel: Reader 和 Writer 通过 Channel 交换数据。
• Writer：数据写出模块，负责将数据从DataX导入目标数据系统。

2.2 实时数据同步

对于日志类数据来说，由于每天的日志是源源不断产生的，并且分布在 不同的服务器中，有些大型互联网公司的服务器集群有成千上万台机器，所以所产生的日志需要尽快以数据流的方式不间断地同步到数据仓库。 另外，还有一些数据应用，需要对业务系统产生的数据进行实时处理，比如 天猫“双 ll”的数据大屏，对所产生的交易数据需要实时汇总，实现秒级的数据刷新。这类数据是通过解析 MySQL 的 binlog 日 志 (相当于Oracle 的归档日志)来实时获得增量的数据更新，并通过消息订阅模式来实现数据的实时同步的。具体来说，就是建立一个日志数据交换中心，通过专门的模块从每台服务器源源不断地读取数据日志数据，或者解析业务数据库系统的 binlog 或归档日志，将增量数据以数据流的方式不断同步到日志交换中心，然后通知所有订阅了这些数据的数据仓库系统来获取。阿里巴巴的TimeTunnel (TT)系统就是这样的实时数据传输平台，具有高性能、实时性、顺序性、高可靠性、高可用性、可扩展性等特点。
具体来说， TT 是一种基于生产者、消费者和 Topic 消息标识的消息中间件，将消息数据持久化到 HBase 的高可用、分布式数据交互系统。

TT系统结构：

• 生产者：消息数据的产生端，向 TimeTunnel 集群发送消息数据。
• 消费者：消息数据的接收端，从 TimeTunnel 集群中获取数据进 行业务处理。
• Topic：消息类型的标识，如淘宝 acookie 日志的 Topic 为taobao_acookie， 生产 Client 和消费 Client 均需要知道对应的 Topic 名字。
• Broker模块：负责处理客户端收发消息数据的请求，然后往 HBase 取发数据。

TimeTunnel 支持主动、被动等多种数据订阅机制，订阅端自动负载
均衡，消费者自己把握消费策略。对于读写比例很高的 Topic，能够做到读写分离，使消费不影响发送。同时支持订阅历史数据，可以随意设 置订阅位置，方便用户回补数据。另外，针对订阅有强大的属性过滤功能，用户只需关心自己需要的数据即可。TimeTunnel 高效、稳定地支持阿里巴巴实时数据的同步，每天处理的日志类数据多达几百TB，数据库 binlog解析的实时增量数据同步也有几百TB，在天猫“双 ll”大促活动中，在峰值为每秒十几万笔交易量的极端情况下延迟控制在 3s 以内，有效保障了各种场景的实时数据应用。

参考资料

《大数据之路 某某公司大数据平台建设》
《hadoop构建数据仓库》