当前位置:   article > 正文

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

实时数仓 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。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/笔触狂放9/article/detail/687330
推荐阅读
相关标签
  

闽ICP备14008679号