博客 字节跳动数据平台为什么不选“纯中台制”

字节跳动数据平台为什么不选“纯中台制”

   鹤袋鼠   发表于 2022-01-04 16:30  687  0

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

字节跳动数据平台团队根据业务的需要,用七年时间研发并逐渐迭代出了一套数据平台,该平台管理的总数据量在几年前就已经超过了 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 :最后想了解您目前都关注哪些技术方向?未来的大数据开发者们应该具备哪些能力?

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

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

0条评论
社区公告
  • 大数据领域最专业的产品&技术交流社区,专注于探讨与分享大数据领域有趣又火热的信息,专业又专注的数据人园地

最新活动更多
微信扫码获取数字化转型资料
钉钉扫码加入技术交流群