快狗打车实时数仓演变之路
发布时间：2023-02-16 10:08:43 所属栏目：大数据 来源：互联网
导读：快狗打车业务快速发展是公司众多人员的努力，同时对数据侧提出了更高的要求。数据的价值随着时间的增加而降低，分析以及运营更加希望实时数据助力业务发展，研发也希望借助BI侧的大数据综合计算能力得到汇总数据。 在这样的基础上，快狗打车实时数据仓库历经
|
快狗打车业务快速发展是公司众多人员的努力，同时对数据侧提出了更高的要求。数据的价值随着时间的增加而降低，分析以及运营更加希望实时数据助力业务发展，研发也希望借助BI侧的大数据综合计算能力得到汇总数据。 在这样的基础上，快狗打车实时数据仓库历经两次迭代，从Spark计算引擎到阿里云Blink+Flink，从Hbase存储到目前多样式OLAP系统使用。本文将分享快狗打车实时仓库的发展和实践。 首先交代下，快狗打车实时数仓的业务背景。业务的复杂度比较高，业务线比较多，各个业务线之间数据相互关联，不相互独立。流量比较大，目前有小程序、APP端、网页、H5等，这些端产生的业务数据日增有几TB，如果全部应用到实时数仓里，对成本和计算都有压力。 此外，实时数据的应用场景也比较多，比如驾驶舱、报表、应用于线上的智能的调控等，这些场景对实时数据需求多。在业务发展初期时，也会面临或多或少的问题，比如开发时长等。 以往的开发流程和实时计算 关于实时计算的过程，从DS到kafka，然后Spark消费kafka的数据，继而产生服务。这在当时来讲，是一个非常简单的流程。它的叠加历史时期，也是一个业务快速发展的时期，我们在上面堆积了非常多的任务，从风控到流量，以及驾驶舱等一系列的任务。 我们发现，开发成本非常高，通用化模版应用少，功能越复杂，开发成本越高，大量时间在编码设计上。早期Spark版本维护有困难，任务失败修复重复数据带来的高昂运维成本。另外，当时使用服务没有节制，服务链路无监控，导致数据源维护成本高。开发应用服务混乱，数据得不到统一，冗余数据也越来越多。 从上云开始转变 从所有的离线数仓和实时数仓迁移上云开始，我们决定做一次完整的改变。在2019年之前，我们使用Spark作为主流的处理引擎，加上多存储的数据源。数据服务大多来自于这些数据源，比如，Mysql、ES等存储引擎。 在2019年到2020年之间，我们完成了一次上云，把整体的离线数仓和实时数仓都迁移到阿里云上面。在这个时期，我们提出了两点：一个是OneData，一个是OneService。 从2020年开始，我们开启了智能化系列。比如说，智能调优、智能运营等一系列的基于实时数据的智能化操作。 解决痛点 在上云的时候，以解决我们的痛点为主，烟囱式的开发，数据得不到复用，成本无限的增高，没有合理的架构，当时是为了解决问题而存在，现在我们希望沉淀数据。 首先，第一点是模型升级，我们采取了大家认可的分层模型，为了摆脱混乱开发，建设分层模型，主要目的是让数据重复利用。我们采取实时和离线完全相等的方案，这么操作运维起来很方便。 我们严格按照离线模型，区分了几个层面。第一是ODS基础数据层，第二是DWS服务数据层，第三是DWF事实数据层，第四是DWA高度汇总数据层，第五是DIM维度数据层。 上图是数据一键集成图，在这里，只需要我们填写DTS标识、库名、表名、Topic，它就会自动的一键创建数据，并且自动转化出来，把数据格式经过一次处理传输，直接转发到kafka里面。 一键配置平台的数据订阅工作，极大的节省了我们与DBA沟通把数据订阅进来的操作流程。另外，创建Topic、删除Topic、消费位点等一系列操作都可以在一键配置平台上进行操作。自动格式化数据，方便后续做模版化的开发，不需要进行定制化开发。 关于开发模版的大致流程分为四步： 第一，Flink SQL读取kafka数据源格式固定，可变的是topic参数和读取位点，group等; 第二，创建视图，利用核心UDF统一离线和实时Schema信息，任务启动阶段进行校验两方的shcema信息(类型，名称等)，严格一致; 第三，输出阶段，分为输出至OLAP、Mysql、Kafka，输出至Kafka利用核心UDF固定格式。 在数据流入和流出阶段，进行严格的格式控制，利用通用模板提高效率，同时保持离线实时一致。 事实上，日志处理是一个非常麻烦的过程，占用大量的时间。所以，我们做了一次集成化的处理，做成了一个参数化配置的平台，仅需传入离线日志表，任务自动获取离线任务所有信息，自动配置到实时任务。 它类似于一个动态规则的配置，自动创建topic，初步清洗好的日志数据自动传入topic，并且优化格式。此外，这个任务还具有资源优化功能，内部核心为任务清洗程序，配置后台，根据任务资源，日志数据切分任务，极大缩短开发时间。 在我们平滑上云之后，用了三个主存储系统。第一个是Hbase+ES，Hbase存储数据+ES构建加速查询索引。第二个是阿里云ADB(云原生数据仓库)，同时也是即席分析平台，支持存算分离、动态扩展、高并发等。第三个是我们与阿里云共建的Hologres，主要使用的HOL AP系统，支持PB级别，支持高并发。 我们在Hologres用到读写分离的架构，Hologres支持实时+离线数据映射查询，支持联邦查询，实时和离线数据混合使用。支持统一数据出口，无论是即席分析还是实时接口查询等，数据出口均在Hologres。 首先，对外提供应用接口。比如，Http接口，灵活性高，可拓展性强;采取表映射形式，可以解耦，无感知变更;接口监测，所有接口的响应时长，ip，查询频率等进行资源监控;平台一站式开发，内部研发的接口管理平台，上线接口从测试到上线达到分钟级别;慢查询监控，慢查询及时监控预警。 接口开发平台的接口配置为SQL开发，测试之后自动生成接口id，分钟级别上线。目前接口规模300+个，平均查询时长在毫秒级别。 实时数仓整体架构图，从ODS、DWS、DWF、DWA，经过FlinkSQL一层一层的加工，数据分别存入到Kafka/Holo，在往上进入到OneData、OneService，最后进入到应用体系。 展望未来，我们希望通过流批一体，达到一套系统，一个逻辑。目前来讲，我们实现了实时数据离线数据相互统一，但是它仍然存在数据交互的问题。另外，它依然是两套系统，务必存在系统之间的相互隔离。同时，我们正在做一套动态规则，智能营销，实现运营策略。 （编辑：甘南站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
