【数据中台】学习摘录-数据采集
【数据中台】学习摘录-数据采集
⽂章⽬录
1. 数据采集
1.1 ⽇志采集
数据采集为⼤数据系统体系的第⼀环，建⽴⼀套标准的数据采集体系⽅案，可以全⾯、⾼性能、规范地完成海量数据的采集，并将其传输到⼤数据平台。数据采集分为⽇志采集和数据库同步两部分，其中⽇志采集主要指的是埋点数据，其数据来源可来⾃浏览器与⽆线客户端。
《阿⾥⼤数据之路》书中分享了两个案例，分别对应了两个思想。
1. ⽇志分流与定制处理
考虑到阿⾥⽇志体量的规模和复杂度，分治策略从⼀开始便是阿⾥互联⽹⽇志采集体系的基本原则。阿⾥PV⽇志的请求位置（URL）是随着页⾯所在业务类型的不同⽽变化的。通过尽可能靠前地布置路由差异，就可以尽可能早地进⾏分流，降低⽇志处理过程中的分⽀判断消耗，并作为后续的计算资源调配的前提，提⾼资源利⽤效率。不仅考虑诸如⽇志分流处理之类的⽇志服务器端分布计算⽅案，⽽且将分类任务前置到客户端（从某种程度上讲，这才是真正的“分布式”）以实现整个系统的效能最⼤化。
申诉qq2. 采集与计算⼀体化设计
在当前的互联⽹环境下，互联⽹⽇志的规模化采集⽅案必须具备个与终端设备的技术特点⽆关，具有⾼度扩展弹性和适应性，同时深⼊契合应⽤需求的业务逻辑模型，并基于此制定对应的采集规范交由产品开发⼈员执⾏。若⾮如此，则不⾜以保障采集、解析、处理应⽤整个流程的通畅。⽬前阿⾥已成功实现规范制定、元数据注册、⽇志采集、⾃动化计算、可视化展现全流程的贯通。通过⼀体化设计，⽤户甚⾄可以在不理解规范的前提下，通过操作向导式界⾯，实现⽇志来集规范的⾃动落地和统计应⽤。⽇志本⾝不是⽇志采集的⽬的，服务于基于⽇的后续应⽤，才是⽇志采集正确的着眼点。
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每个时间分区中向前、向后多冗余些数据，保障数据只会多不会少，⽽具体的数据切分让下游根据⾃⾝不同的业务场景⽤不同的业务时间来限制，但是这种⽅式会有⼀些数据误差，例如⼀个订单是当天⽀付的，但是第⼆天凌晨申请退款关闭了该订单，那么这条记录的订单状态会被更新，下游在统计⽀付订单状态时会出现错误。
>立冬吃什么食物

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。