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

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

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

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

一、大数据平台介绍

1. 发展历程

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

1）离散 0.X Greenplum

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

2）离线 1.0 EMR

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

阿里云 EMR 主要解决我们三个痛点：

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

3）实时、统一 2.0 Flink + Hologres

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

2. 平台能力

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

数据集成
平台现在支持使用实时或者离线的方式集成业务数据库或业务数据的日志。
数据开发
平台现已支持基于 Spark 的离线计算以及基于 Flink 的实时计算。
数据服务

数据服务主要由两部分组成：
- 一部分是由 Impala 提供的分析服务和即席分析的能力；
- 另一部分是 Hologres 提供的针对业务数据的交互式分析能力。
数据应用
同时平台可以直接对接常见的 BI 工具，业务系统也能快速地集成对接。

3. 取得成就

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

横向扩展
大数据平台的核心就是分布式架构，这样我们能够低成本地水平扩展存储或者计算资源。
资源共享
可以整合所有服务器可用的资源。以前的架构是每个业务部门自己维护一套集群，这样会造成一些浪费，难以保证可靠性，而且运费成本较高，现在由平台统一调度。
数据共享
整合了业务部门所有的业务数据以及业务日志等其他异构数据源数据，由平台统一清洗对接。
服务共享
数据共享之后就由平台统一对外输出服务，各个业务线无需自行重复开发，就能快速得到平台提供的数据支撑。
安全保障
由平台提供统一的安全认证等授权机制，可以做到对不同人进行不同程度的细粒度授权，保证数据安全。

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

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

实时大屏
实时大屏需要替换旧的准实时大屏，采用更可靠、低延迟的技术方案。
统一数据服务
高性能、高并发和高可用的数据服务成为企业数字化转型统一数据门户的关键，需要构建一个统一的数据门户，统一对外输出。
实时数仓
数据时效性在企业运营中的重要性日益凸现，需要响应更快更及时。

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

1. 整体技术架构

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

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

2. 实时数仓数据模型

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

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

3. 整体技术架构数据流

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

从图中可以看出，主要分为三个模块：

第一个是集成处理；
第二个是实时数仓；
第三块是数据应用。

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

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

四、具体实践细节

1. 大数据技术选型

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

状态管理与容错机制；
Table API 和 Flink SQL 支持；
高吞吐低延迟；
Exactly Once 语义支持；
流批一体；
全托管等增值服务。

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

极速响应分析；
高并发读写；
计算存储分离；
简单易用。

2. 实时大屏业务实践落地

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

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

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

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

3. 实时数仓和统一数据服务实践落地

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

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

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

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