当前位置: 现金游戏网站现,澳门威尼斯游戏网站,欢乐水果游戏下载 > 反馈中心 > 携程机票数据仓库11年技术栈的演进

携程机票数据仓库11年技术栈的演进

原标题:携程机票数据仓库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、Spark Streaming和Flink的迭代,并徐徐拘谨到Flink。总体的技术演进历史如图1所示。

图1 数仓技术演进历史

2、现在技术栈

生产环境的数据能够大致分成三类:

1)营业数据,主要存储在MySQL和SQLServer,在这些有关型数据库内里有数以万计的外承接着各栽生产服务的营业数据写入;

2)基础数据,也是存储在MySQL和SQLServer中,生产行使时清淡会竖立一层中间化缓存(如Redis)或者本地缓存;

3)日志数据,这类数据的特点是”append only”,对已经生成的数据不会有更新的操作,考虑到这类数据的高吞吐量,生产环境清淡会用新闻队列Kafka暂存;

数据仓库在实走数据同步时,会根据需求在实时、近实时以及T 1天等差别的频率实走数据同步,并且在大数据环境会用差别的载体承接差别频率同步过来的数据。在携程机票,实时同步的现在的载体是ElasticSearch、CrateDB或者HBase,近实时(清淡T 1幼时)或者T 1天的现在的载体是Hive。

从生产的数据载体来讲,主要包括DB和新闻队列,他们的数据同步方案主要是:

1)生产DB到Hive的同步行使taobao开源的DataX,DataX由网站运营中间DP团队做了许众扩睁开发,现在声援了众栽数据源之间的数据同步。实时同步的场景主要在MySQL,行使DBA部分行使Canal解析并写入至新闻队列的bin log。

2)从Kafka到Hive同步行使Camus,但是由于Camus的性能题目及消耗记录和消耗过期较难监控的题目,吾们基于spark-sql-kafka开发了hamal,用于新建的Kafka到Hive的同步;Kafka实时同步的载体主要是ElasticSearch或者CrateDB,主要经过Flink实走。

生产数据被同步数据仓库后,会在数仓内完善数据清洗、新闻整相符、聚相符计算等数据扭转流程,最后数据出仓导入到其它载体,这一系列的流程调度由公司DP团队运维的调度平台Zeus完善。

图2 携程机票数仓技术栈

3、实时 VS 离线

现在机票部分的数据仓库建设主要基于离线数据,一方面跟OTA出售产品不属于快消品有关,实时现在并不是刚需;另一方面实时处理场景下必要对计算资源、存储资源安详性有更高的请求,保持数据一致性的代价很大。结相符两方面,倘若营业对实时需求不高就放开做实时数仓,ROI很难达标。

自然,随着携程营业体量的添长,数据行使方对数据实时性请求日好添高,吾们团队在2020年也会追求实时数据仓库的实走方案,并在一两个主要的数据主题域上先走试点。

数据仓库建设时涉及的共性题目

从团队职能上来讲,数据仓库团队必要负责从生产环境同步数据,在内部完善各层级的扭转计算,参与一切数仓流程及报外的运维,并基于数仓公共数据层和行使数据层数据开发有关行使。

1、数据同步

为了保持数仓数据主题隐瞒有余周详,吾们部分几乎将一切生产外和Kafka topics都同步到了Hive。以下会对同步最常见的两栽场景DB->Hive和Kafka->Hive有关的实践做介绍。

1)DB同步到Hive

稀奇对生产外到Hive的同步,人造配置脚本的方式隐晦不及处理数以万计的外,因此必要一个自动化的同步方案。自动同步方案必要不光仅要解决自动创建外脚本、创建对答的同步脚本题目,还必要在当外组织发生变更的时候,能够自动地感知外组织的转折,并且修改外结议和对答的同步脚本。

DB到Hive同步必要倚赖两个数据源,1)Schema外的元数据新闻,浅易地包括各个字段新闻、字段类型及主键定义;2)统计数据,它主要描述的是这个外在数据产生后有异国UPDATE和DELETE,这个决定着后续外的分区方式。

对营业型数据,一条数据生成后能够会有Update,由于在数仓里绝大片面场景必要用到数据的最新状态,因而吾们会用一个分区存放一切历史数据的最新状态,这类外吾们称之为历史切片外。对日志型数据,生产上数据产生后就不会有任何修改,吾们会选择行使添量分区,每个分区会放当天的添量数据。对基础数据,整个外的数据增补、更新的频率都专门矮,在ods层吾们会每天全量同步一份到最新数据分区,并且会竖立一个无分区的下游维外,将数据状态为有效的数据放到这张下游无分区维外中方便流程行使。

有了上述这两个数据源以后,吾们会根据DBA Schema服务返回的元数据新闻生成Hive外的脚本,并调度实走生成新的Hive外,再依据统计数据决定外的分区方式,进而生成对答新建外的同步脚本。当外创建或者外组织发生变更的时候,经过Schema服务两天输出的比对,吾们会发现外组织的变更并映射到对答Hive外组织变更,同时能够转折对答的同步脚本。还有一栽思路是能够经过DB发布体系的日志,获知每天DB创建、外创建以及外组织转折的添量。

图3 生产DB到Hive的同步

有一个坑点就是生产物理删除,倘若展现了物理删除并且必要在Hive外里将删除数据识别并标记出来,现在能够必要经过全量同步的方法(考虑到从生产环境取数的代价,全量同步营业主键字段即可)解决,稀奇对SQLServer。因此能够跟生产的开发商议尽量行使逻辑删除,云云数仓对删除数据的感知代价会幼许众。

2)Kafka同步到Hive

现在吾们非实时同步主要在行使Linkedin很久以前的一个工具Camus,自然DP团队经过优化和企业本地化二次开发。但从行使感受来望,Camus会有如下能够不及的地方:

基于mapreduce,mapreduce在yarn集群上抢占资源的能力较弱,在资源竞争高峰会有同步变慢的情况发生; 消耗记录存储在HDFS各个文件里,云云对消耗记录的获取和针对消耗过期的监控都很不方便; Kafka Topic和Hive外的血缘有关获取不方便;

因此,吾们基于spark-sql-kafka开发hamal,旨在解决如上痛点并且让配置更添的简洁。实现的过程也许包括,spark-sql-kafka会根据输入的义务从Kafka各个Partition消耗出payload数据,对每条payload实走解编码、解压、magic code等操作,此时会将payload数据转化成json字符串,这个json字符串能够直接行为一个字段写入到Hive外里,也能够根据事先配置挑掏出对答的节点和值行为列和列值写入到Hive中,甚至能够经过Json的Schema推想出Hive外组织,并将Json各节点对答写到Hive外的各列中。

图4 转化为json字符串RDD代码示例

倘若选择推想的模式,现金游戏网站现实现的时候能够行使sampling的方式,相通spark jsonRDD第二个参数,比如说0.001,Hamal能够直接指定采样数据条数,从Kafka topic中拉掏出来,经过jsonRDD推想出StructType,并映射成Hive建外语句。对于建好的外,经过外的字段匹配获取数据,最后写入Hive外,末了会挑交消耗记录到一张Hive的ConsumerRecord外内里。云云其实基于这个外,吾们既能够获取Kafka topic和Hive外的血缘,也能够方便地监控每次同步的数据量。

图5 Kafka同步至Hive Hamal设计

2、数仓分层

分层设计主要参考公司推走的数据规范,将数据仓库的流程分成了生产镜像层(ods)、中间层(edw)、公共数据层(cdm)及行使数据层(adm)。在中间层对ods外做变态数据剔除、NULL值处理、枚举值同一等数据清算和绑定维外新闻做事,在公共数据层对中间层外进走进一步的整相符,雄厚外主题的维度和度量,清淡以宽外的式样表现,用以后续的adhoc取数、报外。

根据机票自己的营业特点,吾们将数据划分成流量、产量、收入、生产KPI、营业考核等几大主题域,对数据外的营业分类和有效管理有主要意义。

图6 数仓分层设计

3、数据解析

数据在同步至数据ods层后,产品频繁会挑的一个需求是将ods层某个含报文字段的外遵命字段设计睁开,倘若要声援此类需求,数据开发就必要晓畅生产上这个外各个字段含义及报文字段的契约定义,而这些对答外的写入开发专门熟识。因此,为了挑高集体的做事效果,吾们开发了一套数据解析框架,对营业开发封装了大数据组件的API调用及有关参数调整,让营业开发更高效地完善熟识的单条数据解析开发。

图7 数据解析框架

4、数仓运维工具

数据仓库拥有一切生产外的镜像外、数以万计的生产数据同步流程、数据扭转流程以及后续报外,对如此周围的数仓实体的管理和运维必要一个一连迭代的体系声援,从而能够大幅度挑高数据工程师的效果。

吾们根据数仓建设中遇到的一些费力度较高且必要重复做的操作,开发了一套运维工具荟萃,现在还在赓续迭代中。运维工具集功能主要包括数据实体通用搜索,报外收件人批量变更,维外导入,Oncall录入,脚本模板生成,序列化与逆序列化等等。工具开发难度不大,但对挑高效果的协助很大。

数据质量体系

对重大的数据仓库实体建设完善的数据质量监控体系,光靠人造one by one竖立检验规则是不足的,必要对几乎一切的实体竖立响答的监控,并且不及给大数据集群带来许众额外的计算代价。当云云的隐瞒面很广的监控完善后,相符作着元数据新闻,就有能够在故障的Root Cause点第暂时间发现故障,并能够清亮地清新故障的影响周围以及故障恢复的流程优先级调度。

因此,竖立完善的数据质量体系必要完善元数据管理,竖立轻量的隐瞒面广的质量监控,并且对稀奇主要的流程,必要增补额外的营业有关校验。

1、元数据管理

在生产环境和大数据环境存在众栽实体,这些实体包括行使、各类外(如SQLServer、MySQL、MongoDB的外等)、新闻队列topic、ElasticSearch的index、Hive的外等等,这些实体相互有关,共同赞成着线上的体系,线下的分析。对这些新闻的治理,实体的元数据管理至关主要。

在数仓体系中,元数据主要包含基础新闻、血缘有关以及标签。基础新闻跟数据外有关,详细包括外的字段、存储、分区类型等;血缘会涉及到各类的实体,外、流程、报外、邮件推送等,这些实体之间存在着上下游调用与被调用有关,成体系地管理好这些实体之间的有关,能够清亮地晓畅到数仓边界,使得对故障的Root Cause追溯以及该Root Cause带来的影响面评估专门便捷。标签是对实体的分类描述,如层级是属于哪一层,坦然是否有涉密,主要等级,是否有专门主要的流程在上面,营业标签是属于订单、前端照样订后。

2、数据质量有关因素

数据质量的题目其实清淡能够在流程实走的日志中望出端倪,由于人造排查故障的时候,除了通例经过SQL查询验证外的添量、营业主键、某些字段值是否平常,另外一个有效手法就是分析运走日志。

从运走日志中能够获取以下新闻,流程的最先时间、截止时间流程实走时间、完善状态、每天添量的字节数、添量条数,引擎实走的参数,在用Spark或者MapReduce实走时消耗资源的情况等等一系列特征。经过对各类计算引擎产生日志的分析,能够获得各类引擎下记录日志数据的pattern,从而挑掏出有关的特征新闻。遇到稀奇的流程或者引擎,能够借用其他手法补齐特征数据,如用SQL,用Hadoop的命令。

图8 数据质量有关特征

这是吾们浅易的一个日志输出,第一张是Spark的实走日志,下面一张是MapReduce的实走日志。

图9 MR和Spark引擎实走日志示例

有了数据质量特征挑取的逻辑,实时流程变态发现能够如下实走:吾们能够将质量特征数据计算分成两块,一块是实时的针对单个流程日志的解析出有关特征,一块是离线的基于历史特征数据的统计。吾们从新闻队列中消耗实时获取实走完善的流程id和actionid,经过运维团队挑供的细目日志查询接口获取完善日志,经过特征解析逻辑,解析出实时的流程质量有关特征,匹配历史数据,行使规则。当已足变态规则,能够经过元数据新闻中的血缘判定影响的周围,推送告警新闻。

图10 实时流程变态监控实走方案

行使案例

携程行为平台方,对机票价格异国定价权,价格由产品挑供方来挑供。在每年航班计划换季的时候,产品挑供方会有一幼片面概率将价格录入错。舛讹的运价,稀奇是很矮的舛讹运价会让航司或供答商蒙受超大的亏损。本着公平营业的原则,携程行为出售平台,做了机票价格监控体系。上线至今,发现了数十首价格变态事件。

在生产的新闻队列中,吾们落地了用户查询返回的一切航班组相符和价格新闻,数据仓库完善近实时同步,将数据解析处理成变态价格有关特征集,每天的添量在百亿级别。吾们从Kafka实时消耗两类日志数据,一类是查询日志,一类是下单日志,竖立匹配,竖立规则集发现疑心的矮价营业标识,并且进一步监控跟营业标识是否进入下单流程。当某个疑似变态特征带来的订单超过必定阈值时,体系会对这疑似变态特征对答的查询进走自动禁售。

图11 价格监控体系

幼结

一套完善的数据仓库实走方案答该包括但不局限于上面介绍的数据同步方案、数据存储方案、数据规范、元数据建设、数据质量体系、运维工具等,每个实走团队答该根据面临的实际情况选择针对每个点的详细技术方案。

携程机票数据仓库团队也正朝着建设周详、规范、易用、高效、精准的数仓路上追求前走,现在在数据同步、数仓数据扭转以及出仓行使方面的实践方案还在随着需求的转折而迭代。接下来,吾们团队会偏重在数据仓库规范彻底落地以及实时数仓实走这些倾向上竭力。

作者丨华智

来源丨携程技术(ID:ctriptech)

dbaplus社群迎接普及技术人员投稿,投稿邮箱:editor@dbaplus.cn

近年来大数据技术发展快捷,并且一连别具匠心来体面新时代的海量数据处理需求。但随着技术的更迭,每次演进都必要消耗大量人员的精力与时间,以去的数据治理模式已经摇摇欲坠,此时DataOps答运而生。来和Gdevops全球敏捷运维峰会北京站一首望望联通大数据背后的DataOps体系建设:

《数据智能时代:构建能力盛开的运营商大数据DataOps体系》中国联通大数据基础平台负责人/资深架构师 尹正军

本次钻研现在的是让行家晓畅联通大数据背后的DataOps平台集体架构演进,包括数据采集交换添工过程、数据治理体系、数据坦然管控、能力盛开平台运营和大周围集群治理等核心实践内容。那么2020年9月11日,吾们在北京不见不散。

Gdevops全球敏捷运维峰会北京站:https://www.bagevent.com/event/6243820?bag_track=dbaplus

相关文章: