“今日头条”名字是 AB 测试定的？字节跳动用九年时间打造出了怎样的数据平台

8 月 18 日，在北京·富力万丽酒店举办的 ArchSummit 全球架构师峰会上，字节跳动数据平台负责人罗旋老师，分享了字节跳动从 0 到 1 的数据平台建设过程。从最简单的数据处理方法，到国内最前沿的数据处理手段，字节数据平台经历了多阶段的发展过程，也有很多解决问题的思路值得技术人关注。以下是演讲整理，以飨读者。

数据平台发展路径：大而全？还是从业务问题出发？

大家好，我是罗旋，来自字节跳动数据平台。今天我想跟大家分享的主题是《字节跳动数据平台的实践与演进》，主要会从我们数据平台的发展历程、为什么这么发展、每个阶段的挑战是什么，以及我们对挑战的解法等方面来介绍。

我们讲，字节跳动数据平台的演进脱离不了一个更大的背景，就是字节跳动业务的发展。抖音、头条等业务发展有什么特点？从这个图可以看出：快 + 多。

• 快：头条，12-14 年破千万；抖音上线 17 个月 DAU 破亿，5 年破六亿。

• 多：除了图文信息流、短视频，还有电商和 ToB 等众多业务线。

接来下，我们来看看数据平台当前的业务架构形态。

• 从横向来看，最上面是我们服务的客户，下面则是我们的能力，分为“中台能力 + 解决方案”两层。

• 从纵向来看，左边蓝色部分的服务对象是字节跳动内部的各个业务，右边绿色部分是字节跳动外部的企业客户。

字节跳动内部，我们的中台能力分为引擎层、建设层和应用层来建设，再通过数据 BP 团队对内部业务提供综合性解决方案，来驱动业务发展。而基于内部的这些能力和经验，我们又封装成供外部使用的中台底座和营销套件，以产品解决方案的形态，通过火山引擎来对外部客户提供服务。

如果只看这个图可能也没有太特别之处，但相信各位同行都知道，要把这么一套体系完备地搭建落地，并不是容易的事，有很大的工作量和挑战，有一段很长的路要走，很难一蹴而就。

那么，如果一个企业的决策者已经认识到数据驱动的重要性，决心要落地这样一套体系的话，接下来就马上面临一个问题：路径怎么选？怎么从零 / 初级阶段到达一个比较完备的阶段。这里，有两个选项：

• 选项 A ：要从一开始就有大而全的规划，非常明确的步骤，建设一个完善完备的系统架构，再来服务业务。

• 选项 B ：先从实际业务问题出发，业务哪有问题先解哪，优先解决业务痛点问题，让业务价值来驱动，数据体系的建设。

不知道大家心里有没有答案。

字节选的是什么呢？路径 B：从业务出发。

我们除了主观上的思考，认为更应该先解决业务问题，验证业务价值外，也有客观的因素。比如，刚才介绍的字节业务发展，相信大家也可以感觉得出来。字节的业务发展得实在太快了，我们没有时间遵照大而全的规划一步步慢慢建设好。业务等不起！

字节跳动数据平台发展历程

如果具体拆解一下，我们的发展路径可以分为这么四个阶段：

• 2014 年及以前，原始阶段

当时，只有 1 个 Hive 和最基础的几张报表，仅包括 DAU、时长等，报表仅以邮件形式来发送，是非常原始的一个状态。

不过很有意思的是，在这个时候，我们已经开始重度使用 A/B 测试了，这是我们最早相对成熟的一个系统。相信这跟绝大多数公司的发展顺序都不同，因为在那个阶段，我们认为最重要的事，就是让业务能够量化、度量，并以非常快速试错的方式来迭代。

• 2015-2017 年，基础建设阶段

我们快速补齐业务发展所需要的各项数据基础能力，包括如何让业务更快获取数据的底层引擎、让业务可自主分析的一些应用型产品等。

• 2018-2019，平台阶段

但我们的业务发展实在是太快的，除了业务体量增大，业务线也越来越多元化、有差异性。对接了更多业务线后，光建设好基础能力也不能更好满足业务需求，需要更有效驱动业务发展的方式。所以，我们在 18 年开始探索数据 BP 模式，一方面平台能力持续升级，产品矩阵扩大，另外一方面，通过 BP 的模式深入业务，可以为业务提供更适合自身发展的数据解决方案。

• 2020 年之后，ToB 输出阶段

这时，我们开始思考在对内提供优质服务的基础上，能不能也帮助更多的外部企业，把这件事做好、产生更大的价值。所以，我们也开始也把这部分能力对外开放，封装成产品套件和解决方案，对外部其他企业服务。

如何应对发展速度的挑战

在不同的阶段中，我们遇到了非常多的挑战。今天，我会分享其中一些最典型的问题和解决方案，希望我们趟过的这些坑和经验能对各位同行有一定助益。

首先就是一开始，在一穷二白的情况下，我们面临最直接的挑战就是：业务随时迭代上线，我们要怎么快速帮助业务去做验证？

这是一张 14 年今日头条迭代发版的情况，仅仅用了 3 个月不到的时间，今日头条就发版 10 次，这个速度还是非常快的，而且大部分发版都有一些新的优化改进或者突破。这还仅仅是客户端的部分，实际在服务后端、个性化推荐等领域，迭代甚至更加频繁。

这些飞速迭代的背后依靠的是什么？一个新功能、新模型、新特征为啥要增加，增加了是不是就会更好？判断的依据是什么，怎么来保障正确性？

针对这些挑战，我们的解法是什么呢？刚刚其实也已经提到过，我们是一家重度使用 A/B 测试的公司。所以，基本每次迭代的背后，都有 A/B 测试的身影。可以说，A/B 测试是字节数据文化的最典型代表。

字节的 A/B 测试发展也经历了三个阶段：

• A/B 测试是在 12 年字节跳动成立之初就开始应用了，今日头条的命名也是 A/B 测试的结果。当然，在原始阶段的 A/B 测试是很粗糙的，也不像现在有那么多功能和场景，从统计科学角度也有很多欠缺。一开始，我们对 A/B 测试的定位，只是一款快速拿到实验结果的验证工具。因为业务迭代很快，当时做一个 A/B 测试，我们有时需要几天，甚至一到两天就要出一个结果。当时业务各方面的提升空间都比较大，在这样的环境下，A/B 测试起到了关键的作用，但还是单纯工程师使用的工具。

• 后来，随着需求的增多，功能也在不断丰富完善。同时，A/B 测试需要提升在业务上的易用性，工具形式无法满足。于是在 16 年，我们开始重构 A/B 测试，以产品的形式来提供更便捷优化和标准的服务。A/B 测试也从一个验证工具变成了一个产品，内部命名为 Libra，寓意为客观。这是我们数据平台的第一款自研产品。这个阶段，Libra 的能力也有了较大发展。与此同时，业务场景也更丰富，接入了广告、推送等场景，同时互娱、搜索业务全面接入。访问高涨，测试总数从之前 1w，直接飞升到了 10w。

• 随着业务形态不断丰富，我们也需要提供更多场景化的支持和深入。除了基础产品功能之外，我们近两年更多追求的是效率和场景的覆盖，还提供更多场景化模板和解决方案，降低使用门槛。比如，我们现在也支持运营类的一些场景，让小白用户也能自助使用。

刚刚讲的是原始阶段，我们通过不断 A/B 测试，小成本快速奔跑快速试错的方式，来支撑业务快速迭代。

字节的业务发展非常快，而数据量的增长更快。16 年的时候，我们每天处理的数据量大概是 200TB。去年，我们日处理数据量已经达到 1500PB，数据平台日新增数据 40PB。

这是我们面临的另外一个非常大而艰巨的挑战。在之前数据量小的时候，业务看数据做分析，能够很快的产出，但大一万倍的时候呢？相信各位同行都知道，数据量每上升一个量级，对架构都有新的挑战，何况是好几个量级。

为了解决数据量和分析效率的问题，我们在引擎层面做过很多探索，当然也有一些曲折的地方。比如在 OLAP 引擎上，我们尝试过 Kylin、Druid、Spark。

比如，一开始我们选了 Kylin，它的优点是响应速度毫秒级别，能解决查询响应慢的问题，但需要预聚合，存在维度组合爆炸带来的计算存储量浪费，同时存在需要提前定义、分析灵活度不足等问题。之后，我们又尝试通过 Spark 来解决，但查询速度又不够极致。

后来我们开始反思，现有的查询引擎是否能持续支撑后面的高速发展？我们有哪些根本性的需求，应该通过什么样的技术来满足？

结论是，我们有几个根本性需求：首先，能够处理海量数据，具有高度可扩展性。其次，要有超高性能，秒级响应。然后，分析模式具有高灵活自主性，能够基于明细数据来分析，而非聚合数据。在这些基础上，还要考虑二次开发、集成的便利性、可运维性、易用性等等。

最终，我们确认 ClickHouse 作为最终使用的 OLAP 查询引擎，它在满足我们最根本诉求时，还具有突出的优势。我们也在开源版本上不断迭代，弥补了它的一些不足，也进一步强化了优势。

在确定 ClickHouse 之后，我们也经历了三个阶段的迭代演进：

• 第一阶段，要在生产环境中大规模使用，首先解决的就是可用和稳定。我们在这个阶段，主要做了高可用引擎和稳定性优化，增强运维能力。此时，我们主要在广告和用户增长业务上提供服务。

• 在可用性和稳定性达到 SLA 后，我们进行了数据分析架构统一，把之前零散异构的分析架构做了统一。这本质上是基础设施的复用，也是中台化理念的一种体现。所以，我们能在这技术栈上搭建各种面向场景化的应用，比如 CDP 等。

• 再之后，我们把重点放在了提升资源利用率、降低运维成本和提升数据的实时性上。在这个阶段，我们发布了自己的云原生版本，叫做 ByteHouse，提供了存储计算独立扩缩容的能力，也面向实时数仓做了很多优化，运维的友好型大幅提升。

目前，ByteHouse 字节内部数据分析服务超过了 2.5 万个节点，单集群最大规模可以达到 2400 个节点左右，从业务上来看，在字节内部支撑了超过 80% 的业务分析应用。也正是因为经过了字节内部的磨炼，我们去年才有信心将 ByteHouse 对外部企业开放提供服务。

那么，ByteHouse 的核心能力有哪些呢？

• 第一，实时分析场景。在海量数据场景下，我们可以支持真正的实时数据分析。单集群层面，可以在复杂业务模型情况下，每秒钟数据实时写入的吞吐量可以达到千万级别，能够实现极致的 time-to insight 体验。

• 第二，架构下面实现了存储和计算的分离，计算节点可以弹性伸缩，更灵活且有效地利用资源，从而降低使用成本。这样在做集群规划的时候可以把它们两个完成解耦开。

• 第三，不同业务部门、不同业务用户可以针对性申请资源，做到多级资源隔离，以提升资源利用率。

• 第四，实现 OLAPaaS，借助云上全托管服务，支持服务随时启停，即付即用。

数据平台关键词：数据 BP、0987、分布式治理

度过了前两个阶段之后，我们再来看看，到了平台阶段，我们又有什么样的困难和解法？

前面已经提到过，字节拥有非常多元迥异的业务线形态，它们带来了很异构的数据和不同的场景。作为数据平台，之前的经验还有没有用？要如何复用起来？这么多不同的业务，怎么更敏捷、更深入得支持好？数据质量要怎么保障？成本可以如何进一步优化？这个时候，我们面临的挑战，不能只是单纯依靠技术层面的优化创新来解决了。

首先，为了解决更敏捷深入支持和驱动业务发展的问题，我们从 HRBP 里获取了灵感，建立了数据 BP，探索了“中台能力 + 数据 BP”的模式。

如何理解呢？我们可以用一个生活中的场景来类比——中央厨房和餐厅。中央厨房通过采摘或者购入食材，进行一系列复杂而标准化的加工，最终为各餐厅提供标准化的成品或者半成品的食物。而餐厅则可以根据自己的用户需要，通过煎炸烹煮各种方式将这些食物组合加工形成一道道的菜，直接供客户食用。这个中央厨房就相当于我们的中台，而这些餐厅则是我们的数据 BP，依据不同业务特点，将“中央厨房”提供的各种能力有机地形成对应的数据解决方案。

这样做有什么好处呢？具体有三点：

1. BP 作为数据平台与业务的桥梁，对业务直接输出平台已沉淀的能力，把业务场景方向输出回中台建设，实现能力的动态互哺。

2. 多元业务线的支撑可沉淀出不同业务类型，对不同业务阶段的方法论和经验进行更强大敏捷的泛化复用。

3. 以明确的目标为导向，可量化可扩展的服务标准。

举个例子，Pico 是 21 年下半年刚并入字节的一个 VR 业务产品，在并入后不久我们就开始着手对这条业务线的支持。对我们来说，这是一个全新的业务形态，该怎么做呢？

总的来说，分为几步走：首先，数据 BP 团队先去了解业务形态，梳理出目前的数据状况以及痛点诉求。整理技术方案，将基础数据快速接入，同时进行历史数据迁移；基础数据接入之后，业务就能直接在字节数据平台的体系中使用各种数据建设和数据分析应用产品。

有了 BP 机制和之前沉淀的中台能力，我们在 3 周内就完成了数据接入工作。数据中台的这些产品体系，从 Pico 业务方的感知来说，就是「即插即用」，可以直接在字节数据中台产品上做数据开发、数据管理、行为分析以及搭建业务数据报表等。

在这之前，Pico 有专职同学进行报表开发，3 周之后，这个工作已经完全可以通过产品实现，也把对应同学从繁重的报表开发中解放出来。整体看，这个效率还是非常高的。

除了敏捷之外，数据 BP 也提出了非常严苛的一套服务衡量标准。相信很多做数据的同行都认可数据价值很大，但数据研发的工作价值和能力水平要怎么体现出来？这是困扰大家的一个问题。对于字节来说，我们还是一家数据驱动的公司，也是最大程度上追求量化客观。

所以，我们还是总结了一套服务评估体系，我们称之为“0987”：

• 0 代表稳定性，即产生数据是否稳定。通常，SLA 破线的故障数要清零。

• 9 代表需求满足程度。我们要满足 90% 的业务数据需求。

• 8 代表数仓构建情况，即数仓完善度。我们要看是否可以满足分析师查询覆盖率达到 80%，就是分析师查询日常数据都可以找到数据。（需求满足程度和数仓完善度都不追求 100%，因为灵活发展的业务中总有特别长尾、临时的一次性分析查询需求。）

• 7 代表用户满意度。通过 NPS 看服务是否满意，我们的目标是 70%，对于 NPS 熟悉的同学知道这在业内是比较高的指标。

整体看，这四个指标的标准都足够高，也刻画了不同的侧面。如果达到，我们就认为对业务提供了高水准的数据服务。

刚刚说，业务多元发展后，我们是通过数据 BP+ 中台能力的模式，来更敏捷、更深入地支持业务。但是所有做数据的人都会遇到的一个问题：数据治理。

关于数据治理，业内有很多定义，在不同业务阶段的实施优先级也与路径不同。从我们的实践经验出发，有这么几个要点：坚持业务第一、优先稳定性建设、保障数据质量、强调数据安全、重视成本优化。

我们的数据治理过程，也经历了从运动式到分布式的迭代。

运动式，相信大家都能理解，就是以项目的形式成立治理委员会，自顶向下的形式来解决数据治理问题。这个模式在前期非常有效，能够很好地打造标杆案例，总结出实践经验，但成本比较高。

字节有大量的业务，委员会很难集中统一治理每个业务，同时每个业务的发展不一样，也需要具备一定灵活性。因此，我们提出了“分布式自治”的概念，也就是说，各个业务可以按照自己的情况进行治理，通过循环迭代，随着业务增长把数据治理提升到一个高水位，而不是上来之后强制按统一模式去做。

那么，分布式治理的核心是什么呢？

首先，一定有组织问题。组织需要构建一个更高效的治理模式，这体现在治理委员上，不应该是中心制的什么都管理，而是要核心解决各种规格和规范问题、多团队协作且无法达成共识时做决策。当大家有问题的时候，这个治理委员会就会发挥作用。我们也希望业务能发挥主观能动性，将治理工作日常化。

其次，就像刚才讲的，治理首先要坚持业务第一，明确是为什么而治理。治理一定要为业务服务、对业务造成最小的打扰，而不是治理同学不考虑业务情况，强制让业务按自己的要求来治理，造成业务的过度抵触。减小对业务节奏打扰的核心在于，让业务自己去发现问题，并且愿意去做治理的事情。我们可以通过产品能力，给业务更全景的视图 & 线索来做到这一点。

此外，在产品设计上，治理能力要分拆出来。不同阶段的业务，可以根据实际情况自由选择最核心需要治理的部分，并去解决问题。

最后，通过产品工具提供最高效的执行效率。如何提供最高效的执行效率呢？治理里面有两个关键点：专家经验、系统智能。系统智能比较好理解，比如元数据自动分析，专家经验是指各个团队沉淀下来的治理相关经验。成熟团队可以沉淀很多专家经验到产品上，还不成熟的团队就可以借鉴参考，进而构建自己的方案。

通过这些方式，可以把治理问题从高度依赖中心化组织决策，变成一个全集团各个业务能够分头治理的事情。从而，我们也跟业务达成一个比较好的协作关系。

以稳定性 SLA 为例，看看我们是如何解决最核心的链路稳定问题的。

举个例子，我们有一个治理产品提供的是 SLA 治理能力，也就是提供“稳定性保障”，比如说任务是否每天 6 点产出了，如果没有就是一个故障。

这个问题的核心是解决全链路稳定性问题。对于特别小的公司来说，这个事情很好解决，大家拉个群说下就可以了。但对于体量大、业务复杂的公司来说，这就没有那么容易了。字节拉过最长的链路，一个要 6 点产出的任务，上游涉及到几十个团队，你拉几十个人的群去协商的过程是极其费力的，而且协商之后也不一定能完全确保稳定。所以，我们通过产品构建整个全链路 SLA 保障，对整个闭环进行控制，核心有以下两点：

1. 业务可以按需在系统里面进行申报。当业务表示我这个东西很重要，那就先申报，系统会协助完成申报后的对齐工作。例如，申报 6 点，链路上所有人都要对齐。产品可以帮助「找到人」「找对人」「提供建议」「提供催办 / 预警 / 监督」。更具体地，如果以前历史记录证明你完全可以做到这个事情，就会自动签署。通过一系列类似机制，之前可能需要几天、几周，甚至更长的对齐过程，变成一天之内可以解决的过程。

2. 全部签署之后，剩下的问题全部交给系统。系统会自动调整优先级、做资源倾斜，确保签署任务可以及时完。出现故障后也可以很方便地 review 相关的全链路流程。这样一段时间的不断迭代，我们就可以实现整个业务需要的 SLA 的保障。

实践过程中，我们仅仅用了一年的时间就完成了字节内所有业务的 SLA 全链路保障，这比调研过的其他企业要快上一些。

前面这些，基本上涵盖了我们从最初比较贫瘠、被各种问题追着跑，到逐步解决问题，并发展成现在数据平台的阶段。

换个角度看，如果把字节的各个业务线看成一个个公司，我们实际已经对很多不同类型的公司提供过高水准的数据解决方案和服务。所以我们也开始考虑，这些能力是否可以面向更多外部企业提供。

在通过火山引擎对外部企业提供服务时，我们会遇到很多此前没有遇到的问题。我列了一些比较尖锐而直接挑战，比如：

• 我没有那么大体量的数据，你们 ByteHouse 再快再稳，我用不上这么高规格的产品技术。

• 你们产品听起来很强大，但你们人才密度要比我们公司大，万一产品我们不会用怎么办？

• 我们的业务就是很单一，我为什么需要中台？

• 产品有点贵，算一算我不如直接招几个程序员来管理更方便

• 字节的这些经验，我们要怎么用？

事实上，这些问题都有一定的道理，但也有一定的片面性和局限性。

比如没有大体量数据的问题，我们相信，如果业务要持续发展且需要促进业务不断增长，那么企业对数据的要求只会越来越高，数据量也会越来越大，正如我们所经历过的一样。其次，数据量只是其中一个维度，字节近年来孵化的很多新业务一开始的量也不大，但都在初期就享受到了这些高水准的数据产品和服务能力，对业务发展有很大的助力。由于支持过不同体量的业务，我们也有能力提供非常高的适配性，例如 ByteHouse 的弹性伸缩能让大家在选择时更灵活，兼顾不同的数据体量。

那针对我们如何更适配企业自身，我们也在做一些努力：

1. 统一化——我们坚持内外部统一用同一套产品技术体系。简单来说，抖音能用到什么样的数据产品技术，外部的企业就可以用到相同的技术。

2. 平民化——即数据平民化、降低使用门槛，让更多人不需要太高的能力和条件也能自助使用这套产品技术。

3. 场景化——也就是更契合业务实际场景，提供更具有价值的解决方案。

举个例子，一开始提到的 A/B 测试，我们在对外的时候发现，很多企业并没有像字节这么多的专业分析同学来设计实验、分析实验结果。所以我们在对外的产品设计中，就会把这部分做得更易上手。同时，我们也会提供场景化模板，比如广告营销的一些场景，包括素材投放对比、DMP 投放等等。

再比如，可视化实验支持直接在页面上修改站点的元素，比如文案、图片、元素的颜色比、字体字号、布局位置，甚至我想新增或者是删除一个元素，不需要跟设计和研发反复沟通确认排期，非常适合 Web 或者是 H5 这样的推广活动页做 UI 的调整。还可以做个性化推送实验，与部分推送平台打通后，针对推送时机、推送通道、标题、内容文案、提醒方式都可以做实验。

通过提供这样的场景化模板，很多实验都能在不需要研发介入的情况下快速开启和分析。这对用户非常友好，没有太强专业背景的人也可以做很多数据驱动的实验和判断。

以上就是字节数据平台过去九年的一些实践经验和演进思路。

数据平台未来会更开放、更智能

未来，我们除了继续秉持业务发展驱动演进之外，也会有两个投入方向：一是开放，二是智能。

过去，我们基本上是按照使用“开源→基于开源二次开发→自研”这个路径发展，最开始追求解决业务问题，开源提供了很多不错的基础方案。

在使用过程中，随着业务复杂度的增加，我们在可扩展性，易用性，垂直定制优化等方向遇到瓶颈，所以就会有基于开源做二次开发，并将一些具体的改动反馈给开源社区。

如果有一些系统，开源社区也没有好的选择，我们就会做自研。我们的技术构建受益于开源，所以目前也已经考虑把一些比较成熟的自研系统开源出来，回馈更广泛的开发者和社区。数据平台内部在积极的推进中，大家可以期待一下。