数据库 频道

快狗打车实时数仓演进之路

快狗打车业务快速发展是公司众多人员的努力,同时对数据侧提出了更高的要求。数据的价值随着时间的增加而降低,分析以及运营更加希望实时数据助力业务发展,研发也希望借助BI侧的大数据综合计算能力得到汇总数据。

在这样的基础上,快狗打车实时数据仓库历经两次迭代,从Spark计算引擎到阿里云Blink+Flink,从Hbase存储到目前多样式OLAP系统使用。本文将分享快狗打车实时仓库的发展和实践。

▲快狗打车实时数据仓库负责人 杨铮

嘉宾介绍:2019年加入快狗打车,负责实时数据仓库整体架构。毕业于山东理工大学,在离线和实时数据仓库有丰富经验,热爱分布式相关技术,在OLAP,Flink,Spark等技术有较深理解。

分享大纲:

1、以往的开发流程和实时计算

2、从上云开始转变

3、解决痛点

4、应用

首先交代下,快狗打车实时数仓的业务背景。业务的复杂度比较高,业务线比较多,各个业务线之间数据相互关联,不相互独立。流量比较大,目前有小程序、APP端、网页、H5等,这些端产生的业务数据日增有几TB,如果全部应用到实时数仓里,对成本和计算都有压力。

此外,实时数据的应用场景也比较多,比如驾驶舱、报表、应用于线上的智能的调控等,这些场景对实时数据需求多。在业务发展初期时,也会面临或多或少的问题,比如开发时长等。

以往的开发流程和实时计算

在历史上,实时数据的开发流程如上图所示。首先,需求同学提出需求到数据产品经理。然后,数据产品经理再把需求下发到开发同学身上。在业务发展的快速期,更多的是以应对需求和快速解决问题为主。

在开发时,会出现重复的任务,然后就形成了一系列问题。比如,烟囱式开发会导致任务堆积,任务的血缘变得混乱。在这个时候,我们逐步发现,运维成本和机器成本变得非常高,数据的复用性也很差。

关于实时计算的过程,从DS到kafka,然后Spark消费kafka的数据,继而产生服务。这在当时来讲,是一个非常简单的流程。它的叠加历史时期,也是一个业务快速发展的时期,我们在上面堆积了非常多的任务,从风控到流量,以及驾驶舱等一系列的任务。

我们发现,开发成本非常高,通用化模版应用少,功能越复杂,开发成本越高,大量时间在编码设计上。早期Spark版本维护有困难,任务失败修复重复数据带来的高昂运维成本。另外,当时使用服务没有节制,服务链路无监控,导致数据源维护成本高。开发应用服务混乱,数据得不到统一,冗余数据也越来越多。

从上云开始转变

从所有的离线数仓和实时数仓迁移上云开始,我们决定做一次完整的改变。在2019年之前,我们使用Spark作为主流的处理引擎,加上多存储的数据源。数据服务大多来自于这些数据源,比如,Mysql、ES等存储引擎。

在2019年到2020年之间,我们完成了一次上云,把整体的离线数仓和实时数仓都迁移到阿里云上面。在这个时期,我们提出了两点:一个是OneData,一个是OneService。

从2020年开始,我们开启了智能化系列。比如说,智能调优、智能运营等一系列的基于实时数据的智能化操作。

解决痛点

在上云的时候,以解决我们的痛点为主,烟囱式的开发,数据得不到复用,成本无限的增高,没有合理的架构,当时是为了解决问题而存在,现在我们希望沉淀数据。

首先,第一点是模型升级,我们采取了大家认可的分层模型,为了摆脱混乱开发,建设分层模型,主要目的是让数据重复利用。我们采取实时和离线完全相等的方案,这么操作运维起来很方便。

我们严格按照离线模型,区分了几个层面。第一是ODS基础数据层,第二是DWS服务数据层,第三是DWF事实数据层,第四是DWA高度汇总数据层,第五是DIM维度数据层。

之前我们使用的是Spark,后来用到了Flink。上云的基础运用的是阿里云云原生,最开始是Flink,现在是全托管Flink,很少用到开源的Flink。从Spark迁移到Flink,很大的一部分原因是希望得到效率方面的巨大提升。

在ODS层面,我们已经做了一次格式的预处理。当时在架构设计方面实现离线实时一体化。RDS主要为Binlog订阅,添加中间处理,统一数据格式。日志数据是通过各个端上的日志传输,统一规范,日志中心格式处理。

上图是数据一键集成图,在这里,只需要我们填写DTS标识、库名、表名、Topic,它就会自动的一键创建数据,并且自动转化出来,把数据格式经过一次处理传输,直接转发到kafka里面。

一键配置平台的数据订阅工作,极大的节省了我们与DBA沟通把数据订阅进来的操作流程。另外,创建Topic、删除Topic、消费位点等一系列操作都可以在一键配置平台上进行操作。自动格式化数据,方便后续做模版化的开发,不需要进行定制化开发。

关于开发模版的大致流程分为四步:

第一,Flink SQL读取kafka数据源格式固定,可变的是topic参数和读取位点,group等;

第二,创建视图,利用核心UDF统一离线和实时Schema信息,任务启动阶段进行校验两方的shcema信息(类型,名称等),严格一致;

第三,多流处理阶段,一般无法定制模板,需要注意state,资源等;

第四,输出阶段,分为输出至OLAP、Mysql、Kafka,输出至Kafka利用核心UDF固定格式。

在数据流入和流出阶段,进行严格的格式控制,利用通用模板提高效率,同时保持离线实时一致。

事实上,日志处理是一个非常麻烦的过程,占用大量的时间。所以,我们做了一次集成化的处理,做成了一个参数化配置的平台,仅需传入离线日志表,任务自动获取离线任务所有信息,自动配置到实时任务。

它类似于一个动态规则的配置,自动创建topic,初步清洗好的日志数据自动传入topic,并且优化格式。此外,这个任务还具有资源优化功能,内部核心为任务清洗程序,配置后台,根据任务资源,日志数据切分任务,极大缩短开发时间。

在我们平滑上云之后,用了三个主存储系统。第一个是Hbase+ES,Hbase存储数据+ES构建加速查询索引。第二个是阿里云ADB(云原生数据仓库),同时也是即席分析平台,支持存算分离、动态扩展、高并发等。第三个是我们与阿里云共建的Hologres,主要使用的HOL AP系统,支持PB级别,支持高并发。

我们在Hologres用到读写分离的架构,Hologres支持实时+离线数据映射查询,支持联邦查询,实时和离线数据混合使用。支持统一数据出口,无论是即席分析还是实时接口查询等,数据出口均在Hologres。

应用

构建好实时数据仓库之后,有哪些应用?

首先,对外提供应用接口。比如,Http接口,灵活性高,可拓展性强;采取表映射形式,可以解耦,无感知变更;接口监测,所有接口的响应时长,ip,查询频率等进行资源监控;平台一站式开发,内部研发的接口管理平台,上线接口从测试到上线达到分钟级别;慢查询监控,慢查询及时监控预警。

接口开发平台的接口配置为SQL开发,测试之后自动生成接口id,分钟级别上线。目前接口规模300+个,平均查询时长在毫秒级别。

在风控应用方面,业务数据经过消息队列里面的消费,加工,然后传输到图计算里面,离线数据先把全量灌进去,然后实时的增量数据构建插入。这部分更多体现我们在风控和图计算方面的内容。

关于指标预警,通过构建运营同学关注的指标,可以以自定义规则定制实时预警和离线预警方式,目前支持SQL和指标形式进行监控,小时级别和天级别的预警,智能预警形式结合算法,自动测算,实时预警。

OneData指标管理是实时指标和离线指标统一管理平台,具备指标血缘、版本等各种管理功能。无论实时或者离线指标,首先是指标管理平台收录,再进行三方嵌入使用。

上图是实时数仓整体架构图,从ODS、DWS、DWF、DWA,经过FlinkSQL一层一层的加工,数据分别存入到Kafka/Holo,在往上进入到OneData、OneService,最后进入到应用体系。

展望未来,我们希望通过流批一体,达到一套系统,一个逻辑。目前来讲,我们实现了实时数据离线数据相互统一,但是它仍然存在数据交互的问题。另外,它依然是两套系统,务必存在系统之间的相互隔离。同时,我们正在做一套动态规则,智能营销,实现运营策略。

0
相关文章