干货 | 百万QPS，秒级延迟，携程基于实时流的大数据基础层建设

作者简介

 

纪成，携程数据开发总监，负责金融数据基础组件及平台开发、数仓建设与治理相关的工作。对大数据领域开源技术框架有浓厚兴趣。

一

一、背景

2017年9月携程金融成立，本着践行金融助力旅行的使命，开始全面开展集团风控和金融业务，需要在携程DC构建统一的金融数据中心，实现多地多机房间的数据融合，满足离线和在线需求；涉及数千张mysql表到离线数仓 、实时数仓、在线缓存的同步工作。由于跨地域、实时性、准确性、完整性要求高，集团内二次开发的DataX（业界常用的离线同步方案）无法支持。以mysql-hive同步为例，DataX通过直连MySQL批量拉取数据，存在以下问题：

1）性能瓶颈：随着业务规模的增长，离线批量拉取的数据规模越来越大，影响mysql-hive镜像表的产出时间，进而影响数仓下游任务。对于一些需要mysql-hive小时级镜像的场景更加捉襟见肘。

2）影响线上业务：离线批量拉取数据，可能引起慢查询，影响业务库的线上服务。

3）无法保证幂等：由于线上库在实时更新，在批量拉取SQL不变的情况下，每次执行可能产生不一样的结果。比如指定了create_time 范围，但一批记录的部分字段（比如支付状态）时刻在变化。也即无法产出一个明确的mysql-hive镜像 ， 对于一些对时点要求非常高的场景（比如离线对账） 无法接受。

4）缺乏对DELETE的支持：业务库做了DELETE操作后，只有整表全量拉取，才能在Hive镜像里体现。

一

二、方案概述

    

基于上述背景，我们设计了一套基于binlog实时流的数据基础层构建方案，并取得了预期效果。架构如图，各模块简介：

1）webUI做binlog采集的配置，以及mysql->hive，mysql→实时数仓，mysql→在线缓存的镜像配置工作。

2）canal负责binlog采集 ，写入kafka ；其中kafka在多地部署，并通过专线实现topic的实时同步。

3）spark-streaming 负责将binlog写入HDFS。

4）merge 离线调度的ETL作业，负责将HDFS增量和 snap 合并成新的 snap。

5）mirror 负责将binlog事件更新到实时数仓、在线缓存。

6）基础服务：包括历史数据的重放，数据校验，全链路监控，明文检测等功能。

一

三、详细介绍

    

本章将以mysql-hive镜像为例，对技术方案做详细介绍。

3.1.binlog采集

    

canal是阿里巴巴开源的Mysql binlog增量订阅和消费组件，在业界有非常广泛的应用，通过实时增量采集binlog ，可以降低对mysql 的压力，细粒度的还原数据的变更过程，我们选型canal 作为binlog采集的基础组件，根据应用场景做了二次开发，其中raw binlog → simple binlog 的消息格式转换是重点。

下面是binlog采集的架构图：

canal 在1.1.4版本引入了canal-admin工程，支持面向WebUI的管理能力；我们采用原生的canal-admin 对binlog采集进行管理 ，采集粒度是 mysql instance级别。

Canal Server会向canalAdmin 拉取所属集群下的所有mysql instance 列表，针对每个mysql instance采集任务，canal server通过在zookeeper创建临时节点的方式实现HA，并通过zookeeper实现binlog position的共享。

canal 1.1.1版本引入MQ