首次揭秘，字节跳动数据平台为什么不选“纯中台制”

嘉宾 | 罗旋

编辑 | 薛梁

“规模尺度每增大十倍，很多架构设计点都需要再重新调整”。

面对个性化、多样化数据，以及企业内部的数据孤岛和业务孤岛，如果有一套能够处理海量数据的基础设施，那么在很大程度上可以挖掘并分析出对业务发展有价值的信息，从而帮助企业更快地作出数据驱动的决策，更快地推出适应用户 / 客户需求的产品。

字节跳动数据平台团队根据业务的需要，用七年时间研发并逐渐迭代出了一套数据平台，该平台管理的总数据量在几年前就已经超过了 EB 级别，在业务日常晚高峰时承载的埋点流量就已超过 1 亿 TPS，有超十万 core 的单任务需要上千台机器来计算。

这样的规模在业界也十分罕见，为了应对大规模的数据量，字节跳动数据平台团队没有采用传统的数据中台模式，而采用了“中台 +BP 制”模式，避免中台脱离业务需求。BP 机制是一种创新，类似于 HRBP，统一管理调配各个业务中的任务。相对于“纯中台制”，数据 BP 制的好处是更紧贴业务支持，规避了中台容易脱离业务需求、造轮子自嗨的风险。相对于“纯 BU 制”，最大的好处则是杠杆率高，平台是容易赋能的。

在策划 2022 年 3 月 24-25 日北京 ArchSummit 全球架构师峰会之初，我采访了字节跳动数据平台负责人罗旋，请他来讲讲字节跳动数据平台建设的历程和技术细节。罗旋在 2014 年加入字节跳动，从零开始组建大数据平台，带领团队搭建了包括数据采集、建设、治理、应用的全链路平台产品。倡导用数据驱动业务，以数据 BP 模式，敏捷支持了今日头条、抖音、西瓜视频、朝夕光年等各大业务线。在大数据的架构、产品、治理、安全隐私、组织设计等方面有丰富实践积累。以下是罗旋的回复内容。

 InfoQ ：作为字节跳动数据平台的负责人，能否请您回顾一下，数据平台是如何建设的？又经历了怎样的演进过程？每次升级改造的背景是怎样？

罗旋：字节跳动数据平台的建设过程可能跟其他公司不大一样。我们所有的建设和演进逻辑，都是围绕如何能敏捷高效支持业务，促进增长这个目的。所以你会发现，从平台演进历史中能够看出，我们的优化前提背景，都是业务高速发展下，我们需要用什么样的能力，来支撑和驱动持续增长。

自 2014 年至今，大致分为以下几个阶段：

• 原始阶段：Hive+ 邮件报表，重度使用 A/B 测试（2014）

我是 2014 年加入字节的，只叙述 14 年之后的发展情况。在此之前，也只有过一两工程师，兼职参与过相关事情，所以基本还是个从零开始的状态。刚加入字节时，只有一个 Hive 和最基础的报表，仅包括 DAU、时长等，报表仅以邮件形式来发送，是非常原始的一个状态。不过很有意思的是，在这个时候，我们已经开始重度使用 A/B 测试了，这是我们最早相对成熟的一个系统，相信跟绝大多数公司的发展顺序都不同，因为在那个阶段，我们认为最重要的事，就是让业务能够量化度量，并以非常快速试错的方式来迭代。

• 基础能力建设时期：自建产品快速取代商业化产品

在 2015-2016 年间，业务快速发展，需要有更多报表、指标，和更灵活的分析能力。2015 年今日头条的日活已经过千万了，数据量增大，对引擎的处理能力提出了更高要求，也开始考虑时效性，交互性等问题，此时我们采用 Spark 和 Storm 来进行数据处理。

到了 2017 年，以抖音为代表的业务数据量膨胀，不断挑战我们的能力边界。成长太快带来的问题很明显，一方面是经常出现资源到位的速度慢于业务增长，缺机器、机架位甚至机房。我们很多时候对数据链路各环节进行优化处理，不只是因为成本，更多时候是因为资源不够，导致我们必须要做。通过优化来解决数据量和分析效率，成为我们首要突破重点，做了很多选型尝试，如 Presto、Kylin、Druid 和 ClickHouse，也基于这些开源引擎，做了大量二次开发和深度优化。这部分的投入，到今天也还在继续，也让我们在部分引擎如 ClickHouse 的积累上，相对领先业界。

除了引擎技术之外，我们也开始建立面向业务的数据产品。包括现在已经对外部企业提供服务的 Finder（火山引擎增长分析），也是在当年取代了商业版的 Amplitude，开始覆盖公司全部业务线。我们当时做过一版测算，按全产品线计算，每年可以给公司节省数亿的开销，如果按现在的数据体量，就要更多得多了。同时期开始投入的，也包括数据开发平台、元数据管理、任务依赖调度等核心平台能力。

公司的业务形态在这个时期，也开始变得丰富，有了抖音、火山小视频、西瓜等等，也就开始产生了中台化诉求。

• 产品化和组织成型：架构组织创新，平台能力持续升级

到了 2018、2019 年，字节新业务的产生速度，又明显加快了。作为一个中台团队，如何快速高效的支持这些不断产生的、类型又越来越多样化的业务，成为一个很重要的命题。

我们在组织层面做了一些创新，设置了数据 BP 机制。BP 全称是 Business Partner，类似于 HRBP，组织形式上是集中式的，可以统一管理调配，执行上分布式到各个业务，解决业务问题。这种组织方式的优势在于，尽管 BP 团队向上支撑了不同类型的业务线，但其实向下兼容了我们平台底层的各项能力，具备相似的技能栈，对工具引擎的学习和使用是高效且顺滑的。

作为数据平台能力的解决方案提供方，数据 BP 同学在组织上都汇报在数据平台，统一培养和调度，相互学习经验的角度，对中台能力也保证足够的熟悉度，以便根据不同业务的特性，灵活组合，提供综合性的数据解决方案，也保证了复用性，不轻易重复造轮子。在具体工作时，他们会扑在不同的业务线上，跟业务同学坐在一起，把自己视为业务线的一部分，保障与业务一起成功。

数据产品层面，我们开始越来越注重“产品化”，注重体验和降低门槛，而不仅仅是基础能力，这样才能让公司内更广泛的角色群体，都能用数据驱动的理念工作。我们的 ABI 产品“风神”就是这个时候推出的，这也成了字节几乎全员使用的一款数据产品。内部流传的“A/B 是一种信仰，风神是一种习惯”，也是从这个时期开始广为人知。

• ToB 服务阶段：“0987”量化数据服务标准，面向外部企业创造价值

2020 年时，我们已经有两大块服务对象了。一个是对字节跳动的各业务线，以数据 BP 为接口，提供数据服务；另一个是面向外部企业，为外部客户创造价值。

在字节跳动内部，当支持了越来越多产品线之后，我们针对数据 BP 这种模式，提出了一个更量化的服务体系标准，叫做“0987”。这四个数字分别指的是：稳定性 SLA 核心指标要达到 0 个事故，需求满足率要达到 90%，数仓构建覆盖 80% 的分析需求，同时用户满意度达到 70%。服务字节内部业务，我们是按照这个高标准来要求自己，同时这也是一种自监管的机制，能够有效的防止自嗨，脱离业务需求和价值。

在外部客户方面，我们其实从 2019 年就开始探索 ToB 市场。到了 2020 年，ToB 升级成了字节跳动公司的战略，公司注册成立了“北京火山引擎科技有限公司”。火山引擎是字节跳动旗下的企业级技术服务平台，数据平台也作为其中重要的大数据板块，持续加大投入。我们将内部支持服务比较好的产品和经验，封装成数据套件，通过火山引擎对外提供服务。目前，我们已经推出了技术引擎和营销增长两大套件，也有了一些不错的标杆客户。同时我们也在思考数据 BP 的解决方案能力、经验和方法论，是否能帮助到外部客户，让他们也享受到和抖音一样的数据服务级别，开始在这方面做一些尝试。

 InfoQ ：正如您刚刚所提，平台架构并不是一开始就确定的。我们知道，架构持续升级的过程很少能一帆风顺，字节数据平台在架构演进的过程中有没有走过一些弯路？能否举个例子？

罗旋：也不算弯路吧，而是在技术演进的路上，需要解决什么样的核心问题，随着问题的变化，解法很可能也会改变。经历过架构演进升级的人都会知道，规模尺度每增大十倍，很多架构设计点都需要调整。另外由于是给飞奔的火车换轮子，有时也需要在资源、ROI 上做一些权衡。举个例子，我们的用户行为分析产品 Finder 所使用的底层查询引擎，就经历过比较大的调整。

在一开始探索的时候，我们在 2016 年底做了技术选型，考虑了查询速度和性能、稳定性等因素，我们认为 Kylin 更符合那个时候的需求。它的优点是“快”，能达到毫秒级别，但是数据需要预聚合，且计算量大，维度和度量也都需要提前定义。当时我们采取了一些方法，暂时缓解了这些问题。但随着产品功能扩展到留存和转化分析，这套架构就难以做到交互式响应了。

为了提供更多灵活性，我们又快速用 Spark 做了一些尝试，保留原始数据、做字典编码、按用户 ID 分片、分层缓存等等。但考虑到业务发展速度需要追求对资源和性能都更极致的方案，通过一系列的测试验证之后，我们选择了 ClickHouse 来作为基础的查询引擎。ClickHouse 当时还远不如现在流行，但我们认为它在类似场景的性能优化上做得比较极致，功能精简的同时实现质量高，是一个非常好的基础。在满足实际业务场景的过程中，我们也做了大量的深度优化和定制修改。目前我们拥有国内最大的 ClickHouse 集群，节点总数超过 15000 个、管理数据量超过 600PB、最大单集群规模在 2400 余个节点，每天支撑着数万员工的交互式数据分析。

今年，我们也推出了企业版的 ClickHouse，叫 ByteHouse，除自研表引擎、扩展数据类型、冷热数据分离等核心能力升级之外，数据实时写入能力相较原生 ClickHouse 也提升了两倍以上。

 InfoQ ：这个架构目前支撑了多大量级的数据规模？大规模处理遇到了哪些挑战？又是如何解决的？

罗旋：数据平台管理的总数据量，几年前就已经超过 EB 级别了，从实时流量的角度，我们在业务日常晚高峰时承载的埋点流量就已超过 1 亿 TPS，有超十万 core 的单任务需要上千台机器来计算。这样的规模在业界也十分罕见，自然的会带来性能、扩展性、实时性等方面的挑战，前面提到的查询引擎的一些优化，也是由此引发的。再叠加上业务的多样性和复杂度，又会在大规模任务的调度、运维、资源优化、数据治理等维度上，碰到不少挑战。

举个例子，目前我们日均的数据处理作业量在百万级。从任务调度的角度，依赖关系复杂、层次也比较深，为了满足时效性要求，需要在前置依赖就绪的情况下快速触发调度执行。我们通过自研的分布式调度系统，实现了秒级调度能力。同时提供了任务的分级打标机制，结合 SLA 签署系统，通过多种任务资源控制方式，实现资源最合理的调配，结合优先级权重来保证 SLA 满足率。也可以根据任务的历史情况，对不合理的任务配置，提出配置优化的告警建议，不然大任务量的运维也很容易成为灾难。

 InfoQ ：除了规模和性能之外，如何做好数据管理也是另一个不得不正视的问题。尤其是像字节这样业务丰富，数据类型不断扩大的企业，是如何去解决这个问题？

罗旋：我们更习惯叫数据治理，意思类似。当数据体量，多样化程度都很高的时候，这确实是一件特别重要的事情。

整体来说，数据治理是个长期过程，我们自己的实践分为两个阶段：

第一个阶段，针对我们的主营业务，成立了数据治理委员会，以民主集中的方式，做专项的诊断和治理，拿到标杆效果。同时，把在这个过程中形成的最佳治理实践，转化成可复用的架构、流程、产品，来降低治理门槛，以寻求可复制性。

第二个阶段，把第一阶段沉淀下来的中台治理能力，源源不断地赋能给创新业务，实现业务的分布式自治，使其不必都依赖特定团队。这个过程中，也会不断有新的需求反馈，让我们对治理产品持续打磨。

这套机制现在已经运行得比较稳定，帮助我们实现了比较高的数据治理标准，也达到了更大程度的成本资源节约。由于经历过多种不同类型业务的考验，因此也能保证治理产品和方法论的泛化能力。我们尽量用产品化的方式来降低门槛，让支持不同业务的数据团队能够自治，可以说我们是用一种更敏捷的方式实现数据治理。作为对比，一些公司的做法可能更类似于“一把手工程”，更依赖全程顶层决策推动，一方面这跟公司的文化相关，另外一方面我们也倡导数据平民化的理念，把产品工具做得足够好，让门槛尽可能低。

 InfoQ ：您多次提到敏捷，这是字节数据平台的特性吗？体现在哪些方面？

罗旋：首先字节本身就是个比较敏捷的公司。这对于字节数据平台来说，也算是一个特性，我们追求的是敏捷高效支持业务增长。从几个方面可以体现：

• 组织敏捷：相对于“传统”中台模式，我们的 BP 模式创新，能更高效支持业务。

• 消费敏捷：通过不断升级优化技术引擎，PB 级复杂分析需求可实现秒级响应，数据从产生到可用也能达到秒级，让业务在数据消费环节看数、用数更快。

• 决策敏捷：这是字节典型的 A/B 测试文化，“遇事不决用 A/B”，用客观代替主观，辅助一线快速决策，而不是依靠冗长的层层拍板的办法。这也使得我们的 A/B 产品每天同时进行的测试就达上万场。

• 服务敏捷：字节的业务发展太快，业务模型非常多元化，促使我们必须快速接入和服务好一个新的业务。服务与工具产品深度融合，在高满意度为要求的前提下，我们快速支持一个业务，一般一周时间就可以接起，开始提供基础能力。

• 实施敏捷：这从刚刚提到的分布式数据治理中可见一斑。我们倡导小团队也可快速实施，无需花费大量时间建设配套组织和制度，对业务影响小，适配性强，见效快。

• 迭代敏捷：字节的发展和变化非常之快，对我们的挑战就是要快速迭代以适应各种变化，这也使得我们整体迭代更敏捷。从产品的发展也能看出来，2016 年底我们的行为分析产品还在迭代技术选型，2017 年就能覆盖内部需求替代较成熟的商业化产品了。

 InfoQ ：敏捷的其中一个体现是组织敏捷，这和其他的数据平台十分不一样，您能再深入介绍下数据 BP 的模式吗？

罗旋：BP 模式的概念我在上面的问题里已经详述了。相对于“纯中台制”，数据 BP 制的好处是更紧贴业务支持，我们会坐在业务身边提供服务，并主动要求考核业务对自己的满意度，规避了中台容易脱离业务需求、造轮子自嗨的风险。相对于“纯 BU 制”，最大的好处则是杠杆率高，平台是容易赋能的。数据 BP 的同学并不是自己在战斗，他背后有很强大的团队，有很强的平台产品工具支持。业务发展曲线陡峭，或战略优先级变化时，数据 BP 的同学能非常快地协调资源。BP 积累的业务支持经验，也更容易进行跨产品线的交流沉淀，最终体现在平台产品和方法论的积累上。

推行数据 BP 制的出发点，一方面是当业务体量越来越大，仅用通用的平台产品技术支持已经不能够满足需求了，需要再深入结合业务特性，提供综合性的解决方案和实施落地的能力；另一方面也是希望在纯中台化和纯业务闭环之间取长补短，在追求复用的同时，最大程度的提升组织效率。从我们几年下来的实践效果看，还是非常好的，虽然还是会有问题出现，但各业务方基本都是认可的。最近我们发现几十个业务的整体 NPS 已经达到了 70，无论是从公司内还是从业界来看，都算是一个比较高的值。

 InfoQ ：上面提到了很多能力特性，能否再总结介绍一下目前字节跳动数据平台的架构？

罗旋：从比较粗的粒度看，数据平台可以分成两大块，一块是平台能力层，另一块是解决方案层。

平台能力层主要是我们的通用产品技术能力部分，包括：

• 数据引擎部分，有字节大规模使用的湖仓一体引擎 LAS 和 OLAP 引擎 ByteHouse。其中 ByteHouse 是我们今年 8 月刚对外推出的，性能和规模在国内都比较领先；

• 数据建设部分，主要是 DateLeap，融合了数据的定义、采集、验证、分流、治理等一站式数据开发治理平台；

• 数据应用部分主要分为：

• 面向通用分析需要的产品：ABI（敏捷 BI 产品，内部叫风神）、Finder（行为洞察分析产品，内部名叫 TEA）、Gaia（一款用于数据门户建设的产品，业务可以自助模块化建设门户）、CDP（用户数据平台，内部叫 Mirror，沉淀了各种分析标签）、Tester（A/B 实验平台，内部叫 Libra）
• 面向不同业务场景提供的洞察型产品，如热点宝（内部叫 Pugna，用于不同业务的场景洞察，如抖音热点榜单等）、管理驾驶舱（用于业务管理层监测各种核心指标）以及安全合规的产品等。

解决方案层，就是我们的数据 BP 模式。一方面数据 BP 团队，依靠我们的平台能力对不同的业务提供数据解决方案；另一方面，数据 BP 团队也能从业务中获取到更多发展诉求，进而使得我们的平台能力不断迭代并得以优化。

 InfoQ ：刚刚讲了很多技术的挑战和发展。技术与业务其实是休戚相关，互相促进的。想请您从数据角度来看，你们在赋能业务上，是否遇到过一些极端挑战？可否举个例子说明？

罗旋：当然，技术最终要通过业务来发挥价值，也只有复杂的业务场景，才会带来足够的技术挑战。

举一个特殊的场景吧。2021 年抖音春晚活动中，流量洪峰达到日常的数倍，在这个场景下，我们需要提供各种实时指标数据，既要用于内部指导活动策略的实时更新，比如下个时段红包投放量的预算决策，也要给外部，比如把实时的春晚战报数据给到春晚现场和各媒体。这在实时性、稳定性、指标精确度、架构容错能力都有非常高的要求，而整个春晚项目从立项到上线只有 27 天，也增加了额外的难度和压力。

首先，在流量采集侧，我们有个很好的基础，字节所有流量数据的采集管控，都是在统一的流量平台上。针对春晚红包项目，我们又额外增强了容灾能力，做了三机房容灾预案，并支持一键容灾。针对尖峰流量，我们跟相关团队合作，支持了服务端限流和客户端回避重试策略。为了在不同负载下灵活降级，也支持了埋点抽样和主动降级机制。

然后，在实时指标方面，我们也已经沉淀出了一套比较成熟的，以 Flink 实时计算引擎与 ByteHouse、LAS 等分析引擎相结合的实时数仓解决方案。针对春晚活动的实时决策和战报需求，我们使用了两套不同的技术架构，一套是基于 Flink 的计算架构，流式计算出最终指标，另外一套基于 ByteHouse 的存储架构，在存储层实时写入明细数据，查询时聚合出最终指标。同时两种架构也都做了双机房双链路冗余灾备。

最后，在离线场景下，也需要我们有强大的分级保障和数据治理能力。在业务峰值期，我们需要出让大量的离线资源给在线业务系统，同时又要保障离线数据仓库仍然能按时产出，产品和分析师才能对前一天的活动情况做细致的复盘，来指导下一步动作。这就要求能在几十万张数据表，百万数据处理任务中，灵活的分级调配资源、降级和快速恢复，我们也确实做到了这一点，相关能力都沉淀在 DataLeap 产品中。

 InfoQ ：字节在数据应用上有很多自研的产品，但在大数据基础架构上的自研方向是怎么考虑的？

罗旋：从演进路径看，基本是三个阶段：1. 使用开源；2. 基于开源二次开发；3. 自研。

最开始追求解决业务问题，开源社区提供了很多不错的基础方案，比如 SparkSQL、ClickHouse、Airflow 等等，我们会先尝试直接使用，也就是阶段 1。在使用的过程中，随着业务复杂度的增加，会在可扩展性、易用性、垂直定制优化等方向遇到瓶颈，此时我们会做一轮技术判断，如果开源社区在核心部分、中长期跟我们预期一致，会走阶段 2，例如 SparkSQL、ClickHouse 等。否则会直接走阶段 3，例如数据任务的调度系统等。而一些系统，开源社区本来也没有好的选择，我们就会从一开始直接走阶段 3，比如 A/B Test 系统。走 2 的系统改动太多，逐渐积累下来，有时也会趋近于 3。

从现状来看，我们是一个 2+3 的混合状态。在过程中，我们也向开源社区反馈了一些具体的改动。目前也在考虑把一些比较成熟的自研系统整体开源出来，回馈更广泛的开发者。内部在积极的讨论中，可以期待一下。

 InfoQ ：未来在 ToB 的规划，以及与字节内部技术演进的协同方式是怎样的？

罗旋：大的思路上，我们坚持内外部统一，用同一套产品技术体系来服务公司内外各业务。这样有几个好处，一是吃自己的狗粮，用内部的大体量和多元化场景来打磨产品技术，给外部客户提供更成熟的产品，也是帮助了字节跳动内部成功的产品和技术。

二是服务内部时，视野更宽广长期，更有外部视角。比如，在早期就去考虑外部市场对这一技术的需求有多大，如果仅仅是个定制化的小场景，那就小投入加外部采购来解决；如果有广泛需求，那就大投入，做到业界领先。

三是从成本效率来说也需要做到更优，能够复用资源和经验。从具体执行路径来说，产品在使用过程中会存在一些版本差异，但更多是由于场景不同，发展阶段不同导致的，核心并不是从内部和外部客户来区分，例如不同规模大小的业务带来的技术形态区别，操作易用性和功能复杂度的权衡等等，有点类似于很多软件的 Pro 和 Lite 版的感觉。

 InfoQ ：最后想了解您目前都关注哪些技术方向？未来的大数据开发者们应该具备哪些能力？

罗旋：我目前主要关注的大数据技术方向包括：实时化、智能化以及安全隐私合规。其中，实时化关注的是实时数仓、流批一体等技术；智能化主要围绕智能物化视图、结合机器学习的查询优化器、增强分析智能问答等；在隐私合规上更关注政策趋势带来技术和架构演进趋势，包括敏感数据发现、多方计算、数据本地化、权限优化等。

对于关心未来发展的大数据开发者来说，我觉得首先需要有过硬的计算机基础技术储备，这是通用的能力。具体到大数据领域技术，一个特点是开源组件种类特别多，大数据开发者应该熟悉了解这些开源组件的特性，这也是很好的学习过程；另一个特点是，一定要找到真正有大数据规模的场景和环境来实践学习，因为它跟小数据场景技术是完全不同的、有本质区别的。小数据场景下也体现不出挑战性。在这个基础上，再去关注一些前沿的方向发展。

你也「在看」吗？👇