360 商品化为助推业务项目组更好推进商品化快速增长,动态数仓共经历了四种商业模式的重构,分别是 Storm + Druid + MySQL 商业模式、Flink + Druid + TIDB 的商业模式 和 Flink + Doris 的商业模式,基于 Apache Doris 的第三代构架的获得成功破冰使得 360 商品化项目组完成了动态数仓在 OLAP 发动机上的标准化,获得成功同时实现广泛动态情景下的以单查阅积极响应。责任编辑将为大家进行详细如是说重构过程和第三代动态数仓在在线视频情景中的具体破冰课堂教学。
作者|窦和雨、姚居德新,360商品化统计数据项目组
360 公司致力成为网络和安全可靠服务提供更多商,是网络完全免费安全可靠的提倡者,先后推出 360 安全可靠保卫者、360 手机保卫者、360 安全可靠应用程序等安全可靠商品和 360 导航系统、360 搜寻等使用者商品。
360 商品化借力 360 商品巨大的使用者全面覆盖能力和极强的使用者黏性,透过专业统计信息处理和演算法同时实现电视广告精准导入,助推数千小企业和 KA 企业同时实现价值快速增长。360 商品化统计数据项目组主要是对整个网络电视广告信道中所产生的统计数据展开计算处理,为商品营运项目组提供更多策略修正的分析统计数据,为演算法项目组提供更多数学模型体能训练的强化统计数据,为电视广告商提供更多网络电视广告的效果统计数据。
业务情景
在正式如是说 Apache Doris 在 360 商品化的应用领域之前,他们Fossat在线视频中的典型使用情景展开概要如是说:
动态上证指数:动态上证指数情景是他们对外呈现统计数据的关键媒介,需要从多个层次监视商品化上证指数的分项情形,包括网络流量分项、消费需求分项、转化分项和增值分项,因此其对统计数据的准确度明确要求非常高(保证统计数据不丢太重),同时对统计数据的及时性和灵活性明确要求也极高,明确要求同时实现以单延后、分钟级统计单元测试。
电视广告帐户的动态消费需求统计数据情景:透过监视帐户发射率下的多方位分项统计数据,及时处理帐户的消费需求变化,易于商品项目组根据动态消费需求情形推动营运项目组对帐户财政预算展开修正。在该情景下统计数据一旦出现问题,就可能导致帐户财政预算的错误修正,从而影响电视广告的导入,这对公司和电视广告商将造成不可估量的损失,因此在该情景中,同样对统计数据准确度有极高的明确要求。目前在该情景下遇到的困难是如何在统计数据量比较大、查阅交叉的发射率比较细的前提下,同时实现以单别查阅积极响应。
AB 实验平台:在在线视频中,演算法和策略同学会针对不同的情景展开实验,在该情景下,具有报表层次不固定、多种层次灵活组合、统计数据分析比较复杂、统计数据量较大等特点,这就需要可以在百万级 QPS 下保证统计数据写入存储发动机的性能,因此他们需要针对业务情景展开特定的数学模型设计和处理上的强化,提高动态统计信息处理的性能和统计数据查阅分析的效率,只有这样才能满足演算法和策略同学对实验报表的查阅分析需求。动态数仓重构
为提升各情景下统计数据服务的效率,助推相关业务项目组更好推进商品化快速增长,截至目前动态数仓共经历了四种商业模式的重构,分别是 Storm + Druid + MySQL 商业模式、Flink + Druid + TIDB 的商业模式 和 Flink + Doris 的商业模式,责任编辑将为大家展开详细如是说动态数仓重构过程和第三代动态数仓在在线视频情景中的具体破冰。第一代构架该阶段的动态数仓是基于 Storm + Druid + MySQL 来构建的,Storm 为动态处理发动机,统计数据经 Storm 处理后,将统计数据写入 Druid ,利用 Druid 的预聚合能力对写入统计数据展开聚合。
构架痛点:最初他们试图依靠该架构解决业务上所有的动态问题,经由 Druid 标准化对外提供更多统计数据查阅服务,但是在实际的破冰过程中他们发现 Druid 是无法满足某些分页查阅和 Join 情景的,为解决该问题,他们只能利用 MySQL 定时任务的方式将统计数据定时从 Druid 写入 MySQL 中(类似于将 MySQL 作为 Druid 的物化视图),再透过 Druid + MySQL 的商业模式对外提供更多服务。透过这种方式暂时可以满足某些情景需求,但随着业务规模的逐步扩大,当面对更大规模统计数据下的查阅分析需求时,该构架已难以为继,构架的缺陷也越发明显:面对统计数据量的持续快速增长,统计数据仓库压力空前剧增,已无法满足动态统计数据的及时性明确要求。MySQL 的分库分表维护难度高、投入成本大,且 MySQL 表之间的统计数据一致性无法保障。
第二代构架
基于第一套构架存在的问题,他们展开了首次升级,这次升级的主要变化是将 Storm 替换成新的动态统计信息处理发动机 Flink ,Flink 相较于 Storm 不仅在许多语义和功能上展开了扩展,还对统计数据的一致性做了保证,这些特性使得报表的及时性大幅提升;其次他们使用 TiDB 替换了 MySQL ,利用 TIDB 分布式的特性,一定程度上解决了 MySQL 分库分表难以维护的问题(TiDB 在一定程度上比 MySQL 能够承载更大统计数据量,可以拆分更少表)。在升级完成后,他们按照不同业务情景的需求,将 Flink 处理完的统计数据分别写入 Druid 和 TiDB ,由 Druid 和 TIDB 对外提供更多统计数据查阅服务。构架痛点:
虽然该阶段的动态数仓构架有效提升了统计数据的及时性、降低了 MySQL 分库分表维护的难度,但在一段时间的使用之后又暴露出了新的问题,也迫使他们展开了第二次升级:Flink + TIDB 无法同时实现端到端的一致性,原因是当其面对大规模的统计数据时,开启事务将对 TiDB 写入性能造成很大的影响,该情景下 TiDB 的事务形同虚设,心有余而力不足。Druid 不支持标准 SQL ,使用有一定的门槛,相关项目组使用统计数据时十分不便,这也直接导致了工作效率的下降。维护成本较高,需要维护两套发动机和两套查阅逻辑,极大增加了维护和开发成本的投入。
第三代动态数仓构架第二次升级他们引入 Apache Doris 结合 Flink 构建了第三代动态数仓构架,借鉴离线数仓分层理念对动态数仓展开分层构建,并标准化 Apache Doris 作为数仓 OLAP 发动机,由 Doris 标准化对外提供更多服务。 他们的统计数据主要源自于维表物料统计数据和业务打点日志。维表物料统计数据会定时全量同步到 Redis 或者 Aerospike (类似于 Redis 的 KV 存储)中,透过 Binlog 变更展开增量同步。业务统计数据由各个项目组将日志收集到 Kafka,内部称为 ODS 原始统计数据(ODS 原始统计数据不做任何处理),他们对 ODS 层的统计数据展开归一化处理,包括字段命名、字段类型等,并对一些无效字段展开删减,并根据业务情景拆分生成 DWD 层统计数据,DWD 层的统计数据透过业务逻辑加工和关联 Redis 中维表统计数据或者多流 Join,最后生成面向具体业务的大宽表(即 DWT 层统计数据),他们将 DWT 层统计数据经过聚合、经由 Stream Load 写入 Doris 中,由 Doris 对外提供更多统计数据查阅服务。在离线数仓部分,同样也有一些情景需要每日将加工完的 DWS 统计数据经由 Broker Load 写入到 Doris 集群中,并利用 Doris 展开查阅加速,以提升他们对外提供更多服务的效率。选择 Doris 的原因基于 Apache Doris 高性能、极简易用、动态标准化等诸多特性,助推 360 商品化获得成功构建了第三代动态数仓构架,本次升级不仅提升了动态统计数据的复用性、同时实现了 OLAP 发动机的标准化,而且满足了各大业务情景严苛的统计数据查阅分析需求,使得整体动态统计数据流程构架变得简单,大大降低了其维护和使用的成本。他们选择 Doris 作为标准化 OLAP 发动机的重要原因大致可归结为以下几点:物化视图:Doris 的物化视图与电视广告业务情景的特点契合度非常高,比如在线视频中大部分报表的查阅层次相对比较固定,利用物化视图的特性可以提升查阅的效率,同时 Doris 可以保证物化视图和底层统计数据的一致性,该特性可帮助他们降低维护成本的投入。
统计数据一致性:Doris 提供更多了 Stream Load Label 机制,他们可透过事务的方式与 Flink 二阶段提交展开结合,以保证幂等写入统计数据,另外他们透过自研 Flink Sink Doris 组件,同时实现了统计数据的端到端的一致性,保证了统计数据的准确度。
SQL 协议兼容:Doris 兼容 MySQL 协议,支持标准 SQL,这无论是对于开发同学,还是统计数据分析、商品同学,都可以同时实现无成本衔接,相关同学直接使用 SQL 就可以展开查阅,使用门槛很低,为公司节省了大量培训和使用成本,同时也提升了工作效率。
优秀的查阅性能:Apache Doris 已全面同时实现向量化查阅发动机,使 Doris 的 OLAP 性能表现更加强悍,在多种查阅情景下都有非常明显的性能提升,可极大强化了报表的询速度。同时借力列式存储发动机、现代的 MPP 构架、预聚合物化视图、统计数据索引的同时实现,在低延后和高吞吐查阅上,都达到了极速性能
运维难度低:Doris 对于集群和和统计数据副本管理上做了很多自动化工作,这些投入使得集群运维起来非常的简单,近乎于同时实现零门槛运维。具体应用领域Apache Doris 目前广泛应用领域于 360 商品化内部的多个业务情景。比如在动态上证指数情景中,他们利用 Doris 的 Aggregate 数学模型对请求、曝光、点击、转化等多个动态流展开事实表的 Join ;依靠 Doris 事务特性保证统计数据的一致性;通过多个物化视图,提前根据报表层次聚合统计数据、提升查阅速度,由于物化视图和 Base 表的一致关系由 Doris 来维护保证,这也极大的降低了使用复杂度。比如在帐户动态消费需求情景中,他们主要借助 Doris 优秀的查阅强化器,透过 Join 来计算同环比……
接下来仅以 AB 实验平台这一典型业务情景为例,详尽的为大家如是说 Doris 在该情景下的破冰课堂教学,在上述所举情景中的应用领域将不再赘述。AB 实验在电视广告情景中的应用领域非常广泛,是衡量设计、演算法、数学模型、策略对商品分项提升的重要工具,也是精细化营运的重要手段,他们可以透过 AB 实验平台对迭代方案展开测试,并结合统计数据展开分析和验证,从而强化商品方案、提升电视广告效果。在文章开头也有简单如是说,AB 实验情景所承载的业务相对比较复杂,这里再详细说明一下:各层次之间组合灵活度极高,例如需要对从 DSP 到网络流量类型再到电视广告位置等十几个层次展开分析,完成从请求、竞价、曝光、点击、转化等几十个分项的完整网络流量漏斗。统计数据量巨大,日均网络流量可以达到百亿元级别,峰值可达百万 OPS(Operations Per Second),一条网络流量可能包含几十个实验标签 ID。基于以上特点,他们在 AB 实验情景中一方面需要保证统计数据算的快、统计数据延后低、使用者查阅统计数据快,另一方面也要保证统计数据的准确度,保障统计数据不丢太重。 统计数据破冰当面对一条网络流量可能包含几十个实验标签 ID 的情形时,从分析角度出发,只需要选中一个实验标签和一个对照实验标签展开分析;而如果透过 like 的方式在几十个实验标签中去匹配选中的实验标签,同时实现效率就会非常低。最初他们期望从统计数据入口处将实验标签打散,将一条包含 20 个实验标签的网络流量拆分为 20 条只包含一个实验标签的网络流量,再导入 Doris 的聚合数学模型中展开统计数据分析。而在这个过程中他们遇到一个明显的问题,当统计数据被打散之后会膨胀数十倍,百亿元级统计数据将膨胀为千亿级统计数据,即便 Doris 聚合数学模型会对统计数据再次压缩,但这个过程会对集群造成极大的压力。因此他们放弃该同时实现方式,开始尝试将压力分摊一部分到计算发动机,这里需要注意的是,如果将统计数据直接在 Flink 中打散,当 Job 全局 Hash 的窗口来 Merge 统计数据时,膨胀数十倍的统计数据也会带来几十倍的网络和 CPU 消耗。接着他们开始第三次尝试,这次尝试他们考虑在 Flink 端将统计数据拆分后立刻展开 Local Merge,在同一个算子的内存中开一个窗口,先将拆分的统计数据展开一层聚合,再透过 Job 全局 Hash 窗口展开第二层聚合,因为 Chain 在一起的两个算子在同一个线程内,因此可以大幅降低膨胀后统计数据在不同算子之间传输的网络消耗。该方式透过两层窗口的聚合,再结合 Doris 的聚合数学模型,有效降低了统计数据的膨胀程度,其次他们也同步推动实业务方定期清理已下线的实验,减少计算资源的浪费。 考虑到 AB 实验分析情景的特点,他们将实验 ID 作为 Doris 的第一个排序字段,利用前缀索引可以很快定位到目标查阅的统计数据。另外根据常用的层次组合建立物化视图,进一步缩小查阅的统计数据量,Doris 物化视图基本能够全面覆盖 80% 的查阅情景,他们会定期分析查阅 SQL 来修正物化视图。最终他们透过数学模型的设计、前缀索引的应用领域,结合物化视图能力,使大部分实验查阅结果能够同时实现以单返回。统计数据一致性保障统计数据的准确度是 AB 实验平台的基础,当演算法项目组呕心沥血强化的数学模型使电视广告效果提升了几个百分点,却因统计数据丢失看不出实验效果,这样的结果确实无法令人接受,同时这也是他们内部不允许出现的问题。那么他们该如何避免数据丢失、保障统计数据的一致性呢?自研 Flink Sink Doris 组件他们内部已有一套 Flink Stream API 脚手架,因此借助 Doris 的幂等写特性和 Flink 的二阶段提交特性,自研了 Sink To Doris 组件,保证了统计数据端到端的一致性,并在此基础上新增了异常情形的统计数据保障机制。 在 Doris 0.14 版本中(初期使用的版本),他们一般透过“同一个 Label ID 只会被写入一次”的机制来保证统计数据的一致性;在 Doris 1.0 版本之后,透过 “Doris 的事务结合 Flink 二阶段提交”的机制来保证统计数据的一致性。这里详细分享使用 Doris 1.0 版本之后,透过 “Doris 的事务结合 Flink 二阶段提交”机制保证统计数据的一致性的原理与同时实现。在 Flink 中做到统计数据端到端的一致性有两种方式,一种为透过至少一次结合幂等写,一种为透过恰好一次的二阶段事务。
应用领域展示
下图为 Sink To Doris 的具体应用领域,整体工具屏蔽了 API 调用和拓扑流的组装,只需要透过简单的配置即可完成 Stream Load 到 Doris 的统计数据写入 。 集群监视在集群监视层面,他们采用了社区提供更多的监视模板,从集群分项监视、主机分项监视、统计信息处理监视三个方面出发来搭建 Doris 监视体系。其中集群分项监视和主机分项监视主要根据社区监视说明文档展开监视,以便他们查看集群整体运行的情形。除社区提供更多的模板之外,他们还新增了有关 Stream Load 的监视分项,比如对当前 Stream Load 数量和写入统计数据量的监视,如下图所示: 除此之外的报警平台展开监视告警,报警方式支持电话、短信、推推、邮件等。总结与规划
目前 Apache Doris 主要应用领域于在线视频情景,已有数十台集群机器,全面覆盖近 70% 的动态统计数据分析情景,同时实现了全量离线实验平台和部分离线 DWS 层统计数据查阅加速。当前日均新增统计数据规模可以达到百亿元级别,在大部分动态情景中,其查阅延后在 1s 内。同时,Apache Doris 的获得成功破冰使得他们完成了动态数仓在 OLAP 发动机上的标准化。Doris 优异的分析性能及简单易用的特点,也使得数仓构架更加简洁。
未来他们将对 Doris 集群展开扩展,根据业务优先级展开资源隔离,完善资源管理机制,并计划将 Doris 应用领域到 360商品化内部更广泛的业务情景中,充分发挥 Doris 在 OLAP 情景的优势。最后他们将更加深入的参与到 Doris 社区中来,积极回馈社区,与 Doris 并肩同行,共同进步!相关链接:SelectDB 官网:https://selectdb.com Apache Doris 官网:http://doris.apache.orgApache Doris Github:https://github.com/apache/doris开源技术论坛:http://forum.selectdb.com/











