广告系统中后链路数据为什么要使用流批一体技术?流批一体技术是什么?

在大规模广告系统的后链路(离线和实时特征计算、模型训练与上线、效果监控等)中,往往既有对海量历史数据的批量计算需求(离线特征、离线模型训练、报表汇总),又有对在线请求的低延迟实时计算需求(实时特征、在线打分、实时监控/告警)。传统将二者割裂、用 Lambda 架构(Batch + Speed 层)分别实现,带来了:

• 代码与业务逻辑重复
• 数据语义/计算结果不一致
• 运维成本、调度复杂度翻倍
• 开发调试效率低

流批一体技术(Streaming + Batch Unified)正是在这个场景下应运而生,用以打通“离线 ↔ 实时”两条腿,统一底层引擎、统一 API、统一数据语义、统一运维调度,从而大幅降低系统复杂度并提升实时性与一致性。

以下从“概念”、“核心能力”、“关键技术点”以及“在广告后链路的价值”四个角度做详细介绍。

一、流批一体技术概念

  1. 统一计算引擎
    – 同一套计算框架即可处理有界(Batch)与无界(Stream)数据
    – 统一抽象:数据流(DataStream)、表/SQL(Table & SQL)等
  2. 统一编程模型
    – 同一份代码/同一套 API(如 Flink 的 DataStream & Table API、Spark Structured Streaming & Spark SQL、Beam)
    – 业务逻辑“一次编写、实时/离线皆可跑”
  3. 统一时间语义
    – 事件时间(Event Time)驱动,Watermark + Window 机制同时支持离线全局聚合和实时滑动/滚动窗口
  4. 统一容错与状态管理
<think>好的,我现在需要回答用户关于搭建实时数仓所需技术和架构的问题。首先,我得回忆一下实时数仓的基本概念,以及它与传统数仓的区别。实时数仓的核心在于实时数据处理和分析,所以需要支持低延迟的技术组件。 接下来,我应该考虑实时数仓的架构。常见的架构有Lambda和Kappa,但现在可能还有其他变种,比如实时数仓常用的分层结构,比如数据采集层、数据处理层、存储层、服务层等。需要把这些层次分清楚,并对应到具体的技术。 然后,技术选型是关键。数据采集方面,常用的有Kafka、Flume、Flink Connectors等。数据处理可能需要流处理框架,比如Flink、Spark Streaming,或者Kafka Streams。存储层的话,实时数仓可能需要OLAP数据库,比如ClickHouse、Doris,或者HBase、Hudi、Iceberg等。服务层可能涉及API网关、查询引擎如Presto或Druid。 另外,需要考虑数据建模,比如维度建模是否适用,或者是否需要其他模型来支持实时查询。数据治理方面,元数据管理、数据质量监控、血缘追踪等也是重要部分,可能需要工具如Apache Atlas。 还要提到架构设计的关键点,比如低延迟、高可用、可扩展性、一致性等。可能需要解释Lambda和Kappa架构的区别,以及为什么现在更多转向Kappa或者更简化的架构。 可能用户会关心具体的技术组合,比如Flink + Kafka + ClickHouse这样的组合是否可行,或者结合Hudi做湖仓一体。需要给出一个典型的技术栈例子,帮助用户理解。 同时,需要注意实时数仓的挑战,比如处理乱序数据、状态管理、Exactly-Once语义等,这些可能涉及技术组件的选择,比如Flink的优势在这里。 最后,确保回答结构清晰,分点列出技术和架构部分,可能用分层的方式解释,每层对应技术和作用。还要注意用户可能需要实际案例或应用场景,但用户没有具体问,所以点到为止即可。 总结步骤:先介绍实时数仓的概念,然后分架构和技术两部分详细说明,每部分再细分层次和对应的技术组件,最后总结关键点和可能的技术组合示例。</think>### 实时数仓技术架构详解 #### 一、核心架构分层 实时数仓通常采用 **分层架构** 以解耦处理流程,典型分层如下: 1. **数据采集层** - **作用**:实时采集多源数据(日志、数据库变更、IoT设备等)。 - **技术选型**: - **消息队列**:Apache Kafka(高吞吐、低延迟)、Pulsar(分层存储)。 - **日志采集**:Filebeat、Flume。 - **数据库同步**:Debezium(CDC工具)、Canal。 2. **数据处理层** - **核心能力**:流批一体处理、实时ETL、数据清洗。 - **技术选型**: - **流处理引擎**:Apache Flink(主导地位,支持精确一次语义、状态管理)。 - **轻量级处理**:Kafka Streams(适合简单ETL)。 - **混合处理**:Spark Structured Streaming(微批模式)。 3. **存储层** - **设计要点**:需同时支持 **高并发写入** 与 **低延迟查询**。 - **技术组合**: - **实时写入**:Apache Hudi/Iceberg(事务型数据湖)。 - **OLAP引擎**:ClickHouse(列式存储)、Doris(MPP架构)、StarRocks。 - **宽表服务**:HBase(随机读写)、Redis(热数据缓存)。 4. **服务层** - **关键功能**:提供统一查询接口、数据可视化、实时BI。 - **技术栈**: - **查询引擎**:Presto(联邦查询)、Doris SQL。 - **API服务**:GraphQL(灵活数据聚合)、RESTful API。 - **可视化**:Grafana(实时仪表盘)、Superset。 #### 二、典型架构模式 1. **Lambda架构**(逐渐被替代) - **组成**: - 批处理层(HDFS+Hive) - 速度层(Flink/Kafka) - 服务层(合并结果) - **痛点**:维护两套代码、数据一致性难保障 2. **Kappa架构** - **革新点**:仅保留流处理层,通过 **数据重放** 实现批处理需求 - **实现路径**: $$ \text{Kafka(持久化日志)} \xrightarrow{Flink} \text{OLAP存储} $$ - **优势**:架构简化,适合事件驱动型场景 3. **湖仓一体架构**(新兴趋势) - **核心思想**:将数据湖与数仓能力融合 - **技术栈**: $$ \text{Delta Lake/Hudi} \leftarrow \xrightarrow{Flink} \rightarrow \text{Doris/StarRocks} $$ - **特征**:支持ACID事务、Schema演进、版本回溯 #### 三、关键技术组件详解 1. **Apache Flink** - **核心优势**: - 精确一次语义(通过Checkpoint机制) - 事件时间处理(解决乱序问题) - 状态管理($State TTL$自动清理) - **典型应用**: ```sql CREATE TABLE user_clicks ( user_id STRING, click_time TIMESTAMP(3), WATERMARK FOR click_time AS click_time - INTERVAL '5' SECOND ) WITH (...); SELECT TUMBLE_START(click_time, INTERVAL '1' HOUR), COUNT(DISTINCT user_id) FROM user_clicks GROUP BY TUMBLE(click_time, INTERVAL '1' HOUR); ``` 2. **实时存储选型对比** | 存储系统 | 写入吞吐 | 查询延迟 | 数据更新能力 | 适用场景 | |------------|----------|----------|--------------------|------------------------| | ClickHouse | 高 | 亚秒级 | 仅追加 | 大宽表聚合查询 | | HBase | 极高 | 毫秒级 | 支持随机更新 | 点查、时序数据 | | Doris | 中高 | 秒级 | 支持批量更新 | Ad-hoc查询 | | Hudi | 中 | 分钟级 | 支持增量更新 | 近实时数据湖 | 3. **数据质量保障** - **端到端延迟监控**:Prometheus + Grafana监控pipeline延迟 - **Exactly-Once实现**: $$ \text{Kafka(幂等生产)} + \text{Flink(两阶段提交)} $$ - **数据一致性校验**:通过DWD层的唯一键校验(如$HASH(user_id,event_time)$) #### 四、实施路线建议 1. **场景驱动设计** - 广告实时投放:要求百毫秒级响应 → 选择Flink + Redis - 实时风控:复杂规则计算 → Flink CEP + HBase - 运营大盘:分钟级延迟可接受 → Flink + Hudi + Presto 2. **迭代优化路径** ```mermaid graph TD A[Kafka做原始日志收集] --> B[Flink ETL清洗] B --> C[写入Hudi数据湖] C --> D[Doris构建聚合层] D --> E[BI工具可视化] ``` 3. **常见陷阱规避** - **热点问题**:采用$user_id\%100$分桶避免数据倾斜 - **小文件问题**:Hudi的Clustering优化 - **资源隔离**:Flink生产消费组独立部署 #### 五、前沿发展方向 1. **流批一体存储**:Apache Paimon(原Flink Table Store) 2. **智能实时数仓**:集成ML模型进行实时预测 3. **Serverless化**:基于Kubernetes的弹性扩缩容 **总结**:实时数仓建设需以业务场景为锚点,通过Flink+消息队列+OLAP存储构建核心链路,同时结合数据技术实现灵活性与效率的平衡。技术选型时需重点评估数据更新频率、查询复杂度、一致性要求等维度。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值