开通VIP，畅享免费电子书等14项超值服
首页
好书
留言交流
下载APP
联系客服
2022.01.08
“规模尺度每增大十倍，很多架构设计点都需要再重新调整”。
面对个性化、多样化数据，以及企业内部的数据孤岛和业务孤岛，如果有一套能够处理海量数据的基础设施，那么在很大程度上可以挖掘并分析出对业务发展有价值的信息，从而帮助企业更快地作出数据驱动的决策，更快地推出适应用户/客户需求的产品。
这样的规模在业界也十分罕见，为了应对大规模的数据量，字节跳动数据平台团队没有采用传统的数据中台模式，而采用了“中台+BP制”模式，避免中台脱离业务需求。BP机制是一种创新，类似于HRBP，统一管理调配各个业务中的任务。相对于“纯中台制”，数据BP制的好处是更紧贴业务支持，规避了中台容易脱离业务需求、造轮子自嗨的风险。相对于“纯BU制”，最大的好处则是杠杆率高，平台是容易赋能的。
在策划2022年3月24-25日北京ArchSummit全球架构师峰会之初，我采访了字节跳动数据平台负责人罗旋，请他来讲讲字节跳动数据平台建设的历程和技术细节。罗旋在2014年加入字节跳动，从零开始组建大数据平台，带领团队搭建了包括数据采集、建设、治理、应用的全链路平台产品。倡导用数据驱动业务，以数据BP模式，敏捷支持了今日头条、抖音、西瓜视频、朝夕光年等各大业务线。在大数据的架构、产品、治理、安全隐私、组织设计等方面有丰富实践积累。以下是罗旋的回复内容。
Q：作为字节跳动数据平台的负责人，能否请您回顾一下，数据平台是如何建设的？又经历了怎样的演进过程？每次升级改造的背景是怎样？
罗旋：字节跳动数据平台的建设过程可能跟其他公司不大一样。我们所有的建设和演进逻辑，都是围绕如何能敏捷高效支持业务，促进增长这个目的。所以你会发现，从平台演进历史中能够看出，我们的优化前提背景，都是业务高速发展下，我们需要用什么样的能力，来支撑和驱动持续增长。
自2014年至今，大致分为以下几个阶段：
在2015-2016年间，业务快速发展，需要有更多报表、指标，和更灵活的分析能力。2015年今日头条的日活已经过千万了，数据量增大，对引擎的处理能力提出了更高要求，也开始考虑时效性，交互性等问题，此时我们采用Spark和Storm来进行数据处理。
到了2017年，以抖音为代表的业务数据量膨胀，不断挑战我们的能力边界。成长太快带来的问题很明显，一方面是经常出现资源到位的速度慢于业务增长，缺机器、机架位甚至机房。我们很多时候对数据链路各环节进行优化处理，不只是因为成本，更多时候是因为资源不够，导致我们必须要做。通过优化来解决数据量和分析效率，成为我们首要突破重点，做了很多选型尝试，如Presto、Kylin、Druid和ClickHouse，也基于这些开源引擎，做了大量二次开发和深度优化。这部分的投入，到今天也还在继续，也让我们在部分引擎如ClickHouse的积累上，相对领先业界。
除了引擎技术之外，我们也开始建立面向业务的数据产品。包括现在已经对外部企业提供服务的Finder（火山引擎增长分析），也是在当年取代了商业版的Amplitude，开始覆盖公司全部业务线。我们当时做过一版测算，按全产品线计算，每年可以给公司节省数亿的开销，如果按现在的数据体量，就要更多得多了。同时期开始投入的，也包括数据开发平台、元数据管理、任务依赖调度等核心平台能力。
公司的业务形态在这个时期，也开始变得丰富，有了抖音、火山小视频、西瓜等等，也就开始产生了中台化诉求。
到了2018、2019年，字节新业务的产生速度，又明显加快了。作为一个中台团队，如何快速高效的支持这些不断产生的、类型又越来越多样化的业务，成为一个很重要的命题。
我们在组织层面做了一些创新，设置了数据BP机制。BP全称是BusinessPartner，类似于HRBP，组织形式上是集中式的，可以统一管理调配，执行上分布式到各个业务，解决业务问题。这种组织方式的优势在于，尽管BP团队向上支撑了不同类型的业务线，但其实向下兼容了我们平台底层的各项能力，具备相似的技能栈，对工具引擎的学习和使用是高效且顺滑的。
作为数据平台能力的解决方案提供方，数据BP同学在组织上都汇报在数据平台，统一培养和调度，相互学习经验的角度，对中台能力也保证足够的熟悉度，以便根据不同业务的特性，灵活组合，提供综合性的数据解决方案，也保证了复用性，不轻易重复造轮子。在具体工作时，他们会扑在不同的业务线上，跟业务同学坐在一起，把自己视为业务线的一部分，保障与业务一起成功。
数据产品层面，我们开始越来越注重“产品化”，注重体验和降低门槛，而不仅仅是基础能力，这样才能让公司内更广泛的角色群体，都能用数据驱动的理念工作。我们的ABI产品“风神”就是这个时候推出的，这也成了字节几乎全员使用的一款数据产品。内部流传的“A/B是一种信仰，风神是一种习惯”，也是从这个时期开始广为人知。
2020年时，我们已经有两大块服务对象了。一个是对字节跳动的各业务线，以数据BP为接口，提供数据服务；另一个是面向外部企业，为外部客户创造价值。
在字节跳动内部，当支持了越来越多产品线之后，我们针对数据BP这种模式，提出了一个更量化的服务体系标准，叫做“0987”。这四个数字分别指的是：稳定性SLA核心指标要达到0个事故，需求满足率要达到90%，数仓构建覆盖80%的分析需求，同时用户满意度达到70%。服务字节内部业务，我们是按照这个高标准来要求自己，同时这也是一种自监管的机制，能够有效的防止自嗨，脱离业务需求和价值。
在外部客户方面，我们其实从2019年就开始探索ToB市场。到了2020年，ToB升级成了字节跳动公司的战略，公司注册成立了“北京火山引擎科技有限公司”。火山引擎是字节跳动旗下的企业级技术服务平台，数据平台也作为其中重要的大数据板块，持续加大投入。我们将内部支持服务比较好的产品和经验，封装成数据套件，通过火山引擎对外提供服务。目前，我们已经推出了技术引擎和营销增长两大套件，也有了一些不错的标杆客户。同时我们也在思考数据BP的解决方案能力、经验和方法论，是否能帮助到外部客户，让他们也享受到和抖音一样的数据服务级别，开始在这方面做一些尝试。
Q：正如您刚刚所提，平台架构并不是一开始就确定的。我们知道，架构持续升级的过程很少能一帆风顺，字节数据平台在架构演进的过程中有没有走过一些弯路？能否举个例子？
罗旋：也不算弯路吧，而是在技术演进的路上，需要解决什么样的核心问题，随着问题的变化，解法很可能也会改变。经历过架构演进升级的人都会知道，规模尺度每增大十倍，很多架构设计点都需要调整。另外由于是给飞奔的火车换轮子，有时也需要在资源、ROI上做一些权衡。举个例子，我们的用户行为分析产品Finder所使用的底层查询引擎，就经历过比较大的调整。
在一开始探索的时候，我们在2016年底做了技术选型，考虑了查询速度和性能、稳定性等因素，我们认为Kylin更符合那个时候的需求。它的优点是“快”，能达到毫秒级别，但是数据需要预聚合，且计算量大，维度和度量也都需要提前定义。当时我们采取了一些方法，暂时缓解了这些问题。但随着产品功能扩展到留存和转化分析，这套架构就难以做到交互式响应了。
为了提供更多灵活性，我们又快速用Spark做了一些尝试，保留原始数据、做字典编码、按用户ID分片、分层缓存等等。但考虑到业务发展速度需要追求对资源和性能都更极致的方案，通过一系列的测试验证之后，我们选择了ClickHouse来作为基础的查询引擎。ClickHouse当时还远不如现在流行，但我们认为它在类似场景的性能优化上做得比较极致，功能精简的同时实现质量高，是一个非常好的基础。在满足实际业务场景的过程中，我们也做了大量的深度优化和定制修改。目前我们拥有国内最大的ClickHouse集群，节点总数超过15000个、管理数据量超过600PB、最大单集群规模在2400余个节点，每天支撑着数万员工的交互式数据分析。
今年，我们也推出了企业版的ClickHouse，叫ByteHouse，除自研表引擎、扩展数据类型、冷热数据分离等核心能力升级之外，数据实时写入能力相较原生ClickHouse也提升了两倍以上。
Q：这个架构目前支撑了多大量级的数据规模？大规模处理遇到了哪些挑战？又是如何解决的？
罗旋：数据平台管理的总数据量，几年前就已经超过EB级别了，从实时流量的角度，我们在业务日常晚高峰时承载的埋点流量就已超过1亿TPS，有超十万core的单任务需要上千台机器来计算。这样的规模在业界也十分罕见，自然的会带来性能、扩展性、实时性等方面的挑战，前面提到的查询引擎的一些优化，也是由此引发的。再叠加上业务的多样性和复杂度，又会在大规模任务的调度、运维、资源优化、数据治理等维度上，碰到不少挑战。
举个例子，目前我们日均的数据处理作业量在百万级。从任务调度的角度，依赖关系复杂、层次也比较深，为了满足时效性要求，需要在前置依赖就绪的情况下快速触发调度执行。我们通过自研的分布式调度系统，实现了秒级调度能力。同时提供了任务的分级打标机制，结合SLA签署系统，通过多种任务资源控制方式，实现资源最合理的调配，结合优先级权重来保证SLA满足率。也可以根据任务的历史情况，对不合理的任务配置，提出配置优化的告警建议，不然大任务量的运维也很容易成为灾难。
Q：除了规模和性能之外，如何做好数据管理也是另一个不得不正视的问题。尤其是像字节这样业务丰富，数据类型不断扩大的企业，是如何去解决这个问题？
罗旋：我们更习惯叫数据治理，意思类似。当数据体量，多样化程度都很高的时候，这确实是一件特别重要的事情。
整体来说，数据治理是个长期过程，我们自己的实践分为两个阶段：
第一个阶段，针对我们的主营业务，成立了数据治理委员会，以民主集中的方式，做专项的诊断和治理，拿到标杆效果。同时，把在这个过程中形成的最佳治理实践，转化成可复用的架构、流程、产品，来降低治理门槛，以寻求可复制性。
第二个阶段，把第一阶段沉淀下来的中台治理能力，源源不断地赋能给创新业务，实现业务的分布式自治，使其不必都依赖特定团队。这个过程中，也会不断有新的需求反馈，让我们对治理产品持续打磨。
Q：您多次提到敏捷，这是字节数据平台的特性吗？体现在哪些方面？
罗旋：首先字节本身就是个比较敏捷的公司。这对于字节数据平台来说，也算是一个特性，我们追求的是敏捷高效支持业务增长。从几个方面可以体现：
Q：敏捷的其中一个体现是组织敏捷，这和其他的数据平台十分不一样，您能再深入介绍下数据BP的模式吗？
罗旋：BP模式的概念我在上面的问题里已经详述了。相对于“纯中台制”，数据BP制的好处是更紧贴业务支持，我们会坐在业务身边提供服务，并主动要求考核业务对自己的满意度，规避了中台容易脱离业务需求、造轮子自嗨的风险。相对于“纯BU制”，最大的好处则是杠杆率高，平台是容易赋能的。数据BP的同学并不是自己在战斗，他背后有很强大的团队，有很强的平台产品工具支持。业务发展曲线陡峭，或战略优先级变化时，数据BP的同学能非常快地协调资源。BP积累的业务支持经验，也更容易进行跨产品线的交流沉淀，最终体现在平台产品和方法论的积累上。
推行数据BP制的出发点，一方面是当业务体量越来越大，仅用通用的平台产品技术支持已经不能够满足需求了，需要再深入结合业务特性，提供综合性的解决方案和实施落地的能力；另一方面也是希望在纯中台化和纯业务闭环之间取长补短，在追求复用的同时，最大程度的提升组织效率。从我们几年下来的实践效果看，还是非常好的，虽然还是会有问题出现，但各业务方基本都是认可的。最近我们发现几十个业务的整体NPS已经达到了70，无论是从公司内还是从业界来看，都算是一个比较高的值。
Q：上面提到了很多能力特性，能否再总结介绍一下目前字节跳动数据平台的架构？
罗旋：从比较粗的粒度看，数据平台可以分成两大块，一块是平台能力层，另一块是解决方案层。
平台能力层主要是我们的通用产品技术能力部分，包括：
解决方案层，就是我们的数据BP模式。一方面数据BP团队，依靠我们的平台能力对不同的业务提供数据解决方案；另一方面，数据BP团队也能从业务中获取到更多发展诉求，进而使得我们的平台能力不断迭代并得以优化。
罗旋：当然，技术最终要通过业务来发挥价值，也只有复杂的业务场景，才会带来足够的技术挑战。
举一个特殊的场景吧。2021年抖音春晚活动中，流量洪峰达到日常的数倍，在这个场景下，我们需要提供各种实时指标数据，既要用于内部指导活动策略的实时更新，比如下个时段红包投放量的预算决策，也要给外部，比如把实时的春晚战报数据给到春晚现场和各媒体。这在实时性、稳定性、指标精确度、架构容错能力都有非常高的要求，而整个春晚项目从立项到上线只有27天，也增加了额外的难度和压力。
然后，在实时指标方面，我们也已经沉淀出了一套比较成熟的，以Flink实时计算引擎与ByteHouse、LAS等分析引擎相结合的实时数仓解决方案。针对春晚活动的实时决策和战报需求，我们使用了两套不同的技术架构，一套是基于Flink的计算架构，流式计算出最终指标，另外一套基于ByteHouse的存储架构，在存储层实时写入明细数据，查询时聚合出最终指标。同时两种架构也都做了双机房双链路冗余灾备。
Q：字节在数据应用上有很多自研的产品，但在大数据基础架构上的自研方向是怎么考虑的？
罗旋：从演进路径看，基本是三个阶段：1.使用开源；2.基于开源二次开发；3.自研。
最开始追求解决业务问题，开源社区提供了很多不错的基础方案，比如SparkSQL、ClickHouse、Airflow等等，我们会先尝试直接使用，也就是阶段1。在使用的过程中，随着业务复杂度的增加，会在可扩展性、易用性、垂直定制优化等方向遇到瓶颈，此时我们会做一轮技术判断，如果开源社区在核心部分、中长期跟我们预期一致，会走阶段2，例如SparkSQL、ClickHouse等。否则会直接走阶段3，例如数据任务的调度系统等。而一些系统，开源社区本来也没有好的选择，我们就会从一开始直接走阶段3，比如A/BTest系统。走2的系统改动太多，逐渐积累下来，有时也会趋近于3。
从现状来看，我们是一个2+3的混合状态。在过程中，我们也向开源社区反馈了一些具体的改动。目前也在考虑把一些比较成熟的自研系统整体开源出来，回馈更广泛的开发者。内部在积极的讨论中，可以期待一下。
Q：未来在ToB的规划，以及与字节内部技术演进的协同方式是怎样的？
罗旋：大的思路上，我们坚持内外部统一，用同一套产品技术体系来服务公司内外各业务。这样有几个好处，一是吃自己的狗粮，用内部的大体量和多元化场景来打磨产品技术，给外部客户提供更成熟的产品，也是帮助了字节跳动内部成功的产品和技术。
二是服务内部时，视野更宽广长期，更有外部视角。比如，在早期就去考虑外部市场对这一技术的需求有多大，如果仅仅是个定制化的小场景，那就小投入加外部采购来解决；如果有广泛需求，那就大投入，做到业界领先。
三是从成本效率来说也需要做到更优，能够复用资源和经验。从具体执行路径来说，产品在使用过程中会存在一些版本差异，但更多是由于场景不同，发展阶段不同导致的，核心并不是从内部和外部客户来区分，例如不同规模大小的业务带来的技术形态区别，操作易用性和功能复杂度的权衡等等，有点类似于很多软件的Pro和Lite版的感觉。