7月20日火山引擎原动力大会举办，技术与业务互构共成长

ig281

火山引擎是字节跳动技术中台能力的对外输出。

技术和业务呈现出一种互构的关系，它们会互相折腾，进而制造出“麻烦”，最终实现共同成长。

7月20日，火山引擎原动力大会在北京举办，字节跳动副总裁杨震原以抖音电商作为例子，分享了火山引擎支持公司内部业务做好数据驱动的方式 。

杨震原称，抖音电商业务在发展进程中对技术部门提出诸多需求，给数据产品带来诸多“困扰”。正因这些“困扰”，数据产品得以更好地改良。反过来讲，出色的数据产品也使抖音电商的效率得以提升。技术与业务相互构建，彼此塑造、共同发展。

火山引擎是字节跳动将技术中台能力向外输出的产物。在此次原动力大会上，火山引擎发布了全新的“云上增长新动力”。并且推出了一系列云上增长解决方案。这些方案结合了字节的最佳实践以及行业发展趋势。把敏捷迭代、体验创新和数据驱动当作增长三要素。是由火山引擎与不同行业的标杆客户共同创造并打磨形成的。

杨震原表示，数据驱动理念在抖音电商的实践中，积累了诸多经验，形成了一定的技术能力，这些都沉淀到了火山引擎数据产品上 。他希望火山引擎能助力企业客户获取增长新动力 。

以下为杨震原演讲全文：

大家好，我是杨震原，非常开心大家抽出时间来参加火山引擎举办的发布会 。

大家都清楚，火山引擎是字节跳动技术中台能力向外部的输出 。刚刚谭待（火山引擎总裁）提到，火山引擎进行了更新 ，其目的是为更多企业提供“云上增长新动力” ，而数据驱动是增长动力里极为重要的一个因素 。接下来 ，我会向大家分享字节跳动内部业务实现数据驱动的方式 。

首先要说的是，数据驱动并非有数据便可驱动，而是要从解决一个个业务问题开始运转：我们要明确业务目标，此目标需能被量化，因有量化才能优化；优化效果绝非凭感觉，而是要用A/B测试等客观分析评估方法；业务过程的数字化极为重要，数字化越充分，对业务的描述就越精准；还有数字化协同工作，涵盖数据治理等手段使底层数据有规范、统一的表达，借助数据可视化等工具让更多业务角色能使用这些数据。

在围绕业务目标持续进行优化和评估的过程中，数据驱动会成为内部协同的日常习惯，最终让产品获得更有效的改进，这便是数据驱动基本的方法。在此我分享一下抖音电商在数据驱动方面的一些实践经验。

简单介绍一下抖音电商，它大概于2020年6月成立。大家能够看到，我们数据产品对抖音电商支持的一些重要节点，还能看到电商业务给数据产品的NPS（净推荐值）打分情况。2020年11月，数据产品已能支持抖音电商的核心业务，获得较好的NPS反馈，到如今NPS值应已达70%左右，在此期间我们做了各类工作及诸多改进，也可谓是伴随抖音电商一同成长过来。

生意转化时间以秒计算，如何高效开发大量实时任务？

支持一项全新业务时，数据产品会面临各种各样的挑战。其中第一大挑战是实时性 。

抖音电商的转化路径十分短，转化时间常常按分甚至按秒计算。大家能够想象，在直播卖货期间，不管是主播还是运营，他们对数据实时性的要求都极高。今天主播介绍一件商品，接下来的5秒钟内，可能会产生几万单甚至几十万单的订单，所以需要非常实时的数据反馈，这种反馈要能让主播更快更准确地做选品调整，还要能让运营人员及时制定一些营销策略，如此才能让业务更好地发展。

这与许多传统的货架电商模式存在差异。实时需求场景极为丰富，业务活动的频次相当高。在这般持续爆发的需求状况下，怎样确保数据支持能够及时达成，我们采用的方法是实时数仓。

实时数仓看似并非全新概念，不少公司都在开展实时数仓相关工作，做出来并非难事。然而，在实际将实时数仓应用于业务时，面临的挑战众多。比如数据一致性问题，直播时能迅速获取数据的实时分析。但两三天后查看统计数据时，若发现前后不一致该如何解决？这是个大问题。

再比如，在需求迭代非常快的过程中，整个链路的全流程管理能否做好。数据发布是否有合适工具。测试是否有合适工具。数据监控能否到位。实时数据一旦出问题，修复代价很大。它不像离线数据，大不了重跑一遍就行。

所以从整个流程来看，做好实时颇具挑战。我们的数据产品历经诸多业务、长时间迭代，实时数仓已较为完善。对抖音电商而言，我们如今能够提供较全套的实时数据。

实时大屏能给运营人员和主播实时反馈各项核心指标，实时分析是指若现有的实时指标不足，可在实时分析平台临时性地进行一些分析查询，比如突然想分析某一个目标人群，或者想做一个临时的漏斗分析等，这里提供了非常灵活的SQL查询并处理实时数据流，实时预警可配置各种规则，当业务情况发生变化，如当前流量突然下滑时，能提供报警功能或配置自动触发一些操作，实时营销也为运营人员提供了工具，比如运营发现“创单到成功购买”的转化低，可分析出未成功购买的人群是否对价格敏感或受其他因素影响，进而制定一些对应的营销策略，使业务有更好的转化。

大促频率高、新玩法多，如何敏捷支持各项业务诉求？

第二大挑战是敏捷的需求。

如今电商大促的频率十分频繁，电商业务具备一个特性，新的玩法众多。若要做好敏捷支持，存在诸多技术方面的方法。我今日想要给大家分享一种组织模式，即数据BP 。

数据BP是一种分工方法。我们有做公共产品的团队，叫数据平台。该团队做通用功能，做通用数据产品，能提供基础支持。数据BP嵌入到每个业务中。比如抖音电商有数据BP团队，他们与抖音电商业务目标完全对齐，为其目标努力。他们对数据平台内部颇为了解，能充分运用数据平台的产品。此外，抖音电商的数据BP会将业务需求引入数据平台，助力数据平台发展，我们觉得这个机制成效显著 。

我们总结了几个数字说明数据BP的服务标准，叫0987。

做到零数据事故，这看似是个很基本的要求。然而在业务复杂多变的情形下，实现零数据事故并非易事。它对技术能力提出了很高的要求，对运维提出了很高的要求，对治理也提出了很高的要求。

第二个数字为9，意味着90%的需求得以满足。从这个数字可知，数据BP是个服务型团队。它需将业务需求转化出来并满足好。这就要求团队熟悉业务。能与产品及业务人员深入互动。能一同探讨需求。能助力业务修改甚至提出需求。如此方能真正达成90%的需求满足。

第三个数字为8，意味着80%的分析需借助主题表、中间表的方式予以覆盖，这对中间数据的建设提出了很高要求。我们对80%这个尺度自行衡量了许久，认定其为合适的值。当这个数字很大时，比如希望所有数据都能通过中间表覆盖，这其实是不必要的。因为可能会过度抽象很多中间数据。也许需求刚提完，中间数据表刚建设完，业务就发生变化了。当这个数字过低时，意味着大量分析直接基于原始数据进行，这会引发诸多问题，诸如一些指标看似相似实则不同、口径不一致、部分分析运行缓慢等。从大量业务实践可知，80%的分析覆盖是一个相对合理的目标。

最后这个7，指的是70%的NPS。这在行业里是很高的标准。它代表业务满意度的一个评价。我们要能够通过这个指标。去发现数据服务环节中的各个问题。来提高业务的满意度。

字节内部，数据BP机制十分有效。例如不久前抖音电商举办618大促活动，业务提出诸多玩法需求，这些需求都需要定制的数据予以支持。其中有10个需求直至5月17日才完成数据详评，上线开发时间极为紧迫。不过由于存在先前沉淀下来的模型，数据BP判断有4个能够复用，部分有3个可复用，在10个工作日内就实现了100%的交付，并且沉淀出新的玩法模型，能够应用于下次的大促当中。我认为要是没有数据BP的组织模式，想要支持好如此紧迫的活动是很难达成的。

如何在满足实时、敏捷的同时确保稳定？

电商业务涉及金钱，数据计算必须准确无误，容错空间极小。与此同时，业务运营高度依赖数据，每天都要依据数据做出决策，数据务必按时产出。如此便产生了第三大挑战，即稳定。

要想实现稳定，实际上存在一些基础工作，比如监控、运维质量等。我在此想阐述的一点是数据治理，要在保证实时、敏捷的情况下确保稳定，治理是一个极为重要的问题。因为倘若不把数据治理工作做好，业务的复杂度，其中冗余的问题以及一些混乱的因素，是无法仅通过监控和运维机制来解决的。

我们提到了几个做法，其中一个是分布式治理，还有一个是经验复用，另外一个是将经验沉淀到工具中 。

为什么要提出分布式治理呢？我们早期采用的并非分布式治理模式，而是专职团队治理模式，专职团队专门负责数据治理工作。然而，当我们的数据团队需要支持众多业务时，这种模式便难以继续维持下去了，因为不可能安排一个专门的治理团队去治理各个业务 。

所以我们提出了分布式治理，要有治理委员会来制定各种标准，这些标准都来自业务上传，每个业务中都有专人负责治理工作，治理工作自下而上产生 。

我们在成熟产品积累了诸多经验，这就是经验复用。当再去支持新的产品时，能够迅速借鉴成熟产品的经验，不再重走先污染后治理的老路。除经验复用外，还需将经验沉淀于工具中，这才是进一步扩大杠杆的方法。

数据产品提供了一整套数据治理工具，这是因为在长期的数据处理过程中，我们会将一些通用能力沉淀到工具里，新业务直接使用这些工具时，不会在初期挖很多坑，能够直接达到较高的数据治理水准 。

让数据驱动成为习惯

刚才谈论了抖音电商于数据驱动实践进程里的三个挑战，接下来我会再简要介绍一下业务不同角色怎样做好数据化的运营以及决策。

数据产品并非仅供管理者使用，它要能供公司各个角色、各个层级的人使用，助力每个人都能做出更好的决策。然而，不同角色需要不同的数据产品，如此方能提高效率，更具针对性。

对于管理层，我们提供了管理驾驶舱，管理者可直接看到宏观指标，看到趋势变化，进而辅助管理者做出更及时有效的决策。对于一线的运营和风控等人员，他们可能需要查看业务数据，如罗盘，同时也可能需要BI（敏捷分析平台），还可能需要人群画像、行为分析等能指导一线工作的工具。因此，我们会针对不同的业务角色，专门定制不同的产品，以此来满足各个角色的需要。

在字节跳动内部，每月有超过10万员工直接使用BI产品，这表明数据驱动已成为大家日常工作的一种习惯，且这种习惯深入人心 。

这是字节跳动整个数据产品体系的架构图，上面呈现着各种业务，我们借助数据BP的机制对不同业务予以支持，接着是一些数据应用产品，它们直接供公司的不同角色使用，底下存在一些偏基础的产品，诸如数据建设、数据引擎等，这些产品能够支撑我们上层的应用，如此一套体系，既能满足不同业务个性化的需求，又能实现经验复用，还能复用一些底层能力 。这些能力形成了对应的产品，这些工具也形成了对应的产品，它们都在火山引擎上，被提供给外部客户使用。

技术与业务互相塑造、共同成长

我始终秉持一个理念，技术与业务呈互构关系，二者相互折腾，制造麻烦，进而共同成长。如同我刚才所分享的抖音电商实例，该业务在发展进程中向技术部门提出诸多需求，给数据产品带来诸多“麻烦”。正是鉴于这些“麻烦”，数据产品得以更优改进。反过来讲，出色的数据产品亦使抖音电商效率得以提升。技术和业务互构，互相塑造、共同成长。

我的分享到此结束。字节跳动技术中台支持公司业务所积累的经验，以及具备的技术能力，均已沉淀于火山引擎。我期望火山引擎能助力我们的客户提升业务价值，获取新的增长动力。感谢大家！