Flink 在讯飞 AI 营销业务的实时数据分析实践
发布时间：2022-08-25 11:44:23 所属栏目：大数据 来源：互联网
导读：01业务简介 构建实时数据分析平台是为了更好的解决业务对更高数据时效性的需求，先简单介绍一下业务流程。 从日常的场景说起，当我们打开手机 APP 时，常会看到广告。在这样一个场景中，涉及到了两个比较重要的角色。一是手机 APP，即流量方；另一个是投广告
|
01业务简介 构建实时数据分析平台是为了更好的解决业务对更高数据时效性的需求，先简单介绍一下业务流程。 从日常的场景说起，当我们打开手机 APP 时，常会看到广告。在这样一个场景中，涉及到了两个比较重要的角色。一是手机 APP，即流量方；另一个是投广告的广告主，如支付宝、京东会投放电商广告。广告主购买流量方的流量投广告就产生了交易。 讯飞构建了一个流量交易平台，流量交易平台主要的职能是聚合下游流量，上游再对接广告主，从而帮助广告主和流量方在平台上进行交易。讯飞还构建了投放平台，这个平台更侧重于服务广告主，帮助广告主投放广告，优化广告效果。 在上述的业务流程图中，APP 与平台交互时会向平台发起请求，然后平台会下发广告，用户随后才能看到广告。用户看到广告的这个动作称之为一次曝光，APP 会把这次曝光行为上报给平台。如果用户点击了广告，那么 APP 也会上报点击行为。 广告在产生之后发生了很多行为，可以将广告的整个过程称为广告的一次生命周期，不仅限于图中的请求、曝光、点击这三次行为，后面可能还有下单、购买等。 在这样一个业务流程中，业务的核心诉求是什么呢？在广告的生命周期中有请求、曝光和点击等各种行为，这些行为会产生对应的业务日志。那么就需要从日志生成数据供业务侧分析，从日志到分析的过程中就引入了数仓构建、数仓分层，数据呈现的时效性就带来了实时数据仓库的发展。 02数仓演进 上图是一个典型的数仓分层框架，最底层是 ODS 数据，包括业务日志流、OLTP 数据库、第三方文档数据。经过 ETL 将 ODS 层的数据清洗成业务模型，也就是 DWD 层。 最初是建立了 Spark 数仓，将业务日志收集到 Kafka 中再投递到 HDFS 上，通过 Spark 对日志进行清洗建模，然后将业务模型再回写到 HDFS 上，再使用 Spark 对模型进行统计、分析、输出报表数据。后续，讯飞沿用了 Spark 技术栈引入了 spark-streaming。 随后逐渐将 spark-streaming 迁移到了 Flink 上，主要是因为 Flink 更高的时效性和对事件时间的支持。 当初 spark-streaming 的实践是微批的，一般设置 10 秒或是 30 秒一批，数据的时效性顶多是秒级的。而 Flink 可以支持事件驱动的开发模式，理论上时效性可以达到毫秒级。 当初基于 spark-streaming 的实时数据流逻辑较为简陋，没有形成一个数仓分层的结构。而 Flink 可以基于 watermark 支持事件时间，并且支持对延迟数据的处理，对于构建一个业务逻辑完备的数仓有很大的帮助。 由上图可见，ODS 的业务日志收集到 Kafka 中，Flink 从 Kafka 中消费业务日志，清洗处理后将业务模型再回写到 Kafka 中。然后再基于 Flink 去消费 Kafka 中的模型，提取维度和指标，统计后输出报表。有些报表会直接写到 sql 或 HBase 中，还有一些报表会回写到 Kafka 中，再由 Druid 从 Kafka 中主动摄取这部分报表数据。 在整个数据流图中 Flink 是核心的计算引擎，负责清洗日志、统计报表。 03场景实践 3.1 ODS - 日志消费负载均衡 ODS 业务中，请求日志量级大，其他日志量级小。这样请求日志（request_topic）在 Kafka 上分区多，曝光和点击日志（impress/click_topic）分区少。 （编辑：珠海站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
