简介：在营销场景下，算法同学会对广告主提供个性化的营销工具，帮忙广告主更好的精细化营销，在可控老本内实现更好的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个商品idinsert into table ${output_table_name}select nickname,        concat_id(true, item_id, behavior_time, 50) as rt_click_item_seqfrom ${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_listfrom ${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 clickfrom ${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工作，并且提供调度脚本，最初将我的项目进行封装提交给算法团队进行应用。将来咱们心愿用户可能在极光平台自助开发批量计算业务，升高算法同学开发成本，提供一个可扩大、低成本的批计算引擎能力，反对业务疾速迭代，赋能业务落地疾速拿到后果。

原文链接
本文为阿里云原创内容，未经容许不得转载。