dbaplus社群TB@携程机票数据仓库11年技术栈的演进作者介绍

作者介绍
华智，携程高级研发经理，现负责数据仓库技术架构、性能优化、数仓规范制定、数据模型设计以及数据应用开发。
前言
随着大数据技术的飞速发展，海量数据存储和计算的解决方案层出不穷，生产环境和大数据环境的交互日益密切。数据仓库作为海量数据落地和扭转的重要载体，承担着数据从生产环境到大数据环境、经由大数据环境计算处理回馈生产应用或支持决策的重要角色。
数据仓库的主题覆盖度、性能、易用性、可扩展性及数据质量都是衡量数据仓库解决方案好坏的重要指标。携程机票部门数据仓库也在不断摸索向着这些目标砥砺前行。
携程机票数据仓库技术栈
携程机票部门的数据仓库建设主要基于公司公共部门的大数据基础环境及数据调度平台，辅以部分自运维的开源存储引擎和基于开源组件二次开发的数据同步工具和运维工具。
1、数仓技术演进历史
机票部门的数据仓库源于2008年，当时生产环境数据落地主要使用SQLServer ，数据仓库处理的目标数据体量不大，因此选择的SQLServer、Informaticas、Kettle这样的数据仓库方案，数据模型设计及报表定制使用SAP的商用平台BO 。
随着机票业务系统的日益复杂，特别是生产环境引入消息中间件Kafka存储日志数据后，这套方案不可扩展性的缺点日趋明显， SQLServer的存储和计算能力很大程度上限制了数仓数据的主题覆盖度及性能。
在2014年，公司公共部门hadoop集群部署上线，并且引入了zeus调度平台及DataX同步工具，各个BU的数据仓库开始逐步转为基于Hive建设。
随着生产业务对实时监控、流量回放的需求增强， 2016年机票部门部署了ElasticSearch ，用以实时落地从Kafka同步的各个主流程服务日志，并通过统一的交易标识(transactionID)串联用户的一次完整的搜索、下单等行为，用于生产排障和流量回放。基于Hive的搜索性能一直被广泛诟病，特别是针对adhoc查询，机票部门在2016年调研并部署了Facebook开源的基于内存和Pipeline的查询引擎Presto ，在没有享受到local数据获取的前提下，查询性能较原生的Hive引擎或者Spark引擎都有很大的提升。
在2018年，为了支持数仓数据的可视化运营平台，我们先后引入了ClickHouse和CrateDB作为后台的存储和查询引擎，特别是引入CrateDB以后，亿级体量的表四个维度的聚合耗时P90下降到了4秒。
实时数据处理技术也经过了Esper、Storm、SparkStreaming和Flink的迭代，并慢慢收敛到Flink 。总体的技术演进历史如图1所示。

文章图片
图1数仓技术演进历史
2、当前技术栈
生产环境的数据可以大致分成三类：
1）业务数据，主要存储在MySQL和SQLServer ，在这些关系型数据库里面有数以万计的表承接着各种生产服务的业务数据写入；
2）基础数据，也是存储在MySQL和SQLServer中，生产应用时一般会建立一层中心化缓存（如Redis）或者本地缓存；
3）日志数据，这类数据的特点是”appendonly” ，对已经生成的数据不会有更新的操作，考虑到这类数据的高吞吐量，生产环境一般会用消息队列Kafka暂存；
数据仓库在实施数据同步时，会根据需求在实时、近实时以及T+1天等不同的频率执行数据同步，并且在大数据环境会用不同的载体承接不同频率同步过来的数据。在携程机票，实时同步的目标载体是ElasticSearch、CrateDB或者HBase ，近实时（一般T+1小时）或者T+1天的目标载体是Hive 。
从生产的数据载体来讲，主要包括DB和消息队列，他们的数据同步方案主要是：
1）生产DB到Hive的同步使用taobao开源的DataX ， DataX由网站运营中心DP团队做了很多扩展开发，目前支持了多种数据源之间的数据同步。实时同步的场景主要在MySQL ，使用DBA部门使用Canal解析并写入至消息队列的binlog 。