【数据中台】学习摘录-数据采集

1. 数据采集

1.1 日志采集

数据采集为大数据系统体系的第一环，建立一套标准的数据采集体系方案，可以全面、高性能、规范地完成海量数据的采集，并将其传输到大数据平台。数据采集分为日志采集和数据库同步两部分，其中日志采集主要指的是埋点数据，其数据来源可来自浏览器与无线客户端。

《阿里大数据之路》书中分享了两个案例，分别对应了两个思想。

1. 日志分流与定制处理
   考虑到阿里日志体量的规模和复杂度，分治策略从一开始便是阿里互联网日志采集体系的基本原则。阿里PV日志的请求位置（URL）是随着页面所在业务类型的不同而变化的。通过尽可能靠前地布置路由差异，就可以尽可能早地进行分流，降低日志处理过程中的分支判断消耗，并作为后续的计算资源调配的前提，提高资源利用效率。不仅考虑诸如日志分流处理之类的日志服务器端分布计算方案，而且将分类任务前置到客户端（从某种程度上讲，这才是真正的“分布式”）以实现整个系统的效能最大化。
2. 采集与计算一体化设计
   在当前的互联网环境下，互联网日志的规模化采集方案必须具备个与终端设备的技术特点无关，具有高度扩展弹性和适应性，同时深入契合应用需求的业务逻辑模型，并基于此制定对应的采集规范交由产品开发人员执行。若非如此，则不足以保障采集、解析、处理应用整个流程的通畅。目前阿里已成功实现规范制定、元数据注册、日志采集、自动化计算、可视化展现全流程的贯通。通过一体化设计，用户甚至可以在不理解规范的前提下，通过操作向导式界面，实现日志来集规范的自动落地和统计应用。日志本身不是日志采集的目的，服务于基于日的后续应用，才是日志采集正确的着眼点。

1.2 数据同步

数据同步技术更通用的含义是不同系统间的数据流转，有多种不同的应用场景。主数据库与备份数据库之间的数据备份，以及主系统与子系统之间的数据更新，属于同类型不同集群数据库之间的数据同步。另外，还有不同地域、不同数据库类型之间的数据传输交换，比如分布式业务系统与数据仓库系统之间的数据同步。对于大数据系统来说，包含数据从业务系统同步进入数据仓库和数据从数据仓库同步进入数据服务或数据应用两个方面。

由于源业务系统的数据类型多种多样，有来源于关系型数据库的结构化数据，也有来源于非关系型数据库的非结构化数据，还有来源于文件系统的结构化或非结构化数据，这类数据通常以文件形式进行存储。总之，同步方式可以分为三种：直连同步，数据文件同步和数据库日志解析文件。

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

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

1.2.1 批量数据同步

对于离线类型的数据仓库应用，需要将不同的数据源批量同步到数据仓库，以及将经过数据仓库处理的结果数据定时同步到业务系统。

而阿里巴巴的DataX就是这样一个能满足多方向高自由度的异构数据交换服务产品。对于不同的数据源，DataX通过插件的形式提供支持，将数据从数据源读出并转换为中间状态，同时维护好数据的传输、缓存等工作。数据在DataX中以中间状态存在，并在目标数据系统中将中间状态的数据转换为对应的数据格式后写人。

DataX采用Framework+Plugin的开放式框架实现，Framework处理缓冲、流程控制、并发、上下文加载等高速数据交换的大部分技术问题，并提供简单的接口与插件接入。插件仅需实现对数据处理系统的访问，编写方便，开发者可以在极短的时间内开发一个插件以快速支持新的数据库或文件系统。

1.2.2 实时数据同步

对于日志类数据来说，由于每天的日志是源源不断产生的，并且分布在不同的服务器中，这类数据是通过解析MySQL的binlog（相当于Oracle的归档日志）来实时获得增量的数据更新，并通过消息订阅模式来实现数据的实时同步。具体来说 ，就是建立一个日志数据交换中心，通过专门的模块从每台服务器源源不断地读取日志数据，或者解析业务数据库系统的binlog或归档日志，将增量数据以数据流的方式不断同步到日志交换中心，然后通知所有订阅了这些数据的数据仓库系统来获取。

1.3 数据同步遇到的问题与解决方案

1. 分库分表的处理
   随着业务的不断增长，业务系统处理的数据量也在飞速增加，需要系统具备灵活的扩展能力和高并发大数据量的处理能力，目前一些主流数据库系统都提供了分布式分库分表方案来解决这个问题。但对于数据同步来说，这种分库分表的设计无疑加大了同步处理的复杂度。此时，如果有一个中间表，具备将分布在不同数据库中的不同表集成为一个表的能力，就能让下游应用像访问单库单表一样方便。

2. 高效同步和批量同步
   数据同步的方法通常是先创建目标表，再通过同步工具的填写数据库连接、表、字段等各种配置信息后测试完成数据同步。这也是DataX任务的配置过程，同步中心对DataX进行进一步封装，通过源系统元数据降低了数据库连接、表和字段等信息的配置复杂度。但如果随着业务的发展和变化，会新增大批量的数据同步，且不同数据源就需要配置不用的参数，还有一点就是，部分真正的数据需求方，如java开发和业务运营，由于存在相关数据同步的专业技能门槛，往往需要将需求提交给数据开发方来完成，于是就额外增加了交流的成本。

所以，阿里针对以上几个难点，开发了一款OneClick产品，真正实现了数据的一键化和批量化同步，一键完成DDL和DML生成、数据的冒烟测试以及在生产环境中测试等。

3. 增量与全量同步的合并
   在批量数据同步中，有些表的数据量随着业务的发展越来越大，如果按周期全量同步的方式会影响处理效率。在这种情况下，可以选择每次只同步新变更的增量数据，然后与上一个同步周期获得的全量数据进行合井，从而获得最新版本的全量数据。

当前流行的大数据平台基本都不支持update操作，现在我们比较推荐的方式是全外连接（full outer join) ＋数据全量覆盖重新加载（insert overwrite），如日调度，则将当天的增量数据和前一天的全量数据做全外连接，重新加载最新的全量数据。在大数据量规模下，全量更新的性能比update要高得多。如果担心数据更新错误问题，可以采用分区方式，每天保持一个最新的全量版本，保留较短的时间周期（如3~7天），超出时间的做自动删除，可以设置Lifecycle。

update方法的优点是同步的增量数据量比较小，但是带来的缺点有可能有数据不一致的风险，而且还需要用额外的计算进行数据合并。如无必要，会变化的数据就使用全量更新即可。

4. 同步性能的处理
   数据同步任务是针对不同数据库系统之间的数据同步问题而创建系列周期调度的任务。在大型的数据调度工作台上，每天会运行大量的数据同步任务。针对数据同步任务，一般首先需要设定首轮同步的线程数，然后运行同步任务。

针对数据同步任务中存在的问题，阿里巴巴数据团队实践出了一套基于负载均衡思想的新型数据同步方案。该方案的核心思想是通过目标数据库的元数据估算同步任务的总线程数，以及通过系统预先定义的期望同步速度估算首轮同步的线程数，同时通数据同步任务的业务优先级决定同步线程的优先级，最终提升同步任务的执行效率和稳定性。

5. 数据漂移的处理
   通常我们把从源系统同步进入数据仓库的第一层数据称为ODS层数据。数据漂移是ODS数据的一个顽疾，通常是指ODS表的同一个业务日期数据中包含前一天或后一天凌晨附近的数据或者丢失当天的变更数据。

多获取后一天的数据，既然很难解决数据漂移的问题，那么就在ODS每个时间分区中向前、向后多冗余些数据，保障数据只会多不会少，而具体的数据切分让下游根据自身不同的业务场景用不同的业务时间来限制，但是这种方式会有一些数据误差，例如一个订单是当天支付的，但是第二天凌晨申请退款关闭了该订单，那么这条记录的订单状态会被更新，下游在统计支付订单状态时会出现错误。