简介：在营销场景下，算法同学会对广告主提供个性化的营销工具，帮忙广告主更好的精细化营销，在可控老本内实现更好的 ROI 晋升。咱们在这一段时间反对了多个实时业务场景，比方出价策略的实时化预估、关键词批量服务同步、实时特色等场景，理解到业务侧同学来说，针对 ODPS 场景来说大部分能够灵便应用，但对于 Blink 应用还有有余，咱们这里针对场景积攒了一些教训，心愿对大家有一些帮忙。
作者 | 茂道
起源 | 阿里技术公众号
一 背景
在营销场景下，算法同学会对广告主提供个性化的营销工具，帮忙广告主更好的精细化营销，在可控老本内实现更好的 ROI 晋升。咱们在这一段时间反对了多个实时业务场景，比方出价策略的实时化预估、关键词批量服务同步、实时特色等场景，理解到业务侧同学来说，针对 ODPS 场景来说大部分能够灵便应用，但对于 Blink 应用还有有余，咱们这里针对场景积攒了一些教训，心愿对大家有一些帮忙。
二 技术选型
为什么要抉择 Blink？大部分离线场景如果对于时效性没有要求，或者数据源是 Batch 模式的，非 Streaming 的 (比方 TT、SLS、SWIFT、程序) 等，这个场景的话抉择 ODPS 就比拟不错；总体来说，数据源是实时的(如 TT/SLS/SWIFT)、须要程序读取 ODPS、对时效性要求高的场景，抉择 Blink 是比拟好的。
Blink 目前也是反对 Batch 模式和 Steaming 模式。Batch 模式是指有固定的起始工夫和完结工夫，相比 ODPS 而来，他最大的劣势是提前申请资源，可是独占的，这样能够保障时效性；Streaming 模式就是传统意义上的实时生产，可实现毫秒级的解决。
从开发模式上看，次要分为 Data Stream 模式，相似于 ODPS MR；第二种是 SQL 模式；从易用性角度看，SQL 无疑是应用老本最低的；但对于简单场景，Data Stream 的掌控能力也是最好的，可灵便定义各类 cache 和数据结构，以及同时反对多类场景。
三 次要场景
1 实时 replay 出价策略评估
业务背景
Replay 零碎是一套集线上竞价日志收集、结构化、后续解决的模拟系统。该零碎记录了直通车线上引擎在召回之后的竞价信息，次要涵盖了线上的召回、出价、打分等队列信息。联合排序以及扣费公式，能够利用该日志实现对线上竞价环境的模仿。简略来说，就是能够评估 bidword 上如果过后采纳其余的出价，会带来什么样的后果。通过 replay 零碎，算法团队和广告主能够在线上 AB 测试之前，利用离线流量预估用户策略批改之后带来的成果，这样能够尽可能地缩小策略的批改带给线上的影响，让后果变得更加可控。同时在进行负向策略测试的过程中，能够尽可能地缩小对大盘的收益影响。
算法团队心愿基于在线精排召回日志实现业务侧多种出价策略评估，回放 1 天内采样日志(10 亿数据)，在出价策略上评估，并反对 ad 的实时下线，防止下线 ad 对出价策略有影响，并且预期心愿 10 亿数据量在 1 - 2 个小时内跑完。
次要挑战
- 1 千万物料数据如何加载；
- 高 qps(100 万)下线 ad 的实时同步；
- 业务侧解耦，整个实时 job 链路如何实现和业务解耦
解决方案
- 物料数据加载：间接在 blink 启动时加载所有数据，防止高 qps 状况下，对 igraph 拜访造成压力；另外采纳播送模式，仅一次加载，每个节点都能够应用，防止屡次加载 odps 数据；
- 下线的 ad 信息采纳分桶的形式存入到 IGraph 中，并周期性 cache 形式全量读取全量下线 ad，将查问的 200W+qps 管制在 1w 左右，并应用 RateLimit 限流组件管制拜访并发，把 IGraph 并发管制限度在 40 万左右，实现整体流量平滑；
- 整体实时工程框架，预留 UDF 接口，让业务侧仅实现 SDK 即可，其余工程性能、并发、限流、埋点等逻辑外部实现即可，反对工程框架和算法策略 Replay 解耦。
总结
基于此业务需要，咱们基于 blink streaming Batch 模式的灵便能力，实现了对 tt 数据固定开始和完结工夫的数据处理。积淀了读写 tt 组件，ODPS 组件，iGraph 组件和埋点组件，这些积淀的组件很好地反对了后续类似业务的作业开发，同时组件作为之后作业产品化提供了根底能力。
2 实时特色
业务背景
随着 B 端算法倒退，模型降级带来的增量红利越来越少，须要思考从客户实时信息方面进一步捕获用户用意，更全面、更实时的开掘潜在需要，从 B 端视角进一步晋升增长空间，基于线上用户行为日志产出用户行为实时特色，算法团队应用实时数据改良线上模型。
基于此需要咱们产出一条用户实时特色产出链路，通过解析上游 A + 数据源获取用户实时特色，实时特色次要蕴含以下几种：
- 获取用户近 50 条特色数据值，并产出到 igraph 中。
- 输入具备某种特色的用户 id，并依照分钟工夫聚合
- 输入某种特色近 1 小时的和、均值或者数目
次要挑战
实时特色数据开发数量十分多，对于每个特色数据都须要开发实时数据链路、保护，开发成本、运维老本较高，反复造轮子；
特色数据开发要求开发者理解：
- 数据源头，会基于事实数据源进行 ETL 解决；
- 计算引擎，flink sql 保护了一套本人的计算语义，须要学习理解并依据场景纯熟应用；
- 存储引擎，实时数据开发好须要落地能力服务，故须要关系存储引擎选型，例如 igraph、hbase、hologres 等；
- 查问优化办法，不同存储引擎都有本人的查问客户端、应用及优化办法，故要学习不同引擎应用办法。
解决方案
从产品设计角度，设计一套实时平台能力，让开发实时特色跟在 odps 开发离线表一样简略。产品劣势是让用户只须要懂 SQL 就能够开发实时特色：
- 不须要理解实时数据源
- 不须要理解底层存储引擎
- 只用 sql 就能够查问实时特色数据，不须要学习不同引擎查询方法
整个实时开发产品联动极光平台、dolphin 引擎、blink 引擎和存储引擎，把整个流程串联买通，给用户提供端到端的开发体验，无需感知跟本人工作无关的技术细节。
相干平台介绍：
Dolphin 智能减速剖析引擎：Dolphin 智能减速剖析引擎源自阿里妈妈数据营销平台达摩盘 (DMP) 场景，在通用 OLAP MPP 计算框架的根底上，针对营销场景的典型计算（标签圈人，洞察剖析）等，进行了大量存储、索引和计算算子级别的性能优化，实现了在计算性能，存储老本，稳定性等各个方面的大幅度的晋升。Dolphin 自身定位是减速引擎，数据存储和计算算子依赖于底层的 odps, hologres 等引擎。通过插件模式，在 hologres 中，实现了算子集成和底层数据存储和索引的优化, 实现了特定计算场景计算性能和撑持业务规模的数量级的晋升。目前 Dolphin 的外围计算能力次要包含：基数计算内核，近似计算内核，向量计算内核，SQL 后果物化及跨 DB 拜访等。Dolphin 同时实现了一套 SQL 转译和优化能力，主动将原始用户输出 SQL，转化成底层优化的存储格局和计算算子。用户应用，不须要关怀底层数据存储和计算模式，只须要依照原始数据表拼写 SQL，极大的晋升了用户应用的便利性。
极光消费者经营平台：极光是面向营销减速场景的一站式研发平台，通过平台产品化的形式，能够让特色引擎能力更好赋能用户。极光反对的特色场景蕴含超大规模标签交并差(百亿级标签圈选毫秒级产出)、人群洞察(上千亿规模秒级查问)、秒级成果归因(事件剖析、归因剖析)、实时和百万级人群定向等能力。极光在营销数据引擎的根底上提供了一站式的运维管控、数据治理以及自助接入等能力，让用户应用更加便捷；极光积淀了搜推广罕用的数据引擎模板，蕴含基数计算模板、报表模板、归因模板、人群洞察模板、向量计算模板、近似计算模板、实时投放模板等，基于成熟的业务模板，让用户能够零老本、无代码的应用。
依据目前的业务需要，封装了实时数据源和存储数据源
应用举例：
--- 注册输出表
create table if not exists source_table_name(
user_id String comment '',
click String comment '',
item_id String comment '',
behavior_time String comment ''
) with (
bizType='tt',
topic='topic',
pk='user_id',
timeColumn='behavior_time'
);
---- 创立输出表
create table if not exists output_table_name (
user_id STRING
click STRING
) with (
bizType='feature',
pk='user_id'
);实现实时特色算子：
concat_id:
- 含意：从输出表输出的记录中，选取 1 个字段，依照 timestamps 倒序排成序列，能够配置参数依照 id 和 timestamp 去重，反对用户取 top k 个数据
应用举例：
-- 用户最近点击的 50 个商品 id
insert into table ${output_table_name}
select nickname,
concat_id(true, item_id, behavior_time, 50) as rt_click_item_seq
from ${source_table}
group by user_id;
-- 1 分钟内最近有特色行为用户 id 列表
insert into table ${output_table_name}
select window_start(behavior_time) as time_id,
concat_id(true, user_id) as user_id_list
from ${source_table}
group by window_time(behavior_time, '1 MINUTE');sum、avg、count：
- 含意：从输出表输出的记录中，选取 1 个字段，对指定的工夫范畴进行求和、求平均值或计数
应用举例
-- 每小时的点击数和曝光数
insert into table ${output_table_name}
select
user_id,
window_start(behavior_time) as time_id,
sum(pv) as pv,
sum(click) as click
from ${source_table}
group by user_id,window_time(behavior_time, '1 HOUR');总结
基于 B 端算法的实时特色需要，积淀了一套基于 blink sql + udf 实现的实时特色产出零碎，对用户输出的 sql 进行本义，在 Bayes 平台生成 bink SQL Streaming 工作，产出实时特色数据存入 iGraph 当中，积淀了 blink 写入 igraph 组件，concat_id 算子、聚合算子等根底能力，为后续 Dolphin streaming 实时特色产出零碎打下了根底，反对后续多种特色算子扩大形式，疾速反对此类用户需要。
3 关键词批量同步
业务背景
每天有很多商家通过不同渠道退出直通车；而在对新客承接方面存在比拟大的空间。另一方面，对于零碎的存量客户的低活局部也有较大的优化空间。零碎买词作为新客承接、低活促活的一个重要抓手，心愿通过对直通车新客和低活客户进行更高频率的关键词更新（天级 -> 小时级），帮忙指标客户的广告尝试更多关键词，存优汰劣，达到促活的指标。
基于此需要，咱们在现有天级别离线链路的根底上补充小时级的音讯更新链路，用来反对规范打算下各词包、以及智能打算的零碎词更新，每小时音讯更新量在千万量级，应用 Blink 将全量 ODPS 申请参数调用 faas 的函数服务，将每条申请的后果写入到 ODPS 的输出表中。更新频率在两个小时，更新工夫：早 8 点到晚 22 点，单次增删规模：增 500W/ 删 500W。
次要挑战
- blink 批处理作业须要进行小时级调度
- faas 函数调用须要限流
解决方案
- 应用 Blink UDF 实现对 request 申请调用 HSF 的函数服务性能
- blink UDF 应用 RateLimiter 进行限流，拜访函数服务的 QPS 能够严格被节点并行度进行管制
- 在 Dataworks 平台配置 shell 脚本，进行 Bayes 平台批计算任务调度
总结
基于此需要，应用 blink sql batch 模式实现了近实时的此类更新链路，买通了此类批处理作业的调度模式，为后续批作业产品化打下了根底。
四 将来瞻望
基于 B 端算法的业务，Dolphin 引擎目前曾经设计开发了 Dolphin streaming 链路，用户在极光平台开发实时特色变得跟在 odps 开发离线表一样简略，用户无需理解实时数据源、底层存储引擎，只须要用 sql 就能够查问实时特色数据。然而 B 端算法业务中还有相似于本文中提到的批处理业务，这些业务须要开发 blink batch sql、blink streaming batch 模式、ODPS UDF 和 java code 工作，并且提供调度脚本，最初将我的项目进行封装提交给算法团队进行应用。将来咱们心愿用户可能在极光平台自助开发批量计算业务，升高算法同学开发成本，提供一个可扩大、低成本的批计算引擎能力，反对业务疾速迭代，赋能业务落地疾速拿到后果。
原文链接
本文为阿里云原创内容，未经容许不得转载。