名字是AB测试定的字节跳动用九年时间打造出了怎样的数据平台今日头条 (名字测试abo性别和信息素)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如何应对发展速度的挑战

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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