Flink 实时数仓建设

1.实时数仓建设背景

离线数仓技术架构成熟，业务目标明确。但是，随着行业技术发的发展，离线数仓的问题也暴露出来：

• 数据处理链路长：数据往往要经过多级 ETL（Extract、Transform、Load）处理后，才能进行最终展示；
  • ETL的设计分三部分：数据抽取、数据清洗转换、数据的加载。
    • 数据抽取是从各个不同的数据源抽取到ODS中（Operational Data Store，操作型数据存储，这个过程也可以做一些数据的清洗和转换）。
    • 数据清洗转换，数据清洗是去除空值、脏数据、超过极限范围的数据；数据转换数据转换的任务主要进行不一致的数据转换、数据粒度的转换。
      • 不一致数据转换：这个过程是一个整合的过程，将不同业务系统的相同类型的数据统一，比如同一个供应商在结算系统的编码是XX0001，而在CRM中编码是YY0001，这样在抽取过来之后统一转换成一个编码。
      • 数据粒度的转换：业务系统一般存储非常明细的数据，而数据仓库中数据是用来分析的，不需要非常明细的数据。一般情况下，会将业务系统数据按照数据仓库粒度进行转换。
    • 数据加载一般在数据清洗转换之后直接写入DW（Data Warehousing，数据仓库）中去。
• 周期长，业务指标滞后：数据从采集到应用往往小时级别，甚至天级别；

在某些场景下，以上问题会导致数据处理速度不符合业务需求，比如：

• 实时广告投放：广告平台需要实时计算来分析用户行为数据并实时调整广告投放策略；
• IoT应用：物联网应用需要实时计算来处理传感器数据并触发相应的操作；
• 电商大促：电商平台需要实时计算券的核销数据并实时调整券的投放策略；
• 资金风控：线上活动场景中，黄牛党/羊毛党的识别需要秒级反馈，因为每秒都意味着几万/几十万的资金损失；

2.实时数仓介绍

2.1 实时OR离线选型

数据仓库有一个很重要的功能，即能够记录历史。通常，数仓都是希望从业务上线的第一天开始有数据，然后一直记录到现在。

但实时处理技术，又是强调当下处理状态的一门技术，所以这两个相对对立的方案重叠在一起的时候，它注定不是用来解决一个比较广泛问题的一种方案。

于是，我们把实时数仓建设的目的定位为解决由于离线数据仓库数据时效性低解决不了的问题。由于这个特点，我们给定了两个原则：

1.离线数仓能解决的问题，实时数仓就不解决了。比如上个月的一些历史的统计，这些数据是不会用实时数仓来建设的。

2.问题本身就不太适合用数仓来解决，也不用实时数仓解决。比如业务性很强的需求（比如 实时计算用户存款账户余额），实时数仓可能并不适合解决这些需求。

当然为了让我们整个系统看起来像是一个数仓，我们还是给自己提了一些要求的。这个要求其实跟我们建立离线数仓的要求是一样的：首先实时的数仓是需要面向主题的，然后具有集成性，并且保证相对稳定。

实时数仓和离线数仓。两者的差别：

• 业务层面：数据可见时间 - 离线数仓一般最快也是分钟级别，大部分离线数仓任务的数据产出时间在小时/天级别。
• 架构层面：离线数仓一般用Hive等进行数据计算(MR或者Spark)和存储。实时数仓一般用Flink进行数据处理。
• 存储层面：离线数据仓库是一个保存历史累积的数据，而我们在建设实时数仓的时候，一般只保留上一次批处理到当前的数据。

那么实时数仓到底有多快？应该有多快？这些完全取决于业务的需求。比如淘宝双11大屏，从数据采集到最终展示，只需要3秒。当然，极致的速度必然会有较高的成本。一般来说，实时数仓架构中，从数据产生到最终服务于业务系统，整条链路时间在1分钟以内。

2.2 实时VS离线开发

• 编程方式

离线开发最常见的方案就是采用 Hive SQL 进行开发。实时数仓里使用 Flink SQL和Flink DataStream两种方式 ，同样也是配合 UDF 来进行开发。

• 作业执行层面

离线处理的执行层面一般是 MapReduce 或者 Spark Job ，对应到实时数仓就是一个24h持续不断运行的 Flink Streaming 的程序。

• 数仓对象层面

离线数仓实际上就是在使用 Hive 表。对于实时数仓来讲，我们对表的抽象是使用 Stream Table 来进行抽象。

• 物理存储

离线数仓，我们多数情况下会使用 HDFS 进行存储。实时数仓，我们更多的时候会采用像 Kafka 这样的消息队列来进行实时数据的存储。

3.实时数仓构建

3.1 方案架构

Hologres是一站式实时数仓，支持数据实时写入与更新，实时数据写入即可查。Hologres与Flink深度集成，能够提供一体化的实时数仓联合解决方案。本文基于Flink+Hologres搭建实时数仓的方案架构如下：

1. Flink将数据源写入Hologres，形成ODS层。
2. Flink订阅ODS层的Binlog进行加工，形成DWD层再次写入Hologres。
3. Flink订阅DWD层的Binlog，通过计算形成DWS层，再次写入Hologres。
4. 最后由Hologres对外提供应用查询。

3.2 实践场景

以某个电商平台为例，通过搭建一套实时数仓，实现数据的实时加工清洗和对接上层应用数据查询，形成实时数据的分层和复用，支撑各个业务方的报表查询（交易大屏、行为数据分析、用户画像标签）以及个性化推荐等多个业务场景。

1.构建ODS层：业务数据库实时入仓

MySQL有orders（订单表），orders_pay（订单支付表），product_catalog（商品类别字典表）3张业务表，这3张表通过Flink实时同步到Hologres中作为ODS层。

2.构建DWD层：实时主题宽表

将订单表、商品类别字典表、订单支付表进行实时打宽，生成DWD层宽表。

3.构建DWS层：实时指标计算

实时消费宽表的binlog，事件驱动的聚合出相应的DWS层指标表；

4.实时数仓应用场景

4.1 实时报表

电商场景下，会通过实时计算一些营收指标比如GMV,订单数，买家数等指标，写入KEY-Value类型的数据库，比如Redis ,根据定义KEY查询各类聚合指标表；

4.2 实时 OLAP 分析

OLAP 分析本身就非常适合用数仓去解决的一类问题，我们通过实时数仓的扩展，把数仓的时效性能力进行提升。甚至可能在分析层面上都不用再做太多改造，就可以使原有的 OLAP 分析工具具有分析实时数据的能力。

4.3 实时风控

通过汇总指标的运算给用户标记上一些特征来进行风险控制；

4.4 IOT实时监控

流计算分析大量工业传感器传入数据，实时进行数据清洗和归纳，可以帮助用户实时分析和诊断工业设备的运行状况，实时检测运行故障，实时预测制品良率，实时监控设备关键指标、实时将数据清洗并写入在线OLAP系统和MQ ,通过MQ作为告警消息源，更好保证数据投递过程中避免用户告警系统故障，导致告警信息遗漏，保证告警准确性。

5.实时数仓架构总结

前面介绍了实时数仓常见应用场景，对于实时数仓的构建，从原始数据到最终业务系统，数据需要经过采集，加工，分析，挖掘等步骤。与传统离线数仓的构建相似，中间会涉及数据 ETL，数仓的建模，数据多维分析等过程，每个过程又会涉及多个系统，如数据加工及实时计算部分，就会涉及到 kafka + Flink。数据多维分析会涉及到 OLAP 相关系统，比如产品如Hologres, Clickhouse、Doris。数据处理过程示意如下：

实时数仓的数据处理过程涉及到以下几个关键环节：

1.数据产生：一般场景下，数据有两个来源

• 用户行为日志：用户在app上的操作会产生一系列日志，包括点击，跳转，浏览，停留时长，机型，ip等信息。
• 数据库中相关信息：用户下单等业务类行为，会被记录到数据库中。

2.数据采集：日志和数据库的内容，需要上报到消息队列中，使整条数据链路流动起来。比如日志中的数据，可通过日志采集等工具被实时上报到消息队列中。而mysql的数据（binlog），可通过 canal ,flink cdc等开源组件被实时采集到消息队列中。

3.数据加工：消息队列（比如kafka）的原始数据，往往格式不齐，内容不全，需要经过数据清洗（ETL）之后，才能更好的被下游业务利用。而整个ETL过程，是实时数仓架构设计上非常重要的一环。该环节要做到延时小，成本低，可扩展性好，业务指标计算准确。

• 在系统选型上，需要选择Flink对数据进行处理，Flink具有强大的数据处理能力，低延时，高吞吐，从而保证业务产出。
• 在数据架构设计上，也可以依据数仓的基本方法论来构建成ODS/DWD/ADS层，从而减少数据冗余，降低数据存储成本，并且使数据结构有更好的可扩展性。

4.数据分析：经过Flink（ETL）处理好的部分数据可以直接被业务方使用，如app当日激活/pv/uv等实时指标。另一部分数据需要经过多维分析才能被业务方使用，这就需要用到OLAP系统，将数据写入OLAP系统后，通过与历史数据的合并查询，即可得到相关数据。

5.业务系统：经过处理的数据，可直接服务于相关业务方，如运营，决策者，相关应用等，如运营人员可通过实时报表中的数据及时调整运营策略，提高活动转化率，实时风控，可避免业务损失等。