关于实时数仓的几点技术分享

置顶派可数据

于 2024-09-18 10:33:09 发布

阅读量300

点赞数 6

分类专栏：商业智能数字化转型数据仓库文章标签： java spring 开发语言数据仓库商业智能BI

本文链接：https://blog.csdn.net/weixin_44958787/article/details/142326840

版权

商业智能同时被 3 个专栏收录

565 篇文章 10 订阅

订阅专栏

数据仓库

356 篇文章 16 订阅

订阅专栏

数字化转型

285 篇文章 7 订阅

订阅专栏

一、实时数仓建设背景

业务需求的变化：随着互联网和移动互联网的快速发展，企业的业务需求变得越来越复杂和多样化，对数据处理的速度和质量要求也越来越高。传统的T+1数据处理模式已经无法满足企业的需求，实时数据处理成为了一种必要的需求。
数据时效性的重要性：在当今数据驱动的时代，数据的时效性对于企业的决策和运营至关重要。实时数仓能够提供实时的数据分析和数据挖掘，帮助企业快速发现市场变化、调整业务策略、优化产品设计和提高客户满意度。
技术的进步和发展：随着大数据技术的不断进步和发展，分布式计算、流处理、数据缓存等技术的成熟为实时数仓的建设提供了技术基础。这些技术的应用使得大规模数据的实时处理成为可能，提高了数据处理的速度和效率。
竞争压力的增大：随着市场竞争的加剧，企业需要更加精准地了解市场和客户需求，快速响应变化和抓住商机。实时数仓能够帮助企业快速获取实时的市场和客户数据，提供精准的分析和决策支持，提高企业的竞争力和市场地位。

二、实时数仓和离线数仓对比

架构选择：离线数仓采用传统大数据框架模式搭建，而实时数仓则采用Kappa架构方式搭建。
建设方法：两者都采用传统数仓建模方法论。
准确性：离线数仓的准确性较高，而随着技术的发展，实时数仓的准确性也在逐步提高。
实时性：离线数仓统计数据结果通常在T+1，而实时数仓的统计结果通常在分钟级别或秒级别，这显示出实时数仓的实时性更强。
稳定性：离线数仓的稳定性好，方便重算，而实时数仓对数据波动较为敏感，数据重新计算时相对麻烦。
数据吞吐量：离线数仓的吞吐量都很高，而随着实时技术的进步，实时数仓的吞吐量也得到了提高。
数据存储：离线数仓一般将数据存储在HDFS、Hive中，而实时数仓则将数据存储在Kafka、Hbase、Redis、ClickHouse中。

三、应用场景

实时数据分析：实时数仓可以提供实时的数据分析和数据挖掘，包括客户行为分析、销售分析、运营分析等。这可以帮助企业快速了解市场和客户需求，发现商机，调整业务策略，优化产品设计和提高客户满意度。
实时风险控制：实时数仓可以用于实时监测和预警各种风险，如保险欺诈监测、信用风险预警等。这可以帮助企业及时发现和应对风险，保障业务的稳定运行。
实时决策支持：实时数仓可以提供实时的销售策略调整、产品开发优化、市场推广效果评估等支持，帮助企业快速响应市场变化和抓住商机。
实时客户体验优化：实时数仓可以用于实时监测和优化客户体验，如客户服务快速响应、个性化推荐与定制服务等。这可以帮助企业提高客户满意度和忠诚度，增加客户留存和转化。

四、实时数仓的架构设计

离线大数据架构：HDFS存储，hive、mr、spark进行离线计算；
Lambda架构：在离线大数据架构的基础上增加新链路用于实时数据处理，需要维护离线处理和实时处理两套代码；
Kappa架构：批流合一，离线处理和实时处理整合成一套代码，运维成本小，这就是现今flink之所以火的原因。Kappa架构已成为数据仓库架构的新趋势；
计算框架选型：flink等实时计算框架，强烈推荐flink，其『批量合一』的特性及活跃的开源社区，有逐渐替代spark的趋势；
数据存储选型：首要考虑查询效率，其次是插入、更新等问题，可选择apache druid，不过在数据更新上存在缺陷，选型时注意该问题频繁更新的数据建议不要采用该方案。当然存储这块需要具体问题具体分析，不同场景下hbase、redis等都是可选项；
实时数仓分层：为更好的统一管理数据，实时数仓可采用离线数仓的数据模型进行分层处理，可以分为实时明细层写入druid、Doris等查询效率高的存储方便下游使用；轻度汇总层对数据进行汇总分析后供下游使用。数据流转方案：实时数仓的数据来源可以为kafka消息队列，这样可以做到队列中的数据即可以写入数据湖用于批量分析，也可以实时处理，下游可以写入数据集市供业务使用。

实时数仓主要解决数据时效性问题，结合机器学习框架可以处理实时推荐、实时获取广告投放效果等智能化业务场景。实时数仓的建设应早日提上日程，未来企业对数据时效性的要求会越来越高，实时数仓会很好的解决该问题。

数据收集层：这一层负责实时数据，包括 Binlog、Service Log， Tracking Service Log，经过 Real-time Ingestion 团队数据将会被收集到 Kafka 、Hbase 中。Auto-Ingestion 团队负责数据库数离线日常收集到 HDFS。
存储层：这层主要是 Kafka 保存实时消息，加上 HDFS 保存 Hive 数据存储等，HBase 保存维度数据。
在存储层上面是 Spark， Flink 计算引擎, Presto SQL 查询引擎。
调度管理层：各种资源管理，任务管理，任务调度，管理各种 Spark，Flink 任务。
OLAP数据存储层：Druid 用于存储时间序列数据，Phoenix(HBase)存储聚合报表数据、维度表数据、标签数据，Doris；Elastic Search 存储需要多维度字段索引的数据如广告数据、用户画像等。
应用层：数据报表，数据业务服务，用户画像等。

五、实时数仓各层级的技术选型

数据源：直接配置为kafka实时消息传输；
数据明细层：一般也会选择kafka作为数据存储，如果是这层做成大宽表的话，可以选择druid/Doris/hbase/
数据汇总层：对数据进行高度汇总后的数据，这层一般也会选择kafka作为数据存储，这样需要保证各层级的数据通过kafka能够产生依赖。
应用层：应用层根据不同的业务类型选用不同的数据存储，如果结果需要能够快速搜索，可以选用es，如果结果需要进行多维数据统计分析，可以选用druid，Doris;如果结果数据量不是很大的话，最好选用mysql，相对来说，mysql的稳定性要好一点。
维度存储：维度如果是稳定并且数据量不大的情况下可以选择mysql，但是如果维度经常变动或者字段经常增加的话，最好选用hbase进行存储redis。

六、实时数仓架构实践演变

1、实时数仓1.0版本

1.0 版本的实时数仓主要是对流量数据做实时 ETL，并不计算实时指标，也未建立起实时数仓体系，实时场景比较单一，对实时数据流的处理主要是为了提升数据平台的服务能力。实时数据的处理向上依赖数据的收集，向下关系到数据的查询和可视化，下图是实时数仓 1.0 版本的整体数据架构图。

第一部分是数据采集，由三端 SDK 采集数据并通过 Log Collector Server 发送到 Kafka。（客户端埋点流程、模型和平台技术）；
第二部分是数据 ETL，主要完成对原始数据的清洗和加工并分实时和离线导入 Druid(Druid 数据库)；
第三部分是数据可视化，由 Druid 负责计算指标并通过 Web Server 配合前端完成数据可视化；
Lambda 架构有高容错、低延时和可扩展的特点，为了实现这一设计，我们将 ETL 工作分为两部分：Streaming ETL 和 Batch ETL。

Streaming ETL

这一部分我会介绍实时计算框架的选择、数据正确性的保证、以及 Streaming 中一些通用的 ETL 逻辑，最后还会介绍 Spark Streaming 在实时 ETL 中的稳定性实践。

计算框架选择

在 2016 年年初，业界用的比较多的实时计算框架有 Storm 和 Spark Streaming。Storm 是纯流式框架，Spark Streaming 用 Micro Batch 模拟流式计算，前者比后者更实时，后者比前者吞吐量大且生态系统更完善，考虑到知乎的日志量以及初期对实时性的要求，我们选择了 Spark Streaming 作为实时数据的处理框架。

数据正确性保证

Spark Streaming 的端到端 Exactly-once 需要下游支持幂等、上游支持流量重放，这里我们在 Spark Streaming 这一层做到了 At-least-once，正常情况下数据不重不少，但在程序重启时可能会重发部分数据，为了实现全局的 Exactly-once，我们在下游做了去重逻辑，关于如何去重后面我会讲到。

通用 ETL 逻辑

ETL 逻辑和埋点的数据结构息息相关，我们所有的埋点共用同一套 Proto Buffer Schema，大致如下所示：

message LogEntry {
  optional BaseInfo base = 1;
  optional DetailInfo detail = 2;
  optional ExtraInfo extra = 3;
}

BaseInfo： 日志中最基本的信息，包括用户信息、客户端信息、时间信息、网络信息等日志发送时的必要信息。
DetailInfo： 日志中的视图信息，包括当前视图、上一个视图等用于定位用户所在位置的信息。
ExtraInfo ：日志中与特定业务相关的额外信息。

针对上述三种信息我们将 ETL 逻辑分为通用和非通用两类，通用逻辑和各个业务相关，主要应用于 Base 和 Detail 信息，非通用逻辑则是由需求方针对某次需求提出，主要应用于 Extra 信息。

主要的通用逻辑：动态配置 Streaming、UTM 参数解析、新老用户识别。

2、实时数仓1.0的不足之处

所有的流量数据存放在同一个 Kafka Topic 中，如果下游每个业务线都要消费，这会导致全量数据被消费多次，Kafka 出流量太高无法满足该需求。
所有的指标计算全部由 Druid 承担，Druid 同时兼顾实时数据源和离线数据源的查询，随着数据量的暴涨 Druid 稳定性急剧下降，这导致各个业务的核心报表不能稳定产出。
由于每个业务使用同一个流量数据源配置报表，导致查询效率低下，同时无法对业务做数据隔离和成本计算。

3、实时数仓2.0版本

随着数据量的暴涨，Druid 中的流量数据源经常查询超时同时各业务消费实时数据的需求也开始增多，如果继续沿用实时数仓 1.0 架构，需要付出大量的额外成本。于是，在实时数仓 1.0 的基础上，我们建立起了实时数仓 2.0，梳理出了新的架构设计并开始着手建立实时数仓体系，新的架构如下图所示。

原始层

实时数仓 1.0 我们只对流量数据做 ETL 处理，在 2.0 版本中我们加入了对业务库的变更日志 Binlog 的处理，Binlog 日志在原始层为库级别或者 Mysql 实例级别，即：一个库或者实例的变更日志存放在同一个 Kafka Topic 中。同时随着公司业务的发展不断有新 App 产生，在原始层不仅采集日志，像知乎极速版以及内部孵化项目的埋点数据也需要采集，不同 App 的埋点数据仍然使用同一套 PB Schema。

明细层

明细层是我们的 ETL 层，这一层数据是由原始层经过 Streaming ETL 后得到。其中对 Binlog 日志的处理主要是完成库或者实例日志到表日志的拆分，对流量日志主要是做一些通用 ETL 处理，由于我们使用的是同一套 PB 结构，对不同 App 数据处理的逻辑代码可以完全复用，这大大降低了我们的开发成本。

汇总层之明细汇总

明细汇总层是由明细层通过 ETL 得到，主要以宽表形式存在。业务明细汇总是由业务事实明细表和维度表 Join 得到，流量明细汇总是由流量日志按业务线拆分和流量维度 Join 得到。流量按业务拆分后可以满足各业务实时消费的需求，我们在流量拆分这一块做到了自动化，下图演示了流量数据自动切分的过程。

Streaming Proxy 是流量分发模块，它消费上游 ETL 后的全量数据并定期读取埋点元信息，通过将流量数据与元信息数据进行「Join」完成按业务进行流量拆分的逻辑，同时也会对切分后的流量按业务做 ETL 处理。只要埋点元信息中新增一个埋点，那么这个埋点对应的数据就会自动切分到该业务的 Kafka 中，最终业务 Kafka 中的数据是独属于当前业务的且已经被通用 ETL 和业务 ETL 处理过，这大大降低了各个业务使用数据的成本。

汇总层之指标汇总

指标汇总层是由明细层或者明细汇总层通过聚合计算得到，这一层产出了绝大部分的实时数仓指标，这也是与实时数仓 1.0 最大的区别。知乎是一个生产内容的平台，对业务指标的汇总我们可以从内容角度和用户角度进行汇总
从内容角度我们可以实时统计内容（内容可以是答案、问题、文章、视频、想法）的被点赞数、被关注数、被收藏数等指标，从用户角度我可以实时统计用户的粉丝数、回答数、提问数等指标。
对流量指标的汇总我们分为各业务指标汇总和全局指标汇总。对各业务指标汇总，我们可以实时统计首页、搜索、视频、想法等业务的卡片曝光数、卡片点击数、CTR 等，对全局指标汇总我们主要以实时会话为主，实时统计一个会话内的 PV 数、卡片曝光数、点击数、浏览深度、会话时长等指标。

指标汇总层的存储选型

不同于明细层和明细汇总层，指标汇总层需要将实时计算好的指标存储起来以供应用层使用。
我们根据不同的场景选用了 HBase 和 Redis 作为实时指标的存储引擎。

Redis 的场景主要是满足带 Update 操作且 OPS 较高的需求，例如：实时统计全站所有内容（问题、答案、文章等）的累计 PV 数，由于浏览内容产生大量的 PV 日志，可能高达几万或者几十万每秒，需要对每一条内容的 PV 进行实时累加，这种场景下选用 Redis 更为合适。

HBase的场景主要是满足高频 Append 操作、低频随机读取且指标列较多的需求，例如：每分钟统计一次所有内容的被点赞数、被关注数、被收藏数等指标，将每分钟聚合后的结果行 Append 到 HBase 并不会带来性能和存储量的问题，但这种情况下 Redis 在存储量上可能会出现瓶颈。

应用层

应用层主要是使用汇总层数据以满足业务需求。

应用层主要分三块：

通过直接读取指标汇总数据做实时可视化，满足固化的实时报表需求，这部分由实时大盘服务承担；
推荐算法等业务直接消费明细汇总数据做实时推荐；
通过 Tranquility 程序实时摄入明细汇总数据到 Druid，满足实时多维即席分析需求。

4、实时数仓2.0中的技术实现

相比实时数仓 1.0 以 Spark Streaming 作为主要实现技术，在实时数仓 2.0 中，我们将 Flink 作为指标汇总层的主要计算框架。Flink 相比 Spark Streaming 有更明显的优势。

主要体现在：低延迟、Exactly-once 语义支持、Streaming SQL 支持、状态管理、丰富的时间类型和窗口计算、CEP 支持等。
我们在实时数仓 2.0 中主要以 Flink 的 Streaming SQL 作为实现方案。使用 Streaming SQL 有以下优点：

易于平台化、开发效率高、维度成本低等。目前 Streaming SQL 使用起来也有一些缺陷;
语法和 Hive SQL 有一定区别，初使用时需要适应；UDF 不如 Hive 丰富，写 UDF 的频率高于 Hive。

七、实施数仓未来展望

从实时数仓 1.0 到 2.0，不管是数据架构还是技术方案，我们在深度和广度上都有了更多的积累。随着公司业务的快速发展以及新技术的诞生，实时数仓也会不断的迭代优化。短期可预见的我们会从以下方面进一步提升实时数仓的服务能力：

Streaming SQL 平台化。目前 Streaming SQL 任务是以代码开发 maven 打包的方式提交任务，开发成本高，后期随着 Streaming SQL 平台的上线，实时数仓的开发方式也会由 Jar 包转变为 SQL 文件。
实时数据元信息管理系统化。对数仓元信息的管理可以大幅度降低使用数据的成本，离线数仓的元信息管理已经基本完善，实时数仓的元信息管理才刚刚开始。
实时数仓结果验收自动化。对实时结果的验收只能借助与离线数据指标对比的方式，以 Hive 和 Kafka 数据源为例，分别执行 Hive SQL 和 Flink SQL，统计结果并对比是否一致实现实时结果验收的自动化。

参考原文链接：
https://blog.csdn.net/qq_22473611/article/details/107514897

免责声明：本文素材和观点均基于当前可获得的资料和作者的个人理解进行撰写，本文章及其中所涉及的内容仅供读者朋友参考和交流之用，并不构成任何专业建议、投资意见或法律指导，如有任何问题或意见，请及时联系我们，收到您的反馈后我们将及时答复和处理~