简介：本文将会讲述共享充电宝创始企业复电科技如何基于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数仓；
  • 反对对用户组进行计算资源管理。
版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。