来电科技基于Flink+Hologres的实时数仓演进之路

Posted 2021-06-26 阿里云开发者

简介：本文将会讲述共享充电宝开创企业来电科技如何基于Flink+Hologres构建统一数据服务加速的实时数仓

作者：陈健新，来电科技数据仓库开发工程师，目前专注于负责来电科技大数据平台离线和实时架构的整合。

深圳来电科技有限公司（以下简称“来电科技”）是共享充电宝行业开创企业，主要业务覆盖充电宝自助租赁、定制商场导航机开发、广告展示设备及广告传播等服务。来电科技拥有业内立体化产品线，大中小机柜以及桌面型，目前全国超过90%的城市实现业务服务落地，注册用户超2亿人，实现全场景用户需求。

一、大数据平台介绍

（一）发展历程

来电科技大数据平台的发展历程主要分为以下三个阶段：

1.离散0.X Greenplum

为什么说离散？因为之前没有一个统一的大数据平台来支持数据服务，而是由每个业务开发线自行取数或者做一些计算，并用一个低配版的Greenplum离线服务来维持日常的数据需求。

2.离线1.0 EMR

之后架构升级为离线1.0 EMR，这里的EMR指的是阿里云由大数据组成的弹性分布式混合集群服务，包括Hadoop、HiveSpark离线计算等常见组件。

阿里云EMR主要解决我们三个痛点：一是存储计算资源的水平可扩展；二是解决了前面各个业务线异构数据带来的开发维护问题，由平台统一清洗入仓；三是我们可以建立自己的数仓分层体系，划分一个主题域，为我们的指标系统打好基础。

3.实时、统一 2.0 Flink+Hologres

当前正经历的“Flink+Hologres”实时数仓，这也是本文分享的核心。它为我们大数据平台带来了两个质的改变，一是实时计算，二是统一数据服务。基于这两点，我们加速知识数据探索，促进业务快速发展。

（二）平台能力

总的概括来说，2.0版本的大数据平台提供了以下能力：

1）数据集成

平台现在支持使用实时或者离线的方式集成业务数据库或业务数据的日志。

2）数据开发

平台现已支持基于Spark的离线计算以及基于Flink的实时计算。

3）数据服务

数据服务主要由两部分组成：一部分是由Impala提供的分析服务和即席分析的能力，另一部分是Hologres提供的针对业务数据的交互式分析能力。

4）数据应用

同时平台可以直接对接常见的BI工具，业务系统也能快速地集成对接。

（三）取得成就

大数据平台提供的能力给我们带来了不少成就，总结为以下五点：

1）横向扩展

大数据平台的核心就是分布式架构，这样我们能够低成本地水平扩展存储或者计算资源。

2）资源共享

可以整合所有服务器可用的资源。以前的架构是每个业务部门自己维护一套集群，这样会造成一些浪费，难以保证可靠性，而且运费成本较高，现在由平台统一调度。

3）数据共享

整合了业务部门所有的业务数据以及业务日志等其他异构数据源数据，由平台统一清洗对接。

4）服务共享

数据共享之后就由平台统一对外输出服务，各个业务线无需自行重复开发，就能快速得到平台提供的数据支撑。

5）安全保障

由平台提供统一的安全认证等授权机制，可以做到对不同人进行不同程度的细粒度授权，保证数据安全。

二、企业业务对数据方面的需求

随着业务的快速发展，构建统一的实时数仓迫在眉睫，综合0.x、1.0版本的平台架构，综合业务的现在发展和未来趋势判断，构建2.x版本数据平台的需求主要集中在以下几个方面：

1）实时大屏

实时大屏需要替换旧的准实时大屏，采用更可靠、低延迟的技术方案。

2）统一数据服务

高性能、高并发和高可用的数据服务成为企业数字化转型统一数据门户的关键，需要构建一个统一的数据门户，统一对外输出。

3）实时数仓

数据时效性在企业运营中的重要性日益凸现，需要响应更快更及时。

三、实时数仓和统一数据服务技术方案

（一）整体技术架构

技术架构主要分为四个部分，分别是数据ETL、实时数仓、离线数仓和数据应用。

• 数据ETL是对业务数据库和业务日志进行实时处理，统一使用Flink实时计算，
• 实时数仓中数据实时处理后进入Hologres存储与分析
• 业务冷数据存储在Hive离线数仓，并同步到Hologres做进一步的数据分析处理
• 由Hologres统一对接常用的 BI工具，如Tableau、Quick BI、DataV和业务系统等。

（二）实时数仓数据模型

如上所示，实时数仓和离线数仓有一些相似的地方，只不过少一些其它层的链路。

• 第一层是原始数据层，数据来源有两种类型，一种是业务库的Binlog，第二种是服务器的业务日志，统一用Kafka作为存储介质。
• 第二层是数据明细层，将原始数据层Kafka里面的信息进行ETL提取，作为实时明细存储至Kafka。这样做的目的是为了方便下游不同消费者同时订阅，同时方便后续应用层的使用。维表数据也是通过Hologres存储，来满足下面的数据关联或者条件过滤。
• 第三是数据应用层，这里除了打通Hologres，还使用了Hologres对接了Hive，由Hologres统一提供上层应用服务。

（三）整体技术架构数据流

下面的数据流图可以具象加深整体架构的规划和数仓模型整体的数据流向。

从图中可以看出，主要分为三个模块，第一个是集成处理，第二个是实时数仓，第三块是数据应用。

从数据的流入流出看到主要的核心有两点：

• 第一个核心是Flink的实时计算：可以从Kafka获取，或者直接Flink cdt读取mysql Binlog数据，或者直接再写回Kafka集群，这是一个核心。
• 第二个核心是统一数据服务：现在统一数据服务是由Hologres完成，避免数据孤岛产生的问题，或者一致性难以维护等，也加速了离线数据的分析。

四、具体实践细节

（一）大数据技术选型

方案执行分为两个部分：实时与服务分析。实时方面我们选择了阿里云Flink全托管的方式，它主要有以下几方面优点：

1）状态管理与容错机制；

2）Table API和Flink SQL支持；

3）高吞吐低延迟；

4）Exactly Once语义支持；

5）流批一体；

6）全托管等增值服务。

服务分析方面我们选择了阿里云Hologres交互式分析，它带来了几点好处：

1）极速响应分析；

2）高并发读写；

3）计算存储分离；

4）简单易用。

（二）实时大屏业务实践落地

上图为业务实时大屏新旧方案对比。

以订单为例，旧方案中的订单是从订单从库通过DTS同步到另一个数据库，这虽然是实时的，但是在计算与处理这方面，主要是通过定时任务，比如调度间隔时间设为1分钟或者5分钟来完成数据的实时更新，而销售层、管理层需要更实时地掌握业务动态，，因此并不能算真正意义上的实时。除此之外，响应慢且不稳定也是很大的问题。

新方案采用的是Flink实时计算+Hologres架构。

开发方式完全是可以利用Flink的SQL支持，对于我们之前的MySQL计算开发方式，可以说是一个无缝的迁移，实现快速落地。数据分析和服务统一使用Hologres。还是以订单为例，比如今日订单营收额，今日订单用户数或者今日订单用户量，随着业务多样性的增加，可能需要增加城市维度。通过Hologres的分析能力，可以完美支撑营收额、订单量、订单用户数以及城市维度的一些指标做快速展示。

（三）实时数仓和统一数据服务实践落地

以某块业务场景为例，比如量级比较大的业务日志，日均数据量在TB级别。下面先来分析一下旧方案的痛点：

• 数据时效性差：由于数据量较大，所以在旧方案中使用了每小时离线调度的策略进行数据计算。但是该方案时效性较差，无法满足众多业务产品的实时需求，例如硬件系统需要实时知道设备当前状态，如告警、错误、空仓等，以及时做出相应的决策行动。
• 数据孤岛：旧方案使用Tableau对接大量业务报表，报表用于分析过去一个小时或者过去一天，设备上报有多少数量，哪些设备上报出现异常等。针对不同的场景，会将之前通过Spark离线计算的数据，再备份存储到MySQL或者Redis上。这样就多套系统，形成数据孤岛，这些数据孤岛对平台维护是一个巨大的挑战。

现在通过2.0 Flink+Hologres架构，可以将业务日志进行改造。

• 以前TB级别的日志量在Flink高分子低延迟的计算框架下完全没有压力。例如之前的flume HDFS到Spark的一个链路直接被废弃，取而代之的是Flink，我们只需要维护一个Flink的计算框架即可。
• 设备状态数据采集的时候都是一些非结构的数据，需要对数据进行清洗，之后再返回Kafka，因为消费者可能是多样化的，这样可以方便下游的多个消费者同时订阅。
• 在刚才的场景中，硬件系统需要高并发、实时查询上千万的设备（充电宝）状态，对服务能力的要求较高。通过Hologres提供高并发读写能力，关联状态设备建立主键表，可以实时更新状态，满足CRM系统对设备（充电宝）的实时查询。
• 同时在Hologres还会存最近的热点明细数据，直接提供对外服务。

（四）业务支撑效果

通过Flink+Hologres的新方案，我们支撑了三大场景：

1）实时大屏

业务层面更高效地迭代多样化需求，同时降低了开发、运维维护开销。

2）统一数据服务

通过一个HSAP系统来实现服务/分析一体化，避免数据孤岛以及一致性、安全性等问题。

3）实时数仓

满足企业运营中对于数据时效性越来越高的要求，秒级响应。

五、未来规划

伴随着业务的迭代，我们未来在大数据平台的规划主要有两点：流批一体和完善实时数仓。

• 现在的大数据平台总的来说还是离线架构和实时架构混合，后续会废弃冗余的离线代码架构，借助Flink的流批一体统一计算引擎。
• 另外，我们目前只迁移了部分业务，所以会参考之前已经完善的离线数仓指标系统体系，来满足我们现在的实时数仓建设，全面迁移到2.0 Flink+Hologres架构上。

通过未来的规划，我们希望同Flink全托管和Hologres一起共建更加完善的实时数仓，但也在此对其有着更近一步的需求：

（一）对Flink全托管的需求

Flink全托管中的SQL编辑器编写FlinkSQL作业很高效方便，并且也提供了很多常见的SQL上下游 Connector满足开发需求。但是仍有一些需求希望Flink全托管在后续的迭代中支持：

• SQL作业版本控制和兼容性监测；
• SQL作业支持Hive3.X集成；
• DataStream作业打包更方便、资源包上传速度更快；
• Session集群模式部署的任务支持自动调优功能。

（二）对Hologres交互式分析的需求

Hologres不仅能够支持高并发地实时写入和查询，并且兼容PostgreSQL生态，方便接入使用统一数据服务。但是仍有一些需求希望Hologres能在后期迭代中支持：

• 支持热升级操作，减少对业务的影响；
• 支持数据表备份、支持读写分离；
• 支持加速查询阿里云EMR-Hive数仓；
• 支持对用户组进行计算资源管理。

原文链接：https://developer.aliyun.com/article/784437?

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。