目录1.数据同步基础2.阿里数据仓库的同步方式3.数据同步遇到的问题和解决方案1.数据同步基础大数据的数据同步主要包括从分布式业务系统同步进入数据仓库和数据从数据仓库同步进入数据应用和数据服务两个方面。本文主要讲述的是前者。从业务系统同步数据到数据仓库的数据同步总的说来分为三种直连同步(侵入式)数据文件同步数据库日志解析。直连同步通过JDBC方式直接连接源系统抽取数据当数据量大时容易对数据库造成压力甚至拖垮数据库的性能。数据文件同步约定好数据文件的格式编码大小通过专门的FTP文件服务器传输到目标系统同时配上一个校验文件用于核验数据文件的数据量以及文件大小等校验信息以防丢包并验证数据同步的准确性。传输前加密压缩传输后解密和解压缩。数据库日志解析同步这个方式其实已经 可以达到“实时”和“准实时”的要求了。数据库日志文件格式稳定内容丰富解析日志文件获取发生变更的数据完成增量同步的需求。数据库日志抽取通常是获取所有的数据记录的变更(增删改)根据主键分组并按照操作时间倒序排序 来查看数据状态的变化。通过数据库日志解析增量同步该方式性能好效率高对业务系统影响较小但有如下问题a.数据延迟。例如业务系统做批量补录可能会使数据更新量超出系统处理峰值导致数据延迟。b.投人较大。采用数据库日 抽取的方式投入较大需要在源数据库与目标数据库之间部署 个系统实时抽取数据。c.数据漂移和遗漏。数据漂移一般是对增量表而言的通常是指该表的同一个业务日期数据中包含前一天或后一天凌晨 附近的数据或者丢失当天的变更数据。QST:数据延迟和数据漂移这俩我不能理解啥意思啥情况“删除数据”这个变更情况其落地方式视情况而定 主要有三种。第一种不过滤删除流水。不管是否是删除操作都获取同一主键最后变更的那条流水。第二种过滤最后一条删除流水。如果同一主键最后变更的那条流水是删除操作就获取倒数第二条流水。第三种过滤删除流水和之前的流水。如果同一主键变更的过程中有删除操作则根据操作时间讲该删除操作和之前的操作流水都过滤掉。一般可使用第一种“不过滤删除流水”留下删除标识来判断数据是否有效。如果明确业务数据不存在业务上的删除但是存在批量手工删除或备份数据删除例如淘宝商品会员 等则可以采用只过滤最后一条删除流水的方式通过状态字段来标识删除记录是否有效。(QST:折啥意思为什么这样的话第二种方式有效)2.阿里数据仓库的同步方式阿里数据同步的数据源类型是多样的需要同步的数据是海量的阿里大数据处理系统MaxCompute的数据存储达到EB级别每天同步的数据量达到PB级别。批量数据同步Datax,多方向多自由度的数据同步有分布式有单机的。读取数据处理处于中间状态的数据格式化统一化再传到目标数据仓库。一般所有字段全部统一用String类型。一个大Job通过Splitter切分为多个并行执行的Sub-Job运行Sub-Job中的读入数据数据部分对中间状态做处理通过Channel传给WriterWriter负责数据写出模块。实时数据同步双十一的数据大屏是通过解析Mysql库binlog日志(相当于Oracle的归档日志)来实时获得增量的数据更新加上订阅消息实现实时增量同步数据。比如阿里实时数据传输平台TimeTunnel(TT)通过一个模块不停去读取并解析各机子的日志文件增量数据通过数据流传输到日志交换中心然后通知所有订阅了这些数据的数据仓库系统来获取。3.数据同步遇到的问题和解决方案分库分表的处理TDDL(Taobao Distributed Data Layer) 分布式数据库访问引擎通过建立中间状态的逻辑表来整合统一分库分表的访问。再JDBC层之上再持久层之下包括了SQL解释器SQL优化器SQL执行器结果集合并。QST:真牛逼啊有源码可看吗高效同步和批量同步OneClick产品实现了数据的一键化和批量化同步还包括了与数据同步相关的建表配置任务发布测试操作。 数据仓库的数据源种类丰富不同数据源的同步需要开发人员去了解其特殊配置为解决这个问题OneClick通过库名和表名唯一 定位通过IDB接口获取元数据信息自动生成配置信息。增量和全量同步的合并在数据库不支持update或者数据量特别大的情况下采用全外连接(Full outer Join)数据全量覆盖重新加载(Insert Overwrite)。用今天新增数据 full outer join 昨日全量数据得到今日全量数据 insert overwrite。如果怕数据错误以时间为分区字段保留近5-7日的全量数据版本。同步性能的处理基于负载均衡的思想设计的一套数据同步方案实现了根据目标数据库元数据信息来自动估算同步任务所需的总线程数数据同步任务按照业务优先级定位。数据漂移的定义ODS表的同一个业务日期数据中包含前一天或后一天凌晨附近的数据或者丢失当天的变更数据。数据漂移的案例双十一的时候发现有批在11月11日23:59:59左右支付的交易订单漂移到了12日。主要原因是用户下单支付后系统需要调用支付宝接口而有所延迟从而导致这些订单最终生成的时间跨天了。即modified_time和log_time都晚于proc_time。数据漂移的原因时间戳字段通常分为4类具体业务过程发生时间 proc_time数据库表中数据记录更新时间的时间戳字段 modified_time数据库日志中标识数据记录更新时间的时间戳字段log_time数据记录被抽取到数据仓库的时间戳字段 extract_time。按理来讲这四个应一样但这四个往往出现差异从而导致当根据其中某个时间戳字段区分ODS表时就会发生数据漂移。数据漂移的一般处理1.多获取后一天凌晨15min的数据来保证数据只多不少而具体的数据切分让下游根据自身不同的业务场景用不同的业务时间 proc time 来限制。但是这种方式会有一些数据误差例如 某个订单是当天支付的但是第二天凌晨申请退款关闭了该订单那么这条记录的订单状态会被更新下游在统计支付订单状态时会出现错误。(QST这个案例我不理解会出现啥错误)2.通过多个时间戳字段限制时间来获取相对准确的数据。首先根据log_time冗余前一天最后15min和后一天最开始15min的数据然后根据modified_time去筛选出当天数据确保不会出现因系统问题导致的遗漏。然后将后一天log_time前15min的数据按照logtime升序排序去重获得最接近当天记录变化的数据。最后将第一步的全部数据和第二步中最接近昨天的记录做全外连接然后通过限制proc_time来最终获取我们所需要的数据。牛啊牛啊真牛啊操作包含多个业务过程时发生数据漂移的处理比如订单有多个业务流程包括 下单支付成功每个业务过程都有对应的时间戳每个业务过程都可能会发生数据漂移。因此我们可以根实据际情况获取后 15 分钟的数据并限制多个业务过程的时间戳字段下单、支付、成功都是“双 ”当天的然后对这些数据按照订单的 modified time 升序排列获取每个订单首次数据变更的那条记录。此外我们可以根据 log_time 分别冗余前一天最后 15 分钟的数据和后一天凌晨开始 15 分钟的数据并用 modified time 过滤非当天数据针对每个订单按照 log time 进行降序排列 取每个订单当天最后一次数据变更的那条记录。最后将两份数据根据订单做全外连接将漂移数据回补到当天数据中。QST我不理解。。