交易异构数据归档平台Filing1.0分享Filing是一个异构数据源归档平台，致力于实现包括关系型数据库(MySQL)

一、Filing1.0概览

Filing是一个异构数据源归档平台，致力于实现包括关系型数据库(MySQL)、Hbase、Hive、ES等各种异构数据源之间稳定高效的数据归档(迁移)功能；各领域无需编码即可实现数据归档的诉求。

1.1.背景

随着业务的快速发展，订单量日益膨胀，并且交易mysql库的存储压力越来越大。考虑存储成本、系统稳定性、性能、用户体验等因素亟需进行数据归档处理，来进行数据层面的“冷热隔离”。在设计之初面临着如下挑战：

• 数据量大：订单/运单/账单数据规模庞大(相关数据在千亿级以上)。
• 表级级联：数据库表维度的级联归档诉求强烈。
• 同构归档限制业务 ： 严重限制业务(有 ddl 诉求时将是灾难性)。
• 领域多样化：交易领域比较多，包括订单域/运单域/资金域/发票域/工单域，每个域都面将临着数据归档的诉求。
• 归档方式多样化：基于各领域的现状分析，订单/运单域采用归档到Hbase的方式，发票/工单归档到Mysql。

基于此，我们决定自建一个适用于交易的异构数据归档平台，Filing因此而诞生。

1.2.设计理念

在设计之初，我们进行了深入的研究，调研了业界内主流的ETL(Extract-Transform-Load)工具。

主流ETL工具对比：

特性	TurboDX(收费)	Kettle	Datax	Filing(自建)
适用场景	异构数据库实时复制同步、读写分离	面向数据仓库建模的批处理工具	面向数据仓库建模的批处理工具	复杂异构数据之间的迁移处理
产品架构	批流一体化架构、内存多线程流式处理	C/S客户端组件流程设计，批处理模式	脚本方式执行任务，批处理模式	web界面配置，简单易用
图形界面	完全web图形化界面设计和监控管理	线上生产环境没有界面	无图形化界面，运维成本较高	图形化界面配置，支持字段级映射
数据转换	图形界面自动化的schema mapping配置	手动配置schema mapping及代码逻辑处理	通过编写json脚本进行schema mapping映射	图形化界面配置，支持字段级映射
断点续传	支持	不支持	不支持	支持
流量控制	支持	不支持	不支持	支持
分布式	支持	不支持	不支持	支持
高低峰期处理	不支持	不支持	不支持	支持
应急手段	不支持	不支持	不支持	支持

为了灵活支持各种业务的诉求、解决异构数据源归档问题，Filing将复杂的网状的同步链路变成了星型数据链路，Filing作为中间传输载体负责连接各种数据源。当需要接入一个新的归档数据源的时候，只需要将此数据源对接到Filing，便能跟已有的数据源做到无缝归档。

二、框架设计

2.1.计划中心

计划中心是整个FIling的管理核心，主要负责计划的创建、修改、上/下线等。

2.2.调度中心

调度中心是任务处理的核心。主要负责节点的注册/发现、任务的拆分、任务绑定等。

• 注册中心：通过Redis的Zset和pub/sub实现，Zset做角色的注册及发现，pub/sub做上线/下线的通知。

2.2.1.创建任务

在Filing管理后台创建计划并上线后，基于计划设置的执行时间，LalaJob会定时调度并创建任务。在创建任务的时候基于split的策略动态拆分任务。

• split策略：

基于shardingCount( shardingTable )；基于时间条件( 非shardingTable )

2.2.2.绑定任务

基于pod(excutor)的数量和子任务的数量进行平均分配。默认采用短板规则绑定（即取最少子任务绑定数量的executor），目前仅提供这一种策略。

2.2.3.触发任务

任务触发目前只支持定时触发，由TaskManager定时扫描数据库中触发时间在未来60s内的任务，并创建60s内触发的定时任务等待执行。

2.2.4.执行任务

在执行任务时，TaskManager会从执行线程池SubTaskWorkers获取执行线程并绑定SubTask对象，然后通过调用TaskHandler#handle方法执行子任务，handle方法的内容就是具体业务逻辑代码。(归档引擎的核心代码)

2.3.归档引擎

Filing的核心是由1个引擎4个组件构成。将数据源读取和写入抽象成为trigger+scanner以及colletor+excutor组件，并将其纳入到整个归档框架中。

• Trigger(触发器)： Trigger为数据采集模块的触发器，负责构建数据采集的条件，然后交给扫描器执行。

• Scanner(扫描器)： Scanner为数据采集模块的扫描器，负责扫描源端基表数据，然后交给收集器。

• Collector(收集器)： Collector为数据收集模块的收集器，负责收集扫描器扫描出来的数据，然后广播出去。

• Excutor(执行器)： Excutor为数据写入模块，负责不断从Collector取数据，并将数据写入到目标端。

三、核心流程

Filing支持分布式多线程模式完成归档作业运行，基于Filing作业生命周期，从整体流程上详细介绍Filing的各个模块的关系以及如何运行的。

3.1. 流程详情介绍

1. 用户首先需要在归档平台创建一个归档计划，然后发布并上线。

2. 计划创建后会调用LaLaJob的openapi生成一个job；计划上线时会基于动态数据源模块，动态初始化计划配置的所有数据源。

3. LaLaJob会定时进行任务调度，调度成功后会生成一个归档实例，然后基于调度中心的任务拆分模块，将实例按照事先分配的并发数拆分成多个任务，在拆分同时会基于归档引擎的trigger组件构建各自的扫描条件，然后自动分配给节点并在工作时间内进行执行。

4. 最终归档引擎的scanner从源端扫描出数据，交给collector后，经过transformer转换好目标端需要的对象再交给excutor进行数据的写入。

5. 最后，经过一系列的后置处理器处理，统计出执行的结果并记录归档过程中的异常数据。

3.2.Filing计划创建介绍

本小节主要介绍如何创建一个归档计划，下面的动图会直观的看到如何创建计划。

• 数据源导航：预录入的数据源元数据信息，包括资源id、schema等信息。

工作时间& 限流 配置：

3.3.执行效果

3.3.1.数据统计

四、挑战及解决方案

4.1.HBase的rowkey设计

由于新老模型的订单号的长度不一致，并且为了保证region的数据均匀，因此在设计rowkey之初进行了多次讨论，最终订单详情的rowkey生成规则如下：

4.2.byte数组内容一样，引用不同

由于byte[] 内容一样，引用不同导致认为是2条数据，最终落到HBase中是2行数据，导致数据异常(比如订单地址表信息等1对多的表)。因此我们采用重写byte[]的equals和hashcode方法，内容一样就认为是一样的。

4.3.缓存一致性问题

为了提高整体的性能以及减少对单库的影响(会频繁查询归档计划详情)，因此引入了二级缓存(caffeine+redis)。虽然极大的提高了性能，但是在修改计划或者上下线时会存在数据不一致的问题，主要是由于在修改计划时是通过soa调用，只能路由到某个节点，其余节点的本地缓存是没清除的。

因此，为了解决该问题，我们基于调度中心已实现的Redis的pub/sub来通知所有节点来清楚本地缓存。

五、归档数据查询

数据归档完之后，我们面临着归档数据查询的诉求，因此，我们设计了一个统一的归档数据查询插件(ADQ)，能够“傻瓜式”的复用于多个查询服务。最终，实现了数据流的闭环。

5.1.设计目标

• 可复用 ：交易域的查询服务相对较多，能够快速复用于多个服务。

• 一键接入：接入成本低，能够开箱即用、拿来即用。

• 无侵入：对业务代码无侵入、无感知。

5.2.实现原理

5.2.1.核心流程

5.2.2.整体流程

下面以订单查询服务为例说明整体流程。

5.3.主要功能

5.4.HBase-GUI

由于目前大数据暂时没有HBae的可视化查询工具，下图为自研的一个HBase-GUI，主要解决订单归档到HBase后的查询、排查问题等诉求。

六、应用实践

目前filing已正式在交易域应用于如下场景：

• 交易订单数据归档

• 订单ES集群的冷热隔离

关键结果汇总：

1. 解决公司数据增长后存储成本和业务查询矛盾的问题；
2. 提供简单易用的数据归档(迁移)的解决方案；
3. 极大的提高了研发效率；
4. 丰富了公司的通用工具。

6.1. 研发效能提升

• Filing不仅能够灵活支持交易所有领域(订单/运单/资金/工单等)的归档诉求，包括数据迁移的诉求。甚至能够满足货拉拉各领域数据归档诉求的大部分的场景。能够极大的提升研发效率。

• 随着后续订单的持续增长，配合ADQ插件能够快速缓解MySQL热库的压力(动态调整)，保证业务的快速发展。

6.2. 通用工具的丰富

• HBase-GUI 作为自研的一个HBase可视化查询工具，目前已将源码捐给大数据团队，丰富大数据的BQ平台。

• ADQ插件无论是搭配Filing使用，还是单独使用都能够极大的减少开发工作量，提高研发效率。

七、未来规划

核心目标： 把研发效率放首位，做到可复用、可推广等，并探索更多的落地场景。

愿景：希望数据存储不再是瓶颈。打造稳定、高效、灵活、准确&及时的货运交易履约系统一直是我们交易人整体的目标🎯。