基于Flink的资讯场景实时数仓

)

1. 实时数仓介绍

1.1.什么是实时数仓

数据仓库定义：https://en.wikipedia.org/wiki/Data_warehouse，本质是把各种业务系
统产生的数据通过一定的方式（数仓构建方法论）统一处理，从而产生更大的业务价
值。

数据仓库的价值：Successful enterprises must learn from the past, act in the present,and prepare for the future。

⚫ ‘Learn from the past’ ：离线数仓，分析历史数据。
⚫ ‘Act in the present’ ：实时数仓，对当前数据进行监控及分析。
⚫ ‘Prepare for the future’ ：机器学习，根据历史数据对未来趋势进行推断。
在演进过程中，数仓被分为两类：实时数仓和离线数仓。两者的差别：
⚫ 业务层面：
ￚ 在数据可见时间上，离线数仓一般最快要 5 分钟，大部分任务的数据产出时间在小时/天级别。
ￚ 实时数仓到底有多快？应该有多快？这些完全取决于业务的需求。比如淘宝双11 大屏，从数据采集到最终展示，只需要 3 秒。当然，极致的速度必然会有较高的成本。一般来说，实时数仓架构中，从数据产生到最终服务于业务系统，整条链路时间在 3 分钟以内。
⚫ 架构层面：
ￚ离线数仓一般用 hive 等进行数据计算和存储。
ￚ实时数仓一般用 Flink 进行数据处理，OLAP 等系统进行数据存储及分析。

1.2.实时数仓技术架构

实时数仓的构建，从原始数据到最终业务系统，数据需要经过采集、加工、分析、挖掘等步骤。与传统离线数仓的构建相似，中间会涉及数据 ETL，数仓的建模，数据多维分析等过程。每个过程又会涉及多个系统，如数据加工部分会涉及到数据通道类系统（如阿里云消息队列 Kafka 等）；数据多维分析会涉及到 OLAP 相关系统（如阿里云分析型数据库等）。
实时数仓的数据处理过程涉及到以下几个关键环节：

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

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

• 数据采集： 日志和数据库数据需要通过数据通道（如消息队列 Kafka）使整条数据链路‘流动’起来。比如日志中的数据，可通过日志采集等工具被实时上报到消息队列 Kafka 中；数据库中的数据，可通过数据传输服务 DTS(Data Transmission Service) 被实时数据同步到消息队列 Kafka 中。

• 数据加工： 消息队列收到的原始数据，往往存在格式不齐或内容不全，需要经过数据清洗（ETL）之后，才能更好的被下游业务使用。而整个 ETL 过程，是实时数仓架构设计上非常重要的一环，该环节要做到延时小，成本低，可扩展性好，业务指标计算准确。
  在系统选型上，推荐使用实时计算 Flink 对数据进行处理，因为 Flink 具有强大的数据处理能力，低延时，高吞吐，能够保证业务产出。
  在数据架构设计上，可以依据数仓的基本方法论来构建 ODS/DWD/DWS 层，从而减少数据冗余，降低 OLAP 系统的数据存储成本，并且使数据结构具有更好的可扩展性。

• 数据分析： 经过数据加工处理好的数据，一部分可以直接被业务方使用，如 APP当日激活/PV/UV 等实时指标；另一部分需要将数据写入 OLAP 系统，经过多维分析给业务方使用。

• 数据挖掘： 从历史中预测未来一直是人类的梦想，对公司来说，能对未来趋势作出正确的判断才能基业长青。机器学习就是通过历史数据对未来进行预测的一种手段，可以使数据发挥最大的作用。

• 业务系统： 经过处理的数据，可直接服务于相关业务方，如运营、决策者、相关应用等。例如，运营人员可通过实时报表中的客流分析，及时调整运营策略，提高活动转化率；实现实时风控和在线流量反作弊，避免业务损失。

2. 资讯场景介绍与技术架构设计

构建任何技术或大数据系统的第一步，一定是梳理清楚系统要服务的业务，以及该业务对公司带来的价值。之后才能进行架构设计，系统选型，容量评估等技术相关工作。本章节首先介绍资讯聚合类业务的典型业务场景及相关业务目标，然后设计相应的技术架构。

2.1.业务场景

XXX 公司开发了一个知识分享类 APP：

• 自媒体作者可以在 APP 上发布新闻、时事评论、技术分享等文章。
• 用户可阅读文章并对喜爱的文章点赞、收藏或打赏。
  业务的构建涉及到几个端：
• APP 应用：用户访问文章的入口。
• 文章管理系统：自媒体作者管理文章，查看文章点赞数、打赏数、打赏金额等功能。
• 平台管理后台：运营人员对内容进行管理，监控并分析 APP 核心业务指标。
  a) 文章内容审核，对有争议文章进行人工审核
  b) 违规内容下架。
  c) 业务指标查看。

2.2.业务目标

业务部门需要实时计算出以下的核心业务指标，对每天的运营工作进行数据支撑。

• 当天的实时 UV/PV。
• 当天各类目的实时 PV/UV。
• 当天各类目的实时曝光、点击、点赞、打赏次数，以及打赏总金额。
• 当天 TopN PV 的热门文章 。
• 当天 TopN PV 的热门类目。
• 当天打赏总数 TopN 的类目。
• 当天打赏总数 TopN 的作者。
• 实时分析用户地理分布。
• 实时分析用户短期行为偏好。如 5 分钟内用户连续 3 次及以上点击、点赞或打赏某类目的文章，认为用户短期行为偏好该类目，后续可对用户推荐该类目文章。

2.3.技术架构

分析以上的业务场景和业务目标，需要通过搭建一个实时数仓为业务决策和发展提供数据支撑。参考 1.2 节实时数仓技术架构，针对本章节资讯聚合类业务场景，采用下图所示的实时数仓技术架构：
1. 数据采集：
采用消息队列 Kafka 实现 APP 日志聚合，生成 ODS（Operational Data Store，操作数据层）。ODS 存放原始数据，直接加载原始日志、数据，数据保持原貌不做处理。

• 数据加工：
  采用消息队列 Kafka + 实时计算 Flink 实现实时 ETL 和数据流，生成 DWD(DataWarehouse Detail，明细数据层)。DWD 对 ODS 层数据进行清洗（如解码、去除空值和脏数据等）和加维。
• a) 客户端直接收集上来的原始数据，一般来说，为了节省带宽，都会经过加密等操作，需要经过解码等操作才能被使用。注：本实践略过解码部分处理，只进行数据格式转化进行示例。
• b) 通过多数据源 join、流式数据与离线维度信息等的组合，将一些相同粒度的业务系统、维表中的维度属性全部关联到一起，增加数据易用性和复用性，得到最终的实时明细数据，生成 DWD。注：本实践通过云数据库 RDS 存储维表信息。

3.数据分析：
采用实时计算 Flink + AnalyticDB for MySQL 实现实时数据分析 + 多维数据分析。数据分析包括以下两步：

• a) 通过实时计算 Flink 抽取 DWD 中对应信息并进行轻度汇总（如部分业务指标计算），生成 DWS（Data Warehouse Summary，汇总数据层），并将数据存储到 AnalyticDB for MySQL。
• b) 通过 AnalyticDB for MySQL 进行多维数据分析和大屏实时查询。

4. 业务系统：
业务系统通过 DataV 数据可视化实现业务指标实时大屏展示。
推荐系统捕获用户短期行为偏好事件，推荐用户偏好的类目。

中间是使用阿里产品的方法 省略

4. 实时数仓搭建

本章从数据采集、数据加工、数据分析到业务系统，全链路的介绍如何搭建实时数仓。
注意：本章 FLink SQL 脚本请使用前进行变量替换。

4.1.数据采集

原始日志字段设计见下表：

原始日志样例：
{“message”:“2022-02-15 00:00:000,111,oppo-01,183.160.64.64,0001,100001,002,100001,0”}
{“message”:“2022-02-15 00:02:000,112,vivo-01,210.51.167.169,0004,100002,002,300001,0”}
{“message”:“2022-02-15 00:03:000,111,oppo-01,183.160.64.64,0002,100001,001,100002,0”}
{“message”:“2022-02-15 00:04:000,113,iphone-01,183.156.1.1,0002,100003,003,100003,0”}
{“message”:“2022-02-15 00:04:000,111,oppo-01,183.160.64.64,0003,100001,004,100005,20.2”}
{“message”:“2022-02-15
00:05:000,113,iphone-
01,219.134.104.255,0001,100003,004,400001,30”}
{“message”:“2022-02-15 00:07:000,112,vivo-01,210.51.167.169,0102,100002,001,200001,0”}
{“message”:“2022-02-15 00:07:000,114,vivo-01,210.51.167.169,0102,100002,001,200001,0”}
{“message”:“2022-02-15 00:07:000,114,vivo-01,210.51.167.169,0102,100002,004,200001,100”}
{“message”:“2022-02-15 00:12:000,112,vivo-01,210.51.167.169,0001,100002,002,300001,0”}
{“message”:“2022-02-15 00:13:000,111,oppo-01,183.160.64.64,0001,100001,001,100002,0”}
{“message”:“2022-02-15
00:24:000,113,iphone-
01,219.134.104.255,0001,100003,003,100003,0”}
{“message”:“2022-02-15 00:34:000,111,oppo-01,183.160.64.64,0001,100001,004,100005,20.2”}
{“message”:“2022-02-15
00:55:000,113,iphone-
01,219.134.104.255,0001,100003,004,400001,30”}
{“message”:“2022-02-15 12:00:000,111,oppo-01,183.160.64.64,0001,100001,002,100001,0”}
{“message”:“2022-02-15 18:33:000,112,vivo-01,210.51.167.169,0101,100002,001,200001,0”}
{“message”:“2022-02-15 18:33:100,114,vivo-01,210.51.167.169,0101,100002,001,200001,0”}
{“message”:“2022-02-15 18:33:200,114,vivo-01,210.51.167.169,0101,100002,004,200001,100”}
步骤1 本实践通过3.5.1中部署的Kafka客户端模拟发送埋点日志到消息队列Kafka的Topic：app_log_origin。
./bin/kafka-console-producer.sh --broker-list { 默认接入点 } --topic
app_log_origin
发送一条消息：
{“message”:“2022-02-21 00:00:000,111,oppo-01,183.160.64.64,0001,100001,002,100001,0”}
注意：生产环境可以使用 Kafka REST Proxy（https://docs.confluent.io/3.0.0/kafka-rest/docs/intro.html）接收移动 APP 的埋点日志，再将埋点日志转发到消息队列 Kafka。