分享嘉宾：陈仕明 虎牙直播 计算平台负责人
编辑整理：韩城 新浪微博
出品平台：DataFunTalk

导读： 大家好，非常高兴能够通过直播的形式跟大家进行技术交流，这次分享的议题主要是数据平台在成本和用户服务SLA两个方向的技术交流。有些同学看到这两个方向，可能会有疑问，因为过往在行业里大数据的分享，主要集中在比如平台建设、指标体系或者数据治理，更多是技术引擎的一些深度实践，但是在成本和SLA方面，在行业里相对比较少分享。所以，我们也正好借助Data Fun平台跟大家做一次交流，希望能够给大家带来一些启发。

选择这个议题主要有两方面原因，一个是 行业对“开源节流”的日渐关注 ，开源方向上，不管是从资本层面，还是在用户营收层面，在目前行业背景下，相比以往都更难做了，所以既然不好“开源”，那当然就要“节流”了。因此我们看到越来越多的公司把降本提上了日程，也促使我们想和大家在成本这个方向交流一下。

另一个原因是，基础设施上云在整个行业来看，已成为不可逆的发展趋势。而数据平台团队负责的是大数据这一块的基础设施，提供基础的存储和计算服务，从某种概念上来说，其实和公有云存在一定的竞争关系。另外，我相信公有云比绝大多数公司里的数据平台团队，必然更具备技术优势，所以如果一旦你的公司要求大数据这块业务要上云，那数据平台团队的方向又该是在哪里？所以在上云趋势下，也促使我们数据平台团队不停地去思考这个问题。

所以正是因为在上面这两个方向上的考虑，于是我们挑了这两个方向来和大家做一次分享和交流。

全文将围绕以下三方面展开：

• 虎牙数据平台的发展轨迹
• 虎牙大数据平台的定位
• 虎牙大数据平台未来的探索方向

01 虎牙数据平台的发展轨迹

首先和大家简单介绍一下虎牙公司。虎牙作为国内知名的游戏直播平台，一直践行技术驱动内容，在直播游戏化和虚实融合技术领域不断创新，为行业和用户赋能。

回到我们本次的分享主题上，我先介绍下虎牙数据平台的发展轨迹。主要有三个阶段：

• 第一阶段：2017-2018年

这两年虎牙刚从欢聚独立出来，需要建设数据平台，所以首先在大数据的研发效能上进行投入，其实大部分公司的数据平台还处于这个阶段，主要解决的是如何更简单、便捷、高效地支持端到端的数据开发。

• 第二阶段：2019-2021年

随着业务越来越复杂，数据和计算规模越来越大，随之投入的大数据资源成本也随之大幅增长。于是我们从2019年开始，工作重心逐渐转移到成本方向上，比如怎么把YARN全天利用率提升至90%以上。我相信很多公司对于周期任务来说，都面临着相同的问题，就是凌晨的时候算力不够用，但是过了中午，到下午的时候，又有大把的算力闲置。所以，第一个问题我们怎样才能把离线计算的YARN的利用率提升上去。第二个问题，针对在线业务空闲的算力，我们做了大数据的全面容器化改造。现在整个的大数据，全都是基于容器，存算分离的架构，并且其中一大半的离线算力是“免费”使用在线业务的空闲算力。另外，我们在2021年又做了Hadoop EC，目前80%的数据都已经切换用EC 6+3的格式存储，相当于只需要用1.5个副本，就能保障以前三个副本才有的数据完整性，相当于节省了一半的存储。

• 第三阶段：2021年至今

经过前面两部分的工作沉淀，在成本方向上的优化工作已基本完成，当然后续肯定还会有一些优化空间，但投入产出比已经相对较小。所以，我们也在思考接下来的方向应该是什么？经过多年的积累，我们掌握了非常多的元数据，不管是业务侧的，比如任务与任务之间的依赖关系，数据的查询语句和查询频率等，还是任务本身如对资源的消耗，亦或如任务的稳定性这些技术元数据。有了这么多的元数据，如何才能发挥这些元数据的价值，成为我们思考的核心问题和实践方向。所以从去年开始，我们启动了一个新的“智能化”的工作方向。今天的分享，主要集中在针对上面我们第二阶段的工作内容，期望能够和行业内的同学，进行更多的交流和碰撞。

02 虎牙大数据平台的定位

接下来，先介绍一下我们在成本和用户服务保障方面的实践。 首先，从平台定位出发，我们为什么选择了这个工作方向，这得先从组织分工来说。

从上图可以看到，虎牙数据技术方面的分工比较细，很多公司可能都是把大数据相关的所有东西整合到一个大部门，比如数据推荐、数仓，还有底层的数据平台。而虎牙则是分成了三层，每一层都分属在不同的一级部门之下，之间合作属于跨部门的对外合作。其中数据平台属于基础保障，负责对外提供大数据场景下的存储和计算服务。我经常把我们的工作内容，类比为我们只负责修建一条低成本、高可靠的一条水管，但不负责往水管里面灌水。灌水的事情是由数据中台负责，他们理解数据架构，负责在这个“水管“里面把水丰富起来。同时，他们负责确保水的质量、水的安全，也就是一些基础的数仓模型建设。再往上，就到了业务前台，他们更能理解公司业务，知道数据如何能够更好的产生业务价值，所以他们利用数据中台所提供的高质量数据模型，快速迭代输出数据产品功能。这个过程，我经常类比为，前台根据市场需求，把中台提供的高质量“基础水”包装成如“矿泉水”、”纯净水”等市场产品。

当团队的边界和职责细分之后，我们思考的问题就会不同，俗称“屁股决定脑袋”。第一，因为属于跨部门的服务提供方，那用户对我们的要求相应就会高很多，所以要主动思考 我们在用户那儿的价值核心是什么 ？第二，因为我们现在归属于资源层对应的部门，该部门纯粹是一个费用成本部门，不直接应用数据产生业务价值，那么我们在公司层面上的价值是什么？第三，越是底层，其能力越容易被云厂商所覆盖，那么我们数据平台与公有云的关系和核心差一点是什么？在上云的大背景下，我们团队的未来发展走向是什么？

我们主要思考这三个方向的问题，接下来是沿着这些问题，我们思考得到的一些自己的答案，希望和业内同学进行探讨。

首先，从老板的角度看 ，我们作为一个费用部门，老板肯定最关注成本。成本的公式由“单价*量”而构成，所以我们也是围绕这两个因子来思考：第一，如何去降低单价，比如降低存储的单位成本，降低计算的单位成本；第二，如何去降低“量“，作为大数据领域内统一的服务提供方，我们有职责站在公司层面上去评估用户在大数据领域内使用服务的合理性，是否存在浪费。

其次，从用户的角度看 ，我们是服务提供方，提供的服务最好就是简单，能够“开箱即用”的。这就要求我们数据平台团队要成为大数据系统栈的技术专家。第二，服务能力能够覆盖研发和运维环节，尽可能的降低数据研发同学的精力投入，能够让他们更集中精力在数据内容和价值建设上，所以我们也提供数据开发的后续运维服务，让大数据引擎在研发和运维上形成闭环，让数据研发专注在数据价值挖掘上。

最后，从云的角度来看 ，怎么样才能把云厂商的能力充分利用好，取其长而补自身之短(俗称“薅云厂商的羊毛”)，积极地复用行业内的已有能力，而不是“闭门造轮子”。多“往上”看，替老板和用户去解决问题，而不是“向下”看，去和更具备优势的云厂商去“卷”。

再回到虎牙大数据平台，关键是做两个事情 。 一个是面向数据研发侧的【零运维】 ，让数据研发侧不需要关心运维的事情。由数据平台主动分析用户的场景，大数据场景下的几个典型场景有如离线计算、实时计算，还有实时数据的数据分发订阅，我们从用户最关切的问题出发定了SLA。例如离线任务，用户把任务提交上来后，实际上对周期任务来说准时率就是用户最关注的问题，因为延时可能会影响到数据价值的产出。

所以，我们把SLA定义在用户最关切的地方，不要怕做多。当然这种SLA没办法全部由数据平台闭环掉，所以也需要和数据开发同学来共同承担；第二，从成本角度看，成本是量和单价构成，我们和用户的计费模式、资源量的预算，全部按任务实际使用量来计算，简化用户在这块的工作。这种模式和先前用户按照队列中的资源数量来提预算的方式完全不同，那种模式是按服务器的数量，譬如100台或者增加200台服务器来算，但是增加的200台服务器，用户是否用满，完全是由用户承担，平台不负责。但现在是按用户实际使用的算来计算，资源利用率由平台负责，由平台去做闭环做利用率的优化，虽说承担的范围和责任更大了，但优化的空间也大了很多。关于量方面的优化措施，除了常规的比如异常治理、top任务优化等运营手段而外，我们更在单价方面上，集中在如离在线混部，还有基于准时的基线调度上。

最后，和大家介绍下 目前取得的成果 。从上图左侧的虎牙数据平台架构图可以看出，虎牙数据平台是多机房的架构。之所以需要多机房，是因为整个数据平台，我们采用了离在线混部的模式，在线业务是两地三中心的架构。所以，在线业务在哪里，离线业务也需要跟着去哪里。在线业务是多机房的，那么离线业务也需要是多机房。

我们的离线业务目前是部署三个中心机房，其中两个是云下IDC的在线业务中心机房，另一个是云上机房。云上机房的目的是解决大数据的弹性需求，例如应对紧急数据需求，或者大型赛事直播等场景，在这些特殊时段，数据平台算力消耗很大，但是过了这段时间就不需要额外算力了。所以这种情况下，我们是通过云上的方式做临时扩容。

因此， 虎牙数据平台的第一个特点是多机房 。第二，整个大数据的离线计算部分是纯算分离的架构。我们的Hadoop、YARN全部是容器化，YARN的算力也全部是弹性的。接下来就是离在线混部，然后是准时基线调度。

最终成果：通过上述多项成本优化手段，目前离线计算单位算力成本降低了75%，存储单位成本得益于Hadoop EC的大范围落地，降低了40%。

03 虎牙大数据平台未来的探索方向

未来，我们将围绕智能化方向，致力于探索如何将元数据用好，包括任务运维、计算优化、存储生命期的管理和数仓建设，这个就不展开说了，大部分都还在探索阶段，希望两年后，能够在这个方向上有较好的落地效果之后，再来和行业内同学进行分享交流。

接下来，介绍下我所理解的 数仓智能化 。未来如果实现了智能化，那离线数据开发的模式是怎样呢？上图红线以上部分是现在的开发模式，可以看到整个开发流程是很重的：首先接入源头数据，接着通过ETL开发工作，再把这些数据加工成数据模型，然后根据报表层对数据的需求，把模型进行二次汇总，最后把汇总后的结果存到如MySQL，报表从二次汇总后的数据查询。

未来的数据开发模式是什么样的？ 首先查询加速的工作全部自动化，通过平台来透明实现，用户只需要输出轻度或中度的汇总数据模型，数据使用层直接从该数据模型上去查，因为性能较低或查询频次高的场景，加速都由平台通过物化视图的方式对用户透明的去完成，平台会根据使用场景，将合适的数据物化到合适的存储引擎中去。用户虽然在报表上查询的是轻度的数据模型，但是通过物化视图，会自动重写，在已经预先计算好的物化视图上做查询。做到了第一步的SQL自动重写，那么第二步是解决如何自动创建物化视图，让这个过程变得更加“智能”。在这两步完成后，ETL中查询加速的工作就从数据开发的工作任务中剥离掉了，这部分工作往往占了任务数的一半以上，同时因为去掉了人为参与，所以指标一致性的问题，也更容易得到解决。再接下来，就会做ETL中数据抽象模型的这部分任务改造。

所以，我在上图左下角描绘了我设想中理想中数据模型的定义。数据模型定义的不再是一个表（Table），而是一个视图（View）。表和视图在语义上的差异在于，表的数据需要指定物理存储，而视图只是定义了数据逻辑，至于存与不存、存多久，都可以完全由平台控制。用户查询的是视图，这个视图可能已经物化了，但是也可能没有物化。这就是我设想的数据开发的未来，整个开发过程和物理层脱离，只描述逻辑。这个方向是虎牙数据平台未来将持续探索的方向，也是我个人最为感兴趣的方向，并且目前已经有了一些阶段性进展。

最后，再介绍下 我们目前正在做的混合引擎物化视图 ，目的是对用户完全透明的优化查询加速。当要优化查询时，好比我们在关系数据库里建索引一样，如果说SQL慢，那建一个索引就快了。那物化视图呢？实际上也是类似的一种优化体验。对用户而言，它的优化是完全透明的。另外，我们的特点是混合引擎，因为大数据的业务场景多样，数据规模也很大，不可能有一个计算引擎能够覆盖全部业务场景，比如高吞吐和高并发，就是很难调和的两个场景。所以将来也必然是一个混合引擎的架构，因此我们设计了一套混合引擎的物化视图。根据响应的场景，将数据物化到最合适的引擎中，比如实时性更强的场景，我们物化到clickhouse，高并发的场景，我们物化到hbase，表关联的场景，我们物化到doris。

目前已有一些工作开始落地。整个项目目前在公司内也是以开源的方式在设计，以多地远程工作模式在开展，团队成员分布在北京、广州、深圳等。如果有同学对这块业务感兴趣，可以联系我，未来沿着这个方向共同努力。

分享嘉宾