大数据 频道

汽车之家数据库服务化平台从0到1的实践过程

  【IT168 技术】导语:本文根据蔺瑞超老师在2018年5月12日【第九届中国数据库技术大会(DTCC)】现场演讲内容整理而成。

  蔺瑞超 汽车之家高级数据库专家

  汽车之家MySQL技术负责人. 负责公司MySQL的运维体系建设, 以及数据库相关平台设计和实现工作。

  摘要:分享一下汽车之家数据库服务化平台从0到1的实践过程。详细介绍平台的整体架构,技术栈以及各系统模块的工程化实现方案。希望给正在做数据库自动化,平台化的同学一些借鉴和启发。

  服务化平台目标及发展历程

  汽车之家整体平台的目标是实现数据库运维自动化、自助化、服务化。目前,智能技术发展迅速,智能运维成为主流,汽车之家后续也将朝向智能化发展。

  2014年之前汽车之家数据平台基于SQL Server,2014年之后开始使用MySQL,目前,两个体系同时使用,平台建设兼容SQL Server和MYSQL两套体系。2014年,汽车之家基本是纯手工,做了一些标准化的工作和一些规范的制定以及落地。2015年,主要做一些工具化的东西,比如写一些自动化相关的脚本工具。2016年,开始逐渐构建系统来解决问题。2017年,为了配合公司私有云的战略,把数据库服务作为服务平台去建设。未来,我们会向智能化运维方向进行探索。

  服务化平台技术栈


  汽车之家目前平台的技术栈主要基于Python加Go,包括社区的一些比较优秀的组件。

  服务化平台系统架构


  这是汽车之家的基本系统架构,最底层是MYSQL、SQL Server,现在在跟进分布式数据库的评估,后续会有一些相关场景的落地。之上是基础组件、信息采集层。基础组件主要包括运维的基础设施。信息采集层包括元信息、性能数据以及查询日志等。然后在这些信息的上层做了很多运维、数据相关的组件系统,完成我们的运维工作。

  整体架构的上层是一些服务的Portal,主要是面向开发同学和DBA同学的服务单元。灰色部分是在做的以及未来的考量,蓝色部分和绿色部分是已经实现的功能。

  运维设施

  服务的自动化构建,是开发同学提出资源申请, 一直到服务交付的完整流程。我们主要实现了数据库服务的自动化部署,包括MySQL集群建设、SQL Server部署 以及Slave自动构建。

  整个实验方案是基于Salt来实现的部署模块,部署采用Celery分布式异步任务框架来做任务的异步化。整个流程会结合系统平台部的资源申请和装机的流程,协调交互。

  服务化自动化架构


  这是整个架构,从服务申请到资源交付的全流程实现。系统平台系统提供流程申请以及装机, 之后和我们DB自动部署平台做交互,请求过之后, 我们会异步和salt做交互。

  基于Salt实现了两个部署模块,分别支持SQL Server和MySQL,未来开发模块来支持分布式数据库的部署

  服务化自动化构建


  在请求过来之后,DBA对它做一些配置, 比如选择版本和端口, 实例数量等信息。

  选择完之后进行异步部署。

  可以在这边看到它的状态和日志情况。

  这边会把最终部署结果反馈回来,如果有问题,DBA同学需要去处理。

  备份恢复体系


  做DBA运维, 备份恢复是我们最重要的一块工作。目前的备份由全备和日志增量来实现,整个备份过程中需要加密,然后进行恢复较验。

  备份恢复体系,由DB服务器端做备份,通过备份程序把整个备份推到Buffer Storage。整个过程它会把备份信息写入我们平台的数据库,整个阶段都会跟元信息做相关的交互。这一共分为4个流程,从开始备份到上传Buffer环境,在Buffer环境做一个数据恢复性较验,最终把整个信息更新到我们数据库里,来后续供我们备份恢复或者集群构建的时候使用。

  高可用架构


  关于高可用,我们主要还是传统型的HA方案。

  整个公司多个机房之间部署了内部DNS解析服务,所有的业务和DB之间的交互全部都通过DNS来做。整个基本的架构就是MHA加半同步。MHA提供原有功能对DNS做支持。运营解析会有对应接口,我们切完之后可以实时更新DNS Cache,让它生效,这样可以保证切换时间对业务影响比较小。对于SQL Server,我们引入了Always ON来实现秒级HA方案。

  未来我们主要考虑基于MySQL集群的一些技术,以及分布式数据库技术来实现真正的高可用方案的升级换代。

  SQL实时分析


  SQL查询的分析,目前我们通过MYSQL 的Slow log以及实时查询采样来进行实时分析。整个实现方案通过HEKA组件,我们可以把日志流做实时采集,然后推到Kafka。另外,我们把TiDB的SQLParser剥离出来,用在这个地方。消费端主要做格式化和信息落地,落地完成之后做统计分析,除此之外就是可视化。

  HEKA实时采集


  这是大家都很熟悉的Slow log的格式,在Slow log里的SQL就是这个样子。

  这块主要对Slow log按照一定的规则做split,把split内容用一套正则做模式匹配,把对应的关键指标提取出来,最后就形成了这个格式。这个可以直接的推到kafka,然后消费端对信息进行解析。

  这是一个实时的SQL信息,我们用的组件vc-mysql-sniffer,可以生成固定的日志格式,这个日志格式分析完之后就是这个样子。

  最终我们可以拿到SQL的执行时间,SQL的来源以及SQL执行的Database等信息。把这些信息实时的推到Kafka之后,就可以做相关的消费和解析。

  SQL实时分析


  这是我们解析的架构,由HEKA把Slow log 和我们采集的SQL的Log实时化的推到Kafka,Kafka把这些信息推到消息系统。我们在消费端实现了信息的消费,然后通过parser做解析,生成特定的格式进行落库,落到我们的MetaDB,再通过MetaDB上的计算任务做统计。后续我们可能会把美团开发的SQL Adviser引入到这个流程。Error Log也是通过同样的机制采到ELK里,供我们后续做一些相关的分析使用。

  数据设施——需求


  数据传输的类型主要是全备和增量;功能需求主要包括数据脱敏、抽取任务的延迟情况、结构变更感知和异构传输同步。另外,整个系统要简单、灵活,让DBA能够解决常见的问题,能够很快的做响应。

  CDC获取及技术选型


  关于变化的数据获取,常见方案有这几种, 日志解析,用Trigger或类似方式记录数据变更,还有一种就是基于时序的SQL逻辑抽取。我们采用的方案有两个,一个是逻辑抽取(AutoLine) 和BinLog解析。

  AutoLine(逻辑抽取)

  ——逻辑复制


  AutoLine本质上是一个分布式的调度系统。

  如果站到一个表的数据角度来看,整个时序就是这样的一个情况,不断的有数据在变化。

  这些信息怎么获取、抽取、怎么把它迁移到需求地呢?

  在一个点对整个表做一次历史数据的抽取,之后根据它的数据修改时间把它的增量数据抽取出来,把增量部分落置到对端,每一张表都是这样的逻辑。

  如果表特别多的时候,也就是多个任务做小单元化的数据抽取,就把所有的单元变成任务,所有的任务都可以被调度。实现的方式其实很简单,增量的同步肯定要获取增量的数据,我们实验的这套系统就可以支持异构的数据库,并且它还可以按需扩容和故障自愈。

  整个系统架构本质上是调度系统,基于Celery异步任务框架来实现的 。系统设计的时候会有不同的优先级队列。

  下边的Worker执行每个任务单元。Worker是可以人为控制的,可以根据任务量判断给多少Worker。

  现在我们的系统分了全量、增量,增量里面又分为分钟级和小时级的调度,因为每个组的调度频率是单独可控的,所以只要调度正常,每个分组里的任务状态正常,并且不断的有Worker来执行各种任务的小时调度单元,就可以实现整个数据的迁移。

  Worker在执行一个任务片的时候,任务片可能会因为意外情况导致失败。于是有了任务片故障自愈功能。任务片出现了问题之后,它的状态会自动归为可调度状态。调度完成之后会更新任务的元信息来表示数据迁移到了哪个时间点。

  结构感知是一个逻辑抽取,不适合做结构感知。所以,我们基于这套框架做了结构对比度的功能,它会定期的校验任务的主库和配置的信息是否对等,如果不对等会触发一个结构同步动作,然后进行更新。

  所有的任务在调度的过程中都是互相独立的,每一个任务都可能会延迟,这个延迟时间在做计算的时候是有要求的。我们会根据它所在组的调度区间对它做延迟校验,如果它延迟了,我们会把相关的信息反馈到系统层面,让相关同学去处理。

  通过观察我们调度系统的界面,我们可以实时监控任务执行情况。

  在增量的情况下,任务执行效率很高,几秒钟之内就可以将任务片迁移到目标库。

  日志解析——技术选型


  对于技术选型,开源组件有很多,比如Alibaba Canal、Linkin DATABUS、Tungsten replicator、MaxScale CDC等等。通过评估, 选择了自主开发,用Python(团队比较熟悉)来实现日志的解析。

  日志解析

  整个系统有几个核心的组件,第一个是日志解析,也就是把自己伪装成一个Slave,然后不断的获取Binlog的Stream里面的Event来做相关的处理,它会把Event的数据换成Json格式,序列化后投递到Kafka。

  在整个解析中,我们加入了一个幂等消息分发。在异常的时候,Kafka因为一些异常的情况会导致消息重发,因此我们为每个消息生成了一个MD5值,消息端可以基于这个值做消息的幂等性校验。

  还有一个是解析端高可用,就是我们在做日志解析的时候,如果我的主库或者解析源挂掉,可以换到下一个节点去做解析。

  快照处理


  做数据接入的时候,会需要一个历史数据,于是我们引入了快照处理的模块。这个模块利用了一个MYSQL特性,因为我们使用的版本是Percona,Percona把Consistent Snapshot从MariaDB取过来,在此基础上实现了一个session克隆。当开多个线程的时候,可以用同一个Snapshot去抽取,实现真正的并发。

  快照的创建,首先连接数据库要开启RR模式,然后通过START TRANSACTION WITH CONSISTENT SNAPSHOT命令开启快照,这个快照可以拿到Binlog的位点,然后通过函数可以拿到当前连接的session id。

  日志应用

  当Snapshot、Binlog都存在的情况下, Apply端消费对应任务的topic,处理数据的Snapshot,然后做Apply增量。因为已经有位点了,每一个Json消息里面都会包含消息对应的Binlog的位置和它的file,这样就可以做增量的消费,在消费过程中,如果对数据准确要求很高,可以对每一个消息做校验。

  系统结构


  这是当前系统的架构,有Dumper解析模块,还有Snapshot,主要做集备做并发执行,把消息以同样的格式提供到消息缓冲Kafka系统,消费端就可以基于Snapshot加解析端增量来实现实时化的消费。

  目前的消息端可以支持这几个方面:

  •   SQL Server、MySQL

  •   实时计算平台

  •   缓存更新策略

  •   搜索引擎索引的实时更新

0
相关文章