独家揭秘阿里文娱数据服务平台发展史

背景

近些年，随着双 11、618 等营销活动的常态化，优酷对内部的数据分析能力提出了更高的要求。主要体现在以下三方面：

1. 实时性：传统的离线数据分析已无法满足强实时性的数据分析需求。在面向直播的数据大屏中，需要实时计算在线人数、CDN 带宽水位、直播体验（错误、卡顿等）等大盘数据指标，需要全网的客户端日志以及个别服务端日志，无疑对数据的实时性提出了更高的挑战；

2. 灵活性：除已经固化的业务报表外，新上线的活动、研发为了优化某一个模块所依赖的数据分析，都需要灵活、个性化的维度；

3. 平台化：尽管依赖阿里集团的数据生态体系，但 Case By Case 的业务开发仍旧无法满足实时大屏需求，开发、维护成本增加，如何快速支撑实时大屏的流式计算成为数据团队要解决的核心问题。

面对上述三个方面的挑战，优酷数据团队首先解决了数据实时性问题，并在过程中沉淀出了面向实时、离线的多维度聚合统计分析类场景，提供模型搭建、数据计算、数据可视化的一站式数据服务平台。

前身：实时多维度聚合计算

每年的双 11，除阿里集团的双 11 媒体大屏外，每个 BU 的大促、活动、战役都有自己的实时大屏，优酷也不例外。面对的主要挑战如下：

1. 技术挑战：实时大屏都对数据有非常高的要求，同时面临着高吞吐、低延时、零差错、高稳定等多方面的挑战。仅世界杯期间，直播相关日志的实时流计算处理峰值就达到 1 千万条/秒，处理的总数据量高达百亿，期间实时大屏的稳定性保持在 3 个 9 的水平，并且要求分钟级的数据延时，涉及多维度分析；

2. 业务挑战：在面向直播的数据大屏中，为了实时计算在线人数、CDN 带宽水位、直播体验（错误、卡顿等）等大盘数据指标，需要全网的客户端日志以及个别服务端日志。另外为了让技术同学更全面的分析流量，增加了很多实时的数据维度，比如理论带宽降级策略需要端、版本、清晰度等，再比如播放体验卡顿相关需要运营商、省份城市、网络制式等维度。这些数据监控了当日直播的方方面面，也是活动应急决策的重要依据。

3. 整体架构：

1） 埋点日志采集系统：阿里自主研发的无线端 APP、H5 埋点采集工具，并且定义了一套客户端的埋点规范；

2）TT：TT（TimeTunnel）是一个高效、可靠、可扩展的消息通信平台，基于生产者、消费者和 Topic 模式的消息中间件；

3）Blink：Blink 是阿里基于 Apache Flink 自研的实时流计算引擎，支撑阿里绝大部分实时计算任务，支持专有云打包输出。平台易用性高、数据准确性 100%、集群线性扩展、支持容错、支持多租户、资源隔离；

4）OTS: 表格存储（Tablestore）是阿里云自研的 NoSQL 多模型数据库，提供海量结构化数据存储以及快速的查询和分析服务。表格存储的分布式存储和强大的索引引擎能够支持 PB 级存储、千万 TPS 以及毫秒级延迟的服务能力。

为了满足性能要求，优酷采用预聚合的技术架构。依托于实时流计算引擎，对端上采集上来的日志做实时 ETL、数据立方体预计算并落地 KV 存储，对外提供毫秒级响应的数据查询。 分别从稳定性、实时性、开发效率提升上做了以下工作：

1 稳定性

面对如此庞大数据量的实时计算，稳定性压倒一切，为了保障实时大屏的稳定性，做了一系列的任务优化、蓄洪压测、主备链路等工作。

1）任务优化

首先是任务的优化，众所周知，在流式计算 shuffle 中，当下游处理能力不足时，会通知上游停止发送数据，从而避免数据丢失。这就造成了任务的反压，使得实时流计算的吞吐量一直上不去，这时候就要对任务整理分析性能瓶颈并作出优化。

我们遇到了三个造成反压的问题，一个是 IP 解析的 UDF 问题，一个是数据倾斜，一个是 KV 存储的写入瓶颈。

a) 任务上线做蓄洪压测时发现，source 节点资源（cpu/mem）并未打满，却出现了数据延时。并且并行度已经达到了 TT 分区的上限，无法通过简单的增加并行来解决。经分析，由于 Flink 中一个 Vertex 是多个 Operator 的结合，进一步拆分 Operator 后发现是解析 IP 的 UDF 出现了性能问题，修复后 source 节点吞吐量大幅提升；

b) 数据倾斜是大数据处理中老生常谈的问题了。在优酷的业务场景下，在做聚合统计的时候，很多时候是按 CDN 域名、运营商、版本等维度统计，不可避免出现热点问题，尤其是 CDN 域名基本都集中在头部一两个上，长尾却有很多。造成的现象就是该节点增加并行度毫无收益，并且资源大量空闲，in_queue（用来缓存需要计算的数据）却一直被打满，造成反压。定位该问题的思路就是进入明细看每个 TaskExecutor 的 TPS，发现除了头部的几个外，其他节点 TPS 和 in_queue 都是 0，所以这里有明显的数据倾斜。解决该问题的思路是先对散列字段做 HASH 取模分桶，先做桶内的局部聚合，再做全局聚合；

c) 为了保证更高的实时性，用的是纯流式计算，并非 window 的方式聚合，这使得输出的 TPS 要高的多。发现 Sink 节点也出现了性能瓶颈，并且增加并行度已无效，为了提高写出速度，通过调整 Sink 的 batchSize（根据 rowkey 去重的 buffer）参数来优化输出。

2）蓄洪压测

蓄洪压测也是依托于 Blink 提供的模拟上游压力的能力，通过回放 TT 的历史日志来生成影子作业，完成链路的压测。并且在压测中进行任务优化并应用于原实时任务。在战役前共组织了三次大数据压测，完成了几十个作业的压测配置优化，压测的峰值 TPS 达到了 3 千万。

3）主备链路

为了解决 OTS 分区自动裂变（类似 HBase 的自动分区，当出现某个 Region 的写入热点时，为了提高吞吐会对该 Region 进行分区裂变以提高吞吐，但是会导致服务的短暂不可用），以及流计算高峰期存在 Failover 的风险，对实时链路做了不同集群的双链路备份，以及存储不同集群实例的备份。同时在服务端通过预案平台做查询请求的无缝切换，以此来保证链路的可用性。

此外，由于主备链路计算数据立方体维度较多，对于核心的大屏数据指标，单独隔离了兜底的实时计算任务，保证即使主备链路都失败也能保证核心业务的平稳运行。

2 实时性

在实时大屏的业务中，尤其是技术侧的大屏，涉及到直播作战的实时决策，对数据实时性要求较高。为了保证实时性，弃用 window 的计算方式，采用纯流式计算（中间结果通过 state 保存，并流式输出到存储中）。依托于 Blink 强大的实时计算能力，为了提高吞吐，读写 State 开启了 MiniBatch，基于事件消息来触发微批 State 的更新操作。

3 开发效率

从前几次的实时计算开发经验来看，one by one 的业务开发无法满足日益增长的实时大屏需求，开发、维护成本逐渐增加。如何快速支撑实时大屏的流式计算成为数据中台团队要解决的核心问题。

在实时数据统计的场景中，大部分都是根据某些维度进行去重、求和、算记录数、求最大值、求最小值、求平均值、算排行榜等聚合计算，另外还会涉及到实时多表 join、静态维表关联等。对业务模型抽象后，逐步形成了配置化的实时计算开发框架。

核心思路是，经过 ETL-Pipeline 将数据处理成时序数据模型（指标、维度、时间戳），针对生产出来的时序数据，再进行数据立方体的配置化计算（同时对数据立方体做业务剪枝，优化成冰上立方体从而降低计算成本），将聚合计算的结果按统一的协议格式写入 KV 存储中。这样，实时任务的接入就只需关注业务 ETL，同时需要聚合计算的维度即可，不同业务按同一套协议规范写入 KV 存储中，并通过 biz_code 加以区分，服务端通过 biz_code 面向指标、维度查询不同业务的数据。

数据立方体

假如将计算某指标在[A,B,C,D]四个维度排列组合，那么所计算的数据立方体长这个样子：

如上所示是一个完全立方体，不难算出若维度为 n，则总的立方体单体个数为 2^n 个，其存储的数据量总大小为各个维度基数的乘积。如果数据立方体中所有方体都预先计算，所需存储空间可能爆炸，特别是当立方体包含许多维时，会造成维灾难。尤其是在实时计算中，翻倍的数据量级会大大影响流计算吞吐量，所以根据业务的实际需要会对立方体做必要维度、层级维度、维度组等裁剪。

这些完全通过配置化来实现，剪枝后的数据立方体：

那么如何实现实时计算中数据立方体的构建呢？

实现的算法并不复杂，通过 udtf 来实现单条记录的 dispatch，对分发后的数据做聚合统计：如计算[A,B]的数据立方体，分发后的结果为[A, ],[A,B],[ ,B],[ , ]。内部通过遍历二进制数组来做到所有维度的不重不漏，并在此基础上进行过滤，实现数据立方体的裁剪。

原理图示：

数据服务平台

随着上述问题的解决，业务开发的效率逐渐提升，业务也向着更灵活的方式演变。随着业务的逐渐增长，Blink 实时任务数逐步增加，又衍生出了一系列的挑战，如任务的后续维护、元数据管理、降低成本、数据膨胀等等。

为了更好地把优酷的实时、离线数据赋能给更多的业务方使用，我们通过架构升级、底层逻辑封装等方式来突破现有瓶颈。旨在打通文娱数据中间层的模型搭建、OLAP 数据引擎、以及工程侧元数据管理和数据查询服务，结合前端通用可视化组件，提供集数据研发、数据展示一体的文娱数据平台。

面向两类用户提供服务，一类是数据研发同学（技术、产品、数据分析），可通过数据服务平台构建多维度分析的实时、离线数据模型；另一类是数据使用方（运营、产品、数据分析、技术），如运营可通过图表查看数据或者技术同学通过统一接口获取数据（HSF/HTTP）。

以下为系统架构图：

从整体架构设计可以看出，为了解决 Blink 实时任务不断增加维护成本升高的问题，我们把数据模型集中管理，在平台上定义数据模型，并打通 Blink 和 ODPS 提交实时/离线任务，同时提供维表查询检索的能力，将文娱数据集中起来为业务提供数据服务。

在降低计算成本的目标上，数据服务平台做了两件事， 一个是计算脚本模版化 ，面向不同的业务场景提供不同参数配置、生成不同的计算脚本，比如实时计算是否启用 window 模式等； 另一个是由数据服务平台提供指标的后置计算能力 ，如常见的点击率指标，CTR=点击 PV/曝光 PV，由于双流 join 需要消耗额外的计算资源，并且行为日志量级较大，更加剧这个问题。通过数据服务拆解两个数据模型，并创建衍生指标配置点击率的表达式，即可查询。

另一个问题要解决的就是预计算不适合的场景，比如维度较多、维度基数较大的部分场景，Ad-hoc 场景等。由于数据服务面向上层使用方已定义了一套面向多维度聚合计算的查询协议，在常规的 OLAP 引擎上也可以做 SQL 语义的转换，针对这种场景可以定义数据模型并由数据服务做建表、数据同步等操作，目前仅支持阿里集团内的 ODPS 等数据源。

未来规划

在现有的数据服务平台上，我们逐渐收纳了标准定义的各类数据指标，如内容消费分发的曝光、点击、CTR、转化率等，又如播放体验类的 VV、成功率、卡顿率、秒开率等。这些数据一方面服务于数据分析场景做报表的可视化展示，一方面提供给其他系统应用做策略等业务使用。在收口此类标准化数据后，未来就可以在数据之上提供更多自助式分析工具、监控报警、日报月报等可插拔的功能组件，以满足不同的业务需要，抽象此类公共能力。另一方面，在资源成本方面，尤其是在预计算模块，可以增加数据立方体的诊断优化，持续优化降低成本，以防止租户内资源使用过度等问题。

结语

做技术的同学除了解决业务问题本身以外，要有敏锐的嗅觉和产品思维，以发现业务问题背后的深层逻辑。比如数据服务平台最初的目标仅是为了解决实时多维度计算问题，然而成本、开发效率、数据维护等潜在问题浮现而出的时候，就要求技术同学要走在业务之前，逐步抽象问题，通过平台化或者其他手段来提出解决方案。当业务能够尽快落地实现的时候，也能推动业务本身尽快进入新一轮的迭代周期，充分发挥技术价值。

作者介绍：阿里文娱技术专家 布鸪