字节造火山，又一个数据中台的故事

68 阅读 0 评论 0 点赞

字节造火山，又一个数据中台的故事

雷锋网按：外界总会首先注意到字节跳动不少产品是建立在推荐引擎上的，但也往往会忽略与推荐引擎相辅相成的还有数据中台。从简单的A/B测试，到后来的数据分析平台、数据开发治理、ABI、极速OLAP引擎等一系列产品形态的拓展，逐渐形成了数据中台如今的模样。而这项工作的主要承担方，其实正是最近一段时间字节跳动开放出来的火山引擎数据中台。

字节跳动的早期其实并没有很成熟的数据处理体系（比如数仓），更别说有数据中台这类体系了。但就在短短几年间，伴随今日头条、抖音、西瓜视频等多款爆款应用的成长，字节跳动的数据架构、实践路径、产品体系也逐步打磨出来。

在字节内部，数据中台受到业务线的格外重视，一旦有新的产品业务上线，都会找到数据中台请求支撑。正是这种休戚与共、强调解决问题的务实精神，让数据中台对内已经能够支撑集团数百条业务。而最近一年，越来越多的外部客户、圈内厂商也跑来咨询：“诶？你们的数据中台BP团队、增长引擎，究竟是怎么搞的呀？”

在数据中台团队看来，现在有很多客户对字节跳动内部数据驱动的理念和实践是非常感兴趣的。只是当前阶段，数据中台需要进一步加快最佳实践的产品化，满足客户的差异化诉求。

那么，何为中台BP？何为数据驱动增长？何为“以应用为中心”的数据中台？雷锋网近期与火山引擎数据中台负责人罗旋进行了一次深入交流，以还原当下火山引擎数据中台的独到之处。

抖音的早期故事

2020年9月，来自一份第三方的调研数据显示，抖音用户日均总使用时长是441.6亿分钟。换算成你能理解的时间跨度，意味着将近9万年。抖音获得用户青睐的同时，也在悄悄地改变着互联网流量战争的格局。

实际上，因其强大的Feed流和推荐算法，抖音平台的早期用户自然增长率非常高，无论是用户黏性、活跃量，还是停留时长，这意味着抖音早期几乎不需要什么大力投放，因为本身它就是一款产品力非常强的应用。

时局到了第二阶段，就不太一样了。大概是在2018年初，抖音平台上已经积累了大量活跃用户，为了进一步优化体验，给用户带来价值，产品也同时进入到了功能版本迭代的高发期。这时，就会遇到一个命题——A/B测试固然有效，但如何保证每一次迭代的决策长期来看是正确的？此时，产品经理就需要依靠大量的数据对产品的各种情况进行测算。

再往后，抖音的用户体量已经足够大，且进入到增长曲线的平滑期，除了精细化运营外，更需要探索新的增长空间。产品如何快速试错、大量尝试？此时，无论是底层引擎的响应速度，还是贴近应用层的工具服务，都需要跟上抖音的业务节奏。

分析以上过往你会发现，抖音从早期发展到如今的成功，离不开数据驱动理念的支撑，而给这一理念披上产品外衣的，用今天的视角来看其实就是火山引擎的数据中台。

火山数据中台的前世今生

在字节跳动内部，有这么一句话：“A/B是一种信仰，风神（数据洞察平台）是一种习惯。”

2014年前：

可以说，A/B测试从2012年字节跳动创建之初就已经开始应用，通过A/B测试来消除偏见，接近客观事实。

2014~2018年：

随着A/B测试越做越多，字节团队发现非A即B的负面影响，只看一个结果是不够的，需要进一步对数据进行分析以佐证判断，为此在A/B测试的基础上开发了数据洞察平台风神。而像数据集成、数据开发、数据治理等更多的工具也逐渐在这段时间里成型。

值得一提的是，数据中台基于Clickhouse开发的OLAP引擎也是在此期间上线和能力改造，以解决数据分析性能的瓶颈。

这个阶段，主要解决的是效率和成本优化的问题，包括对底层架构进行升级，从接入第三方的工具，到尝试自研一些开发工具、调度工具等，使得研发和运维的效率变得更高。

2018年~2020年：

2018年应该是一个比较关键的节点，并且为字节跳动带来了三个主要改变。

一是数据中台的“成型”。

这个节点开始，字节跳动业务有了更深入、全面化的发展，继今日头条之后，陆续有抖音等现象级的爆款应用，以及孵化的新业务。“正是因为火山引擎的数据中台在头条、抖音都打磨过，所以当有新的业务出现时，可以非常快地接入。”罗旋指出。

二是数据中台的BP化。

另一个重要变化是，在业务线变得越来越多的同时，很多业务的体量也足够大了，比如为抖音提供服务时，单纯提供一些通用型工具是不够的，而是需要更加贴近其业务场景，满足其定制化的场景需求。

这种背景下，字节跳动也开始筹备“数据中台的BP团队”，对“前端”业务进行专门的支撑。BP全称是Business Partner，类比于HRBP，组织形式上是集中式的，可以统一管理调配培养，执行上分布式到各个业务，解决业务问题。这种组织方式的优势在于，尽管BP团队向上支撑了不同类型的业务线，但向下其实是兼容了底层数据的各项能力，具备相似的技能栈，对工具引擎的学习和使用是高效且顺滑的。

雷锋网认为，除了数据中台底层好之外，字节跳动BP团队存在的基础是其企业具有强有力的组织能力，以及企业的部门墙比较低，否则怎么能让业务部门和中台组织能够很好融合？

三是真正意义上有了“客户”的理解。

这一个改变是水到渠成的。正是因为数据中台早期在支撑更早期的业务线方面积累了很多的“信誉”，为今后支撑更多的业务线奠定了良好基础，并形成了正循环。

这种视角下，需要团队不仅有对数据的理解，还要有对“客户”的理解，将业务线看成你的“客户”，还能根据需要提供一些定制化需求。

字节造火山，又一个数据中台的故事

【图：火山引擎数据中台架构图】

2020年之后：

2020年字节跳动将数据中台通过火山引擎对外开放，恰恰说明了一件事：字节跳动的数据中台已经很好服务于内部，它开始思考如何服务好外部的事情了。

无论是之前的飞书，还是如今的火山引擎，逐步将内部实践过的技术或用的好的产品开放出来，在形成商业化路径的同时，还能反馈给内部，进一步提高内部技术。

从面向“业务价值”入手

越来越多的企业经历了建中台到拆中台的过程，但不同的是字节跳动始终在坚守中台，并且还通过火山引擎对外开放了，这是为什么？

原因不难得出——字节跳动的中台发挥了应用的价值，一是上面说的BP制给业务带来了很好的支撑；二是面向业务价值构建数据中台，先判断业务的需求是什么，然后提供轻量化的工具，随之再逐步配套更多的能力。

这样的方式也延伸到了火山引擎数据中台的服务理念上来，面向应用构建数据中台。简单来讲就是，面向应用更有目标性，能更早地发挥数据的价值，让企业客户的数字化转型路径不再是一个漫长的周期建设，而是一个逐步演进的过程。换一个更好的理解方式，其实是面向企业客户实际需求，以及业务价值构建数据中台。

这与其他的数据中台厂商的服务有点大相径庭，他们侧重于搭建完整的体系，这种方式往往会给客户带来困惑：周期非常长且重。数据中台最后是搭好了，但有不少客户往往也找不到数据应用的场景，数据中台建了半天没用起来，更没发挥出应有的作用。如果此时企业没有一个强有力组织的话，很有可能“中道崩殂”。

业界有的数据中台厂商也开始从场景侧延伸出某些工具或解决方案。双轮驱动看似美好，但实则需要上中台的企业客户对数据中台厂商价值输出有极强的容忍度。

对于如何更好地上数据中台，雷锋网根据采访也梳理了几点要素：

首先，上数据中台的最好是业务发展或变化快速的部门，因为这些业务上中台，一是ROI容易成正比，二也能充分发挥数据的价值，容易得到各方认可。
其次，一开始不一定就得从统一数据口径入手，是不是可以先容忍数据层面一定程度的混乱，验证价值。当业务发展起来后，再去治理它，这很大程度上符合敏捷的理念，也符合很多企业的实际情况。
然后，针对业务价值或实际存在的问题提供服务，务实而非务虚。火山引擎数据中台的服务步骤一般是：1.先上专家或架构师，进行项目诊断；2.用产品和解决方案，走通关键路径；3.当核心业务问题被解决后，也有一些事情是需要客户自己来完成，这时也能够针对性提供一些咨询服务，从授人以鱼到授人以渔。经过一两轮的迭代，会发现，企业客户的数据中台正一点一点长起来。

在这个过程中，罗旋认为最好的服务策略是，先理解清楚客户问题是什么。在他看来，数据中台可能根本就不是需求，或者说就是个不准确或错误的需求。追本溯源，首先要了解客户的原始问题是什么，数据中台只是解决的路径或方法之一。