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

2）从Kafka到Hive同步使用Camus ，但是由于Camus的性能问题及消费记录和消费过期较难监控的问题，我们基于spark-sql-kafka开发了hamal ，用于新建的Kafka到Hive的同步；Kafka实时同步的载体主要是ElasticSearch或者CrateDB ，主要通过Flink实施。
生产数据被同步数据仓库后，会在数仓内完成数据清洗、信息整合、聚合计算等数据扭转流程，最终数据出仓导入到其它载体，这一系列的流程调度由公司DP团队运维的调度平台Zeus完成。

文章图片
图2携程机票数仓技术栈
3、实时VS离线
当前机票部门的数据仓库建设主要基于离线数据，一方面跟OTA销售产品不属于快消品相关，实时当前并不是刚需；另一方面实时处理场景下需要对计算资源、存储资源稳定性有更高的要求，保持数据一致性的代价很大。结合两方面，如果业务对实时需求不高就铺开做实时数仓， ROI很难达标。
当然，随着携程业务体量的增长，数据使用方对数据实时性要求日益增高，我们团队在2020年也会探索实时数据仓库的实施方案，并在一两个重要的数据主题域上先行试点。
数据仓库建设时涉及的共性问题
从团队职能上来讲，数据仓库团队需要负责从生产环境同步数据，在内部完成各层级的扭转计算，参与所有数仓流程及报表的运维，并基于数仓公共数据层和应用数据层数据开发相关应用。
1、数据同步
为了保持数仓数据主题覆盖足够全面，我们部门几乎将所有生产表和Kafkatopics都同步到了Hive 。以下会对同步最常见的两种场景DB->Hive和Kafka->Hive相关的实践做介绍。
1）DB同步到Hive
特别对生产表到Hive的同步，人工配置脚本的方式显然不能处理数以万计的表，因此需要一个自动化的同步方案。自动同步方案需要不仅仅要解决自动创建表脚本、创建对应的同步脚本问题，还需要在当表结构发生变更的时候，能够自动地感知表结构的变化，并且修改表结构和对应的同步脚本。
DB到Hive同步需要依赖两个数据源， 1）Schema表的元数据信息，简单地包括各个字段信息、字段类型及主键定义；2）统计数据，它主要描述的是这个表在数据产生后有没有UPDATE和DELETE ，这个决定着后续表的分区方式。
对业务型数据，一条数据生成后可能会有Update ，因为在数仓里绝大部分场景需要用到数据的最新状态，所以我们会用一个分区存放所有历史数据的最新状态，这类表我们称之为历史切片表。对日志型数据，生产上数据产生后就不会有任何修改，我们会选择使用增量分区，每个分区会放当天的增量数据。对基础数据，整个表的数据增加、更新的频率都非常低，在ods层我们会每天全量同步一份到最新数据分区，并且会建立一个无分区的下游维表，将数据状态为有效的数据放到这张下游无分区维表中方便流程使用。
有了上述这两个数据源以后，我们会根据DBASchema服务返回的元数据信息生成Hive表的脚本，并调度执行生成新的Hive表，再依据统计数据决定表的分区方式，进而生成对应新建表的同步脚本。当表创建或者表结构发生变更的时候，通过Schema服务两天输出的比对，我们会发现表结构的变更并映射到对应Hive表结构变更，同时可以改变对应的同步脚本。还有一种思路是可以通过DB发布系统的日志，获知每天DB创建、表创建以及表结构变化的增量。

文章图片
图3生产DB到Hive的同步
有一个坑点就是生产物理删除，如果出现了物理删除并且需要在Hive表里将删除数据识别并标记出来，当前可能需要通过全量同步的方法（考虑到从生产环境取数的代价，全量同步业务主键字段即可）解决，特别对SQLServer 。因此可以跟生产的开发协商尽量使用逻辑删除，这样数仓对删除数据的感知代价会小很多。