核心内容摘要
汇川Codesys轴控制框架升级手记
Doris在广告技术中的应用实时竞价分析系统关键词Doris数据库、实时竞价RTB、广告技术、实时分析、高并发查询摘要在广告技术领域实时竞价RTB系统需要在毫秒级内完成用户画像匹配、竞价策略计算和效果分析。
本文将深入探讨Apache Doris如何凭借其“实时写入高效查询”的特性成为广告实时竞价分析的核心引擎。
我们将从RTB业务场景出发结合Doris的技术原理、实际案例和优化技巧为你揭开“广告系统如何在眨眼间完成万亿数据决策”的神秘面纱。
背景介绍目的和范围广告行业的“实时性”竞争已进入“毫秒级”时代当用户打开APP的瞬间广告系统需要在100ms内完成“用户标签匹配→广告候选池筛选→竞价计算→效果预估→最终排序”全流程。
本文聚焦“实时竞价分析”这一关键环节重点讲解Doris数据库如何解决广告主/平台在RTB场景中的三大核心需求高并发实时数据写入如每秒百万级广告请求日志复杂多维聚合查询如按“用户地域广告位时段”统计点击率毫秒级响应的在线分析如实时调整竞价策略预期读者广告技术AdTech领域的后端开发/数据工程师对实时数据库感兴趣的技术爱好者希望优化广告投放效果的运营/产品经理文档结构概述本文将按照“场景需求→技术原理→实战案例→未来趋势”的逻辑展开首先用“双11大促”的广告投放场景引出RTB分析需求然后拆解Doris的核心技术如MPP架构、列式存储、预聚合如何匹配这些需求接着通过真实代码案例演示Doris在广告效果分析中的落地最后探讨Doris与AI、数据湖结合的未来方向。
术语表核心术语定义RTBReal-Time Bidding实时竞价广告交易的“拍卖场”用户每一次页面刷新都会触发一次实时拍卖广告主通过竞价获得曝光机会。
DorisApache顶级项目一款面向实时分析的MPP大规模并行处理数据库支持高并发写入和低延迟复杂查询。
CTRClick-Through Rate点击率广告曝光后被点击的比例点击数/曝光数是衡量广告效果的核心指标。
CPCCost Per Click单次点击成本广告主为每次点击支付的费用直接影响投放ROI投资回报率。
缩略词列表MPPMassively Parallel Processing大规模并行处理OLAPOnline Analytical Processing在线分析处理Kafka一种高吞吐量的分布式消息队列常用于实时数据传输。
核心概念与联系故事引入双11的“广告大战”想象一下双11当晚20:00用户小明打开某电商APP首页弹出一个“运动鞋”广告——这个广告的展示背后藏着一场“看不见的战争”用户行为触发小明打开APP的瞬间APP向广告平台发送请求包含小明的设备ID、地理位置、历史浏览记录等50维度数据。
广告候选池筛选广告平台需要从1000万广告库中快速筛选出符合小明兴趣如“运动鞋”、广告主预算充足、且未重复曝光的候选广告最终选出100条。
实时竞价与排序对100条候选广告广告平台需要计算每条的“预估CTR”和“竞价价格”最终选择“ECPM千次曝光收益预估CTR×竞价×1000”最高的广告展示。
效果数据回流广告展示后曝光若小明点击点击数据会实时回传到分析系统用于优化后续的竞价策略比如“某地域用户对A品牌运动鞋点击率高可提高该品牌竞价”。
整个过程必须在100ms内完成否则用户会因页面加载慢而流失。
而支撑这一切的“大脑”正是实时竞价分析系统——它需要同时处理“百万级/秒的广告请求数据写入”和“毫秒级的多维聚合查询”Doris正是这个场景的“最佳拍档”。
核心概念解释像给小学生讲故事一样核心概念一实时竞价RTB的“三兄弟”RTB系统就像一个“快速拍卖市场”有三个关键角色广告请求Request用户打开页面时APP发出的“我需要广告”的信号类似“我要买水果”的顾客。
竞价响应Bid广告主收到请求后快速决定“我出多少钱买这个曝光”类似水果摊主喊价“苹果10元/斤”。
效果数据Impression/Click广告展示后曝光用户是否点击的结果数据类似“顾客买了苹果还是没买”。
这三个角色需要“手拉手”工作广告请求触发竞价竞价结果决定展示哪个广告效果数据则用来优化下次竞价——整个过程需要“实时数据实时分析”的闭环。
核心概念二Doris数据库的“超能力”Doris可以比作一个“超级高效的图书馆管理员”它有三个“超能力”快速收书实时写入不管每天有多少新书数据送来比如每秒100万条广告日志它都能快速整理上架写入存储不排队、不堵车。
快速找书高效查询当你需要查“
岁女性用户昨晚8点在上海看到的运动鞋广告点击量”时它能像扫描所有书架一样并行查找几毫秒就给出结果。
自动整理书预聚合它会提前把常用的“书组合”比如“按地域年龄分组的点击量”整理好下次再查同样的组合时直接拿整理好的结果不用重新翻所有书。
核心概念三RTB分析的“三大刚需”RTB分析就像“给广告效果做体检”需要满足三个“急需求”快广告主需要“现在”就知道“刚投放的广告效果如何”不能等第二天类似“刚考完试就想知道分数”。
准分析结果必须准确比如“某地区点击率3%”不能算成“5%”否则竞价策略会乱类似“买菜称重量不能出错”。
全需要同时看多个维度地域、年龄、广告位、时段的效果不能只看一个维度类似“不能只看数学成绩还要看语文、英语”。
核心概念之间的关系用小学生能理解的比喻RTB的“三兄弟”请求、竞价、效果就像“快递的运输链”请求是“下单”竞价是“运输”效果是“签收”。
而Doris就像“快递中转站”它需要快速接收“下单数据”实时写入→ 对应Doris的实时写入能力。
快速查“某个区域、某类商品的运输情况”多维查询→ 对应Doris的高效查询能力。
提前整理“常查的运输数据”预聚合→ 对应Doris的预聚合优化。
简单说RTB需要“快准全”的分析Doris正好有“快收书、快找书、自动整理书”的超能力两者是“天生一对”。
核心概念原理和架构的文本示意图RTB分析系统架构 用户行为 → 广告请求Kafka→ Doris实时写入→ 竞价策略计算实时查询→ 广告展示 → 效果数据Kafka→ Doris实时写入→ 效果分析离线/实时查询→ 优化竞价策略Mermaid 流程图是否用户打开APP发送广告请求广告平台接收请求从Doris查询用户标签/广告历史效果计算候选广告ECPM选择最高ECPM广告展示广告记录曝光数据到Doris用户是否点击?记录点击数据到Doris仅记录曝光数据Doris分析点击原因如地域/时段/广告创意优化竞价策略下次竞价时使用核心算法原理 具体操作步骤Doris能支撑RTB分析的关键在于其“MPP架构列式存储预聚合”三大核心技术。
我们逐一拆解
MPP架构像“多个人一起搬砖”的并行处理MPP大规模并行处理是Doris的“体力担当”。
当需要处理一个复杂查询比如统计全国31个省份的广告点击率Doris会把查询拆成31个小任务分别交给31台服务器同时计算就像31个人同时搬砖最后把结果汇总。
这种“分而治之”的方式让Doris在处理海量数据时依然快速。
类比生活你要数清楚一整个操场的人数一个人数太慢Doris会把操场分成31个区域每个区域派一个人统计最后把31个数字相加——速度快了31倍
列式存储像“按科目整理试卷”的高效存储传统数据库是“行式存储”按一行一行存储数据而Doris用“列式存储”按一列一列存储。
例如广告日志的“地域”“广告ID”“是否点击”三列列式存储会把所有“地域”值放一起所有“广告ID”放一起所有“是否点击”放一起。
为什么更高效RTB分析常用“按地域统计点击数”列式存储只需要读取“地域”和“是否点击”两列数据其他列如“设备ID”用不到而行式存储需要读取整行数据包括用不到的列。
列式存储的“按需读取”大大减少了数据传输量查询更快。
类比生活你有一摞考试卷行式存储是“张三的语文、数学、英语卷”“李四的语文、数学、英语卷”……列式存储是“所有学生的语文卷”“所有学生的数学卷”“所有学生的英语卷”。
当你需要统计全班数学平均分列式存储只需要拿“数学卷”那一摞行式存储需要翻每一份试卷的数学成绩——显然列式更快
预聚合像“提前算好错题本”的智能优化Doris的“预聚合”功能会自动将常用的聚合结果如“地域广告ID的点击数”提前计算并存储。
当用户再次查询同样的聚合条件时直接读取预聚合的结果无需重新扫描全量数据。
具体实现通过创建“物化视图”Materialized ViewDoris会在数据写入时同时更新预聚合的结果。
例如创建一个按“地域广告ID”聚合的物化视图每次写入新的广告日志时Doris会自动更新该视图中的“点击数”和“曝光数”。
类比生活你每天需要统计“苹果和香蕉的销量”预聚合就像提前准备一个“苹果香蕉销量表”每次卖出苹果或香蕉时直接在表上加减数字。
下次老板问“苹果卖了多少”直接看表就行不用翻所有销售小票重新计算。
数学模型和公式 详细讲解 举例说明在RTB分析中核心是计算ECPM千次曝光收益它决定了广告的排序和展示优先级。
ECPM的计算公式为E C P M 预估 C T R × 竞价价格 × 1000 ECPM 预估CTR \times 竞价价格 \times 1000ECPM预估CTR×竞价价格×1000其中预估CTRClick-Through Rate广告被点击的概率通过历史数据如“同用户标签同广告创意的点击率”实时计算。
竞价价格广告主为每次点击愿意支付的费用CPC。
举例说明假设广告A的预估CTR是2%
02竞价价格是5元CPC5则E C P M A
02 × 5 × 1000 100 元 ECPM_A
02 \times 5 \times 1000 100元ECPMA
02×5×1000100元广告B的预估CTR是
5%
015竞价价格是6元则E C P M B
015 × 6 × 1000 90 元 ECPM_B
015 \times 6 \times 1000 90元ECPMB
015×6×100090元此时广告A的ECPM更高会被优先展示。
Doris如何支撑ECPM计算Doris需要实时提供“预估CTR”的计算依据即预估 C T R 近期同维度用户地域 年龄 广告 I D 的点击数 近期同维度的曝光数 预估CTR \frac{近期同维度用户地域年龄广告ID的点击数}{近期同维度的曝光数}预估CTR近期同维度的曝光数近期同维度用户地域年龄广告ID的点击数例如要计算“
岁、上海用户、广告ID123”的预估CTRDoris需要快速查询C T R 点击数地域 上海 , 年龄 25 − 30 , 广告 I D 123 曝光数地域 上海 , 年龄 25 − 30 , 广告 I D 123 CTR \frac{点击数地域上海, 年龄
, 广告ID123}{曝光数地域上海, 年龄
, 广告ID123}CTR曝光数地域上海,年龄25−30,广告ID123点击数地域上海,年龄25−30,广告ID123通过Doris的列式存储和预聚合这个查询可以在毫秒级完成——因为“点击数”和“曝光数”已经按“地域年龄广告ID”预聚合存储无需扫描全量数据。
项目实战代码实际案例和详细解释说明开发环境搭建我们以“广告效果实时分析”为例演示Doris的部署和使用。
假设环境如下操作系统CentOS 7Doris版本
1.
5最新稳定版数据来源Kafka实时接收广告曝光/点击日志工具DBeaver数据库管理工具步骤1部署Doris集群参考官方文档部署3节点Doris集群1 FE节点2 BE节点确保集群状态健康通过SHOW PROC /cluster;查看。
步骤2创建Kafka主题创建两个Kafka主题ad_impression曝光日志和ad_click点击日志用于接收实时数据。
源代码详细实现和代码解读
设计Doris表结构广告曝光表广告曝光日志包含以下字段简化版log_time日志时间精确到秒user_id用户IDregion用户地域如“上海”“北京”age_group用户年龄分组如“
”“
”ad_id广告IDis_impression是否曝光固定为1标识曝光事件Doris表采用列式存储预聚合设计建表语句如下CREATETABLEIFNOTEXISTSad_impression(log_timeDATETIMENOTNULLCOMMENT日志时间,regionVARCHAR(
NOTNULLCOMMENT用户地域,age_groupVARCHAR(
NOTNULLCOMMENT年龄分组,ad_idINTNOTNULLCOMMENT广告ID,impression_countBIGINTSUMDEFAULT0COMMENT曝光数预聚合)ENGINEOLAP AGGREGATEKEY(log_time,region,age_group,ad_id)PARTITIONBYRANGE(log_time)(PARTITIONp202401VALUESLESS THAN(
-
,PARTITIONp202402VALUESLESS THAN(
-
)DISTRIBUTEDBYHASH(ad_id)BUCKETS16PROPERTIES(replication_num3,storage_formatV
;关键参数解释AGGREGATE KEY定义预聚合的维度时间、地域、年龄、广告IDDoris会按这些维度自动聚合impression_count曝光数。
PARTITION BY RANGE按时间分区每月一个分区便于历史数据管理和查询加速。
DISTRIBUTED BY HASH按广告ID哈希分桶16个桶确保数据均匀分布在BE节点避免热点。
设计广告点击表类似曝光表点击表结构与曝光表类似增加click_count字段CREATETABLEIFNOTEXISTSad_click(log_timeDATETIMENOTNULLCOMMENT日志时间,regionVARCHAR(
NOTNULLCOMMENT用户地域,age_groupVARCHAR(
NOTNULLCOMMENT年龄分组,ad_idINTNOTNULLCOMMENT广告ID,click_countBIGINTSUMDEFAULT0COMMENT点击数预聚合)ENGINEOLAP AGGREGATEKEY(log_time,region,age_group,ad_id)PARTITIONBYRANGE(log_time)(PARTITIONp202401VALUESLESS THAN(
-
,PARTITIONp202402VALUESLESS THAN(
-
)DISTRIBUTEDBYHASH(ad_id)BUCKETS16PROPERTIES(replication_num3,storage_formatV
;
实时数据写入通过KafkaDoris Stream Load使用Doris的Stream Load功能从Kafka实时拉取数据写入Doris。
以曝光数据为例提交Stream Load任务的curl命令curl--location-trusted -u user:passwd\-Hlabel:impression_load_202403\-HContent-Type: application/json\-Hformat: json\-Htimezone: Asia/Shanghai\-X PUT http://doris-fe:8030/api/test_db/ad_impression/_stream_load\-d -EOF { log_time:
20:00:00, region: 上海, age_group:
, ad_id: 123, impression_count: 1 } EOF关键参数解释label任务标识确保幂等性重复提交同一label的任务不会重复写入。
format: json指定输入数据格式为JSON。
timezone时区设置避免时间字段解析错误。
实时查询计算CTR现在需要查询“
20:00:00上海
岁用户广告ID123”的CTRSQL如下SELECTi.region,i.age_group,i.ad_id,i.impression_count,c.click_count,(c.click_count/i.impression_count)ASctrFROMad_impression iLEFTJOINad_click cONi.log_timec.log_timeANDi.regionc.regionANDi.age_groupc.age_groupANDi.ad_idc.ad_idWHEREi.log_time
20:00:00ANDi.region上海ANDi.age_group
ANDi.ad_id123;执行结果示例regionage_groupad_idimpression_countclick_countctr上海25-
3
02代码解读与分析预聚合的作用由于impression_count和click_count已经按“log_timeregionage_groupad_id”预聚合查询时无需扫描原始数据直接读取预聚合结果响应时间从秒级缩短到毫秒级。
JOIN优化Doris对同维度的表JOIN做了优化如相同的分区和分桶策略确保JOIN操作在本地节点完成减少网络传输。
实时性保障通过Stream Load数据从Kafka到Doris的写入延迟小于1秒保证了CTR计算的实时性。
实际应用场景Doris在广告RTB分析中的应用场景远不止CTR计算以下是几个典型案例
广告主实时监控投放效果某运动鞋广告主需要实时查看“当前投放的广告在各城市的点击率”以便调整竞价策略如“杭州点击率低降低竞价成都点击率高提高竞价”。
通过Doris的实时查询广告主可以在数据看板中看到秒级更新的地域CTR分布。
广告平台流量质量分析广告平台需要分析“哪些流量位如APP首页/详情页的广告转化率高”从而优先向优质流量位分配高价值广告。
Doris支持按“流量位广告主”维度的实时聚合查询帮助平台快速识别优质流量。
实时反作弊广告平台需要检测“同一设备在短时间内大量重复曝光”的异常行为可能是机器刷量。
Doris的高并发写入能力可以实时接收设备日志结合快速的“设备ID时间窗口”聚合查询如“某设备1分钟内曝光100次”及时标记异常设备。
工具和资源推荐
Doris官方工具Doris Manager集群管理工具支持一键部署、监控和故障排查。
Doris SQL CLI命令行客户端用于执行SQL查询和管理表。
Doris Loader离线数据导入工具如从Hive、MySQL导入历史数据。
生态集成工具Flink用于实时数据清洗如过滤无效广告请求清洗后通过Flink-Doris Connector写入Doris。
Superset数据可视化工具连接Doris后可快速制作广告效果看板。
Kibana结合Elasticsearch用于Doris集群的性能监控如QPS、延迟。
学习资源官方文档Apache Doris Documentation社区论坛Doris 社区技术博客关注“Doris开发者说”公众号获取最新技术
实践案例。
未来发展趋势与挑战趋势1实时数据湖与Doris的融合传统数据湖如Hudi、Iceberg擅长存储海量非结构化数据但实时查询能力较弱。
未来Doris可能与数据湖深度集成实现“湖内实时分析”——广告主可以直接分析湖中的原始日志无需先将数据导入Doris进一步降低数据处理链路的复杂度。
趋势2AI与RTB分析的深度结合Doris将支持更复杂的AI模型推理如用机器学习模型预测CTR通过“查询即推理”的方式在SQL中直接调用模型实现“实时数据→实时分析→实时决策”的闭环。
例如在计算ECPM时直接调用CTR预测模型而非依赖历史统计值。
挑战超大规模数据下的性能优化随着广告数据量的爆炸式增长如每天万亿条日志Doris需要解决“超大规模集群的一致性”和“极端并发下的查询延迟”问题。
未来可能通过“智能负载均衡”和“自适应查询优化”技术动态调整资源分配确保高并发下的稳定性能。
总结学到了什么核心概念回顾RTB实时竞价广告的“快速拍卖”需要毫秒级的数据分析支撑。
Doris的三大超能力实时写入快速收书、高效查询快速找书、预聚合自动整理书。
CTR与ECPM广告效果的核心指标Doris通过预聚合和MPP架构实现快速计算。
概念关系回顾RTB的“快准全”分析需求与Doris的“实时写入高效查询预聚合”特性完美匹配实时写入满足“快”数据及时入库。
高效查询满足“准”复杂多维分析不延迟。
预聚合满足“全”多维度组合分析秒级响应。
思考题动动小脑筋假设你是广告平台的数据工程师需要分析“不同手机品牌用户对游戏广告的点击率差异”你会如何设计Doris表的预聚合维度为什么如果广告日志中存在“延迟数据”如点击数据比曝光数据晚5分钟到达Doris的预聚合功能可能遇到什么问题如何解决除了CTR和ECPM你还能想到哪些广告效果指标需要实时分析Doris的哪些特性可以支撑这些指标的计算附录
常见问题与解答Q1Doris与Hive的区别是什么为什么RTB分析不用HiveAHive是离线分析引擎适合T1报表数据写入后需要经过MapReduce计算查询延迟高分钟级。
Doris是实时分析引擎支持实时写入和毫秒级查询更适合RTB的实时性需求。
Q2Doris如何保证数据可靠性ADoris通过多副本机制默认3副本保证数据可靠性。
当某台BE节点故障时系统会自动从其他副本恢复数据确保业务不中断。
Q3Doris的预聚合会增加存储成本吗A会但通过合理设计预聚合维度只聚合常用查询的维度可以平衡存储和性能。
例如若90%的查询是“地域广告ID”维度只需创建该维度的物化视图避免全量聚合。
扩展阅读 参考资料《Apache Doris实战》—— 林学森Doris核心开发者官方文档Doris Stream Load 指南技术博客Doris在字节跳动广告场景的实践(示例链接)