dbaplus社群TB@携程机票数据仓库11年技术栈的演进( 三 )


2)Kafka同步到Hive
当前我们非实时同步主要在使用Linkedin很久以前的一个工具Camus , 当然DP团队经过优化和企业本地化二次开发 。 但从使用感受来看 , Camus会有如下可能不足的地方:
基于mapreduce , mapreduce在yarn集群上抢占资源的能力较弱 , 在资源竞争高峰会有同步变慢的情况发生;
消费记录存储在HDFS各个文件里 , 这样对消费记录的获取和针对消费过期的监控都很不方便;
KafkaTopic和Hive表的血缘关系获取不方便;
因此 , 我们基于spark-sql-kafka开发hamal , 旨在解决如上痛点并且让配置更加的简洁 。 实现的过程大概包括 , spark-sql-kafka会根据输入的任务从Kafka各个Partition消费出payload数据 , 对每条payload执行解编码、解压、magiccode等操作 , 此时会将payload数据转化成json字符串 , 这个json字符串可以直接作为一个字段写入到Hive表里 , 也可以根据事先配置提取出对应的节点和值作为列和列值写入到Hive中 , 甚至可以通过Json的Schema推断出Hive表结构 , 并将Json各节点对应写到Hive表的各列中 。
dbaplus社群TB@携程机票数据仓库11年技术栈的演进
文章图片
图4转化为json字符串RDD代码示例
如果选择推断的模式 , 实现的时候可以使用sampling的方式 , 类似sparkjsonRDD第二个参数 , 比如说0.001 , Hamal可以直接指定采样数据条数 , 从Kafkatopic中拉取出来 , 通过jsonRDD推断出StructType , 并映射成Hive建表语句 。 对于建好的表 , 通过表的字段匹配获取数据 , 最终写入Hive表 , 最后会提交消费记录到一张Hive的ConsumerRecord表里面 。 这样其实基于这个表 , 我们既可以获取Kafkatopic和Hive表的血缘 , 也可以方便地监控每次同步的数据量 。
dbaplus社群TB@携程机票数据仓库11年技术栈的演进
文章图片
图5Kafka同步至HiveHamal设计
2、数仓分层
分层设计主要参考公司推行的数据规范 , 将数据仓库的流程分成了生产镜像层(ods)、中间层(edw)、公共数据层(cdm)及应用数据层(adm) 。 在中间层对ods表做异常数据剔除、NULL值处理、枚举值统一等数据清理和绑定维表信息工作 , 在公共数据层对中间层表进行进一步的整合 , 丰富表主题的维度和度量 , 一般以宽表的形式呈现 , 用以后续的adhoc取数、报表 。
根据机票本身的业务特点 , 我们将数据划分成流量、产量、收益、生产KPI、业务考核等几大主题域 , 对数据表的业务分类和有效管理有重要意义 。
dbaplus社群TB@携程机票数据仓库11年技术栈的演进
文章图片
图6数仓分层设计
3、数据解析
数据在同步至数据ods层后 , 产品经常会提的一个需求是将ods层某个含报文字段的表按照字段设计展开 , 如果要支持此类需求 , 数据开发就需要了解生产上这个表各个字段含义及报文字段的契约定义 , 而这些对应表的写入开发非常熟悉 。 因此 , 为了提高整体的工作效率 , 我们开发了一套数据解析框架 , 对业务开发封装了大数据组件的API调用及相关参数调整 , 让业务开发更高效地完成熟悉的单条数据解析开发 。
dbaplus社群TB@携程机票数据仓库11年技术栈的演进
文章图片
图7数据解析框架
4、数仓运维工具
数据仓库拥有所有生产表的镜像表、数以万计的生产数据同步流程、数据扭转流程以及后续报表 , 对如此规模的数仓实体的管理和运维需要一个不断迭代的系统支持 , 从而可以大幅度提高数据工程师的效率 。
我们根据数仓建设中遇到的一些费力度较高且需要重复做的操作 , 开发了一套运维工具集合 , 目前还在持续迭代中 。 运维工具集功能主要包括数据实体通用搜索 , 报表收件人批量变更 , 维表导入 , Oncall录入 , 脚本模板生成 , 序列化与反序列化等等 。 工具开发难度不大 , 但对提高效率的帮助很大 。