查看原文
其他

字节跳动基于 DataLeap 的 DataOps 实践

王洋 DataFunSummit
2024-09-10

导读 本文将从数据使用者和开发者的角度,来探讨如何使用 DataOps 的能力,使我们能够更好地管理和使用数据,提高数据研发的效率。

文章将围绕下面五点展开:

1. 字节跳动数据研发所面临的挑战

2. DataOps 理念在字节的具象

3. DataOps 在火山引擎 DataLeap 的产品化方案

4. 规范+产品在字节落地的最佳实践

5. 未来数据研发展望与对外开放

分享嘉宾|王洋 字节跳动 抖音直播数据研发负责人 

编辑整理|马信宏

内容校对|李瑶

出品社区|DataFun


01
字节跳动数据研发所面临的挑战

字节跳动采用中台加数据 BP 的模式来支持业务。数据团队与中台的工具团队在同一组织架构下,共同支持不同的业务线。例如,抖音直播的数据团队在数据平台视角下支持直播业务。

DataOps 的落地有两种方案,一种是中台工具向使用者推广,另一种是数据BP 根据自身面临的挑战推动中台进行迭代和改造。目前,字节跳动主要采用第二种方式,即数据 BP 沉淀方法论,让工具开发对应能力,然后推广出去。

在这种模式下,数据 BP 面临的一个问题是支持什么类型的业务。不同的数据团队支持的流程和业务场景各不相同。对于数据 BP 团队而言,他们需要支持多种场景,包括决策、运营功能和策略项场景。

字节跳动的数据团队在支持多样化的业务场景时,面临着多样化的交付挑战。团队不仅需要交付数据产品,还需要交付数据建设成果,如 Hive 表等数据结构。此外,团队还需提供 BI 看板、API 数据集以及 ClickHouse 表等不同类型的数据产物。

在这种多元化的交付需求下,数据 BP 团队的时间分配也呈现出多样性。大约 40% 的时间用于数据建设,如 Hive 侧的数据构建,而剩余时间则用于数据产品和BI 等相关工作。这种多样化的工作内容要求数据团队具备广泛的技能和灵活的工作方式,以适应不断变化的数据支持需求。

字节跳动的数据团队面临着多样化的支持流程和模式,这使得标准化变得困难。为了确保数据建设的完备性和支持业务的有效性,团队引入了一套核心指标——0987,以衡量数据 BP 团队的表现。

0 代表数据事故数为 0,包括 Hive、API、数据产品等各方面的数据问题。目标是确保数据团队能够提供不阻碍业务运行的数据服务。

9 代表需求满足率>90%。在数据 BP 模式下,需求来源多样,包括产品、运营等直接向数据团队提出的需求。这种短链条的支持方式提高了业务对数据使用的敏捷度,但同时也导致需求量爆炸和类型多元化。

8 代表分析师覆盖率>80%。这个指标关注于数仓建设的有效性,确保分析师的日常查询主要依赖于已建设的数仓模型,而不是原始数据。

7 代表用户 NPS>70%,70% 以上的用户持鼓励或认可态度,剩下 30% 的用户持中立态度,不存在否定态度的用户。通过定期的用户调研,收集反馈以衡量用户满意度,从而反映出数据团队对业务支持的整体表现。

通过这些指标,字节跳动的数据团队能够持续提升服务质量,满足不断变化的业务需求。过去两三年中,NPS 平均值从 60 多提升到 80 多,显示出团队在数据支持方面的持续进步。

我们面临的核心挑战主要可以分为三个部分:质量、变更频率以及风险场景。

首先,关于质量的挑战,由于我们的数据 BP 团队和中台工具团队在一个统一的大数据平台组织下,为避免烟囱式建设,选择了大一统的数仓建设。这带来的挑战包括链路复杂性、任务链路节点数量庞大以及难以追踪任务状态。一个任务链路可能包含上千个节点,从 MySQL 同步到 Hive 的过程中,各个环节的任务状态难以追踪。同时,由于需求量大,线上任务的变更次数也非常频繁。

其次,关于变更频率的挑战,数据团队不仅支持内部决策,还支持线上服务,并为 B 端、C 端提供数据建设。这涉及到多种风险场景,如数据链路可能影响到线上任务的结算,包括抖音直播中的公会任务或主播收益等场景。

最后,由于链路复杂且变更频繁,事故发生的概率相对较高。根据当前情况,研发事故中有 56% 可能是由研发流程不规范导致的。

除了质量、变更频率和风险场景的挑战外,我们还面临着开发过程中的其他挑战,如需求理解问题和遗留的技术债务。此外,硬件成本也是一个显著的问题。

硬件成本挑战的加剧源于公司发展的需求。过去,预算控制主要基于总体成本的控制,即公司设定一个总的预算目标,数据团队只需在这个目标范围内使用资源即可。然而,随着互联网行业近两年的发展放缓,成本控制策略也发生了变化。现在,我们开始将成本控制的关注点下放到单个数据需求的层面。这意味着,我们需要对每个数据需求的成本进行更细致的管理,而不是仅仅关注总体成本是否超标。

在新的成本管理策略下,我们认识到有些数据需求的价值可能并不与其消耗的成本成正比。因此,我们需要对需求进行更严格的评估,确保每个需求都能带来相应的价值,同时避免不必要的成本浪费。这种转变要求我们在满足业务需求的同时,也要注重成本效益,以适应行业发展的新常态。

除了数据质量、硬件成本之外,人效也是一个关键问题。随着行业内部人员调整信息的增多,如何确保数据团队的高效运作变得尤为重要。在裁员现象普遍的背景下,公司自然会关注如何用更少的数据开发人员创造更大的业务价值。

从公司视角来看,这是一个合理的问题:如何优化人力资源,以实现更高效的业务支持。因此,数据团队需要找到方法来度量并提升人效。在这个过程中,DataOps 成为了一个合适的解决方案,它能够帮助团队应对上述挑战,提升效率,同时确保数据质量和成本控制。

02

DataOps 理念在字节的具象

DataOps,根据信通院专家的定义,是一种数据开发过程,它通过对人员、工具和流程的重组,构建了自动化的数据流水线。这样做的目的是不断提高数据产品的交付效率和品质。在字节跳动,我们对 DataOps 的理解与这一概念相符,我们认为它是一种结合人员、流程和工具的方法论。

从数据开发团队的角度来看,我们所调用的资源包括数据开发人员、需求提出方,以及从需求到交付的整个流程。此外,还包括支持数据开发的平台能力,在字节跳动,平台名为 Data Leap。在其他公司,类似的平台可能被称为数据开发套件,例如阿里云提供的数据开发套件,或者其他公司自主研发的大数据套件。开源社区也提供了各种底层能力和调度工具,如 Dolphin Scheduler 等,这些都是支持 DataOps 实施的关键组成部分。

DataOps 应该整合现有的工具和能力,其核心目标是提升数据质量和效率,其中数据质量被优先考虑。基于这一认知,我们面临的一个关键问题是,如何将 DataOps 与现有的能力相结合。DataLeap 作为字节跳动的一站式数据开发平台,已经发展多年,提供了开发套件、质量管理、数据追踪等全方位能力。

2023 年年初,我们面临了如何定义 DataOps 的问题。我们不想简单地将数据开发的整个流程,包括集成、调度等能力都归为 DataOps 的一部分。虽然在业界有许多公司是这样做的,但在字节跳动,我们认为 DataOps 主要解决的问题是规范研发流程。我们希望实现公司内部研发流程的统一,并将这些流程产品化,以便各个团队能够应用这些方案和流程。

在字节的理解中,数据开发的基础能力的迭代并不属于 DataOps 的范畴。为了推动项目前进,我们可能不会将数据平台套件相关开发能力立即纳入 DataOps 的范畴。

我们对 DataOps 的理解和实施策略涉及到了对需求流程、流程管理和研发工具的整合。DataOps 的核心是连接和规范,这两个方面是我们在当前形势下需要重点解决的问题。

首先,关注需求与数据交互全流程的串联。在过去,没有足够关注到如何将需求与数据资产、线上任务、SQL 资产、Hive 接口、API 或 BI 看板等交付物紧密联系起来。我们希望构建这种绑定关系,以便能够追踪数据资产的来源和变更历史,这对于未来的数据管理和分析将非常有帮助。

其次,要解决规范问题。规范包括需求评审、模型开发、测试和上线验收等环节。虽然许多公司在这方面已经做得很好,但字节跳动由于支持模式的历史原因,需要从敏捷支持状态转变为规范支持状态,同时避免效率的损失。为此,我们将建设相应的能力,如需求绑定、模型检测、代码检测、自动测试和发布流水线,以确保这些规范能够在我们的组织模式下落地实施。

03

DataOps 在火山引擎 DataLeap 的产品化方案

火山引擎 DataLeap 产品方案是一个全面的数据开发和管理平台。这个方案集成了强大的计算引擎、全链路开发工具、集成处理能力、服务发布、运维支持以及全域数据治理等相关功能。这些能力共同构成了 DataLeap 平台的核心理念,旨在为数据团队提供全方位的支持。

DataLeap 平台的 DataOps 实施重点在于构建一个开放平台,以支持数据团队的工作。这个开放平台的关键在于它允许数据 BP 团队根据自身需求直接开发功能,而无需完全依赖中台团队。这种架构设计的目的是为了解决中台团队难以全面且及时响应所有数据开发团队需求的挑战。

DataLeap 的开放平台提供了开放 API、开放 UI 和开放数据源,使得 BP 团队可以自主开发试点功能或特定方向定制的能力。这些能力在验证有效后,可以逐步沉淀为中台普适功能,供更多应用团队使用。中台开放平台不仅提供了技术能力,还支持后续的持续运营。

通过这种方式,DataLeap 实现了数据平台团队与 BP 团队的协同工作,共同推动 DataOps 能力的落地。这种模式允许不同团队专注于其专业领域,如测试团队可以自行开发测试相关功能,然后通过开放平台与中台集成。这样的架构提高了整体的灵活性和响应速度,确保了 DataOps 理念中的规范和流程能够在组织内部有效实施和推广。

在字节跳动的 DataLeap 平台中,各个团队有明确的职责分工。平台研发团队负责构建数据开发的功能底座,提供基础的数据开发能力,并确保平台的开放性。平台不仅仅是作为一个闭环系统,而是提供支持,允许内外部团队在其基础上进行扩展和开发。

平台还实现了内外一体的理念,即对内产品和对外发布的火山引擎版本保持一致。数据 BP 团队负责规范制定,并基于平台的开放能力开发插件,进行内部推广。如果某项插件在内部推广效果良好,它可能会被沉淀为平台的一个标准能力,并进行收益评估。

对于外部团队而言,他们可以直接利用平台的能力和最佳实践模式。这种模式确保了业务和技术团队能够从平台提供的功能中直接受益。

DataLeap 产品化方案中的两个关键点是需求管理和全链路跟踪。需求管理能力已经实现,包括需求的准入要求、开发过程管理、交付物绑定、进度追踪和价值评估。这套能力要求在代码变动时必须先绑定需求,确保交付物与需求之间的对应关系清晰可见。这一能力虽然基础,但对于实施 DataOps 和确保数据链路过程中的规范遵守至关重要。它为全链路的数据管理和分析提供了坚实的基础。

流水线管理能力是确保数据质量的关键环节。这套能力构成了数据质量管理的底线,通过发布流水线来控制数据的处理和交付过程。在流水线中,测试和发布被明确区分,确保了数据在发布前的质量验证。同时,离线和实时数据处理也被分开管理,以满足不同业务场景的需求。

此外,流水线还实现了任务优先级管理,允许团队根据任务的重要性和紧急性进行排序和调度。这种管理方式不仅提高了数据处理效率,还确保了关键任务能够得到优先处理,从而提升了整体的业务响应速度。

数据团队利用插件来实现对数据开发过程的规范控制。这些插件是由 BP 团队开发的,而不是中台团队。通过这些插件,BP 团队可以将自定义的规范和禁令直接集成到数据开发流程中。这样,一旦数据开发行为违反了既定规则,插件就会采取措施,如禁止上线或触发其他解决方案。

此外,字节跳动的测试和发布流水线有其独特之处。与许多公司不同,字节跳动的测试环境与生产环境之间存在较大差异。因此,目前的测试流水线主要依赖于生产数据源,但不写入生产环境,以解决日常的测试问题。这种做法的原因在于,数据开发过程中常常需要解决各种数据案例问题,而这些问题可能无法在测试环境中完全模拟。只有达到一定的数据规模,才能完全复现生产环境中的状态。

综上所述,字节跳动的 DataLeap 平台通过 BP 团队开发的插件,强化了数据开发过程中的规范控制,同时也体现了公司在测试流水线方面的独特实践,即利用生产数据源进行测试,以确保测试的有效性和可靠性。

04

规范+产品在字节落地的最佳实践

为了在公司范围内大规模实现 DataOps 的落地,字节跳动采用了三个策略:
  • 鲶鱼效应:让一些团队先行实施 DataOps,以产生示范效应。例如,直播团队可以先行动起来,通过实践展示 DataOps 的优势。这样,其他团队可以看到实际的效果,并受到启发,进而跟随采用。
  • 拆箱即用:为了降低实施 DataOps 的门槛,字节跳动提供了“拆箱即用”的解决方案。这意味着新用户可以迅速开始使用 DataOps,而无需重新构建整个研发流程,从而大大减少了实施成本。
  • 自顶向下:字节跳动还采取了自顶向下的策略,即说服公司高层和业务数据开发团队的领导层。通过展示 DataOps 的价值和逻辑,让他们认识到引入DataOps 理念对于解决问题的重要性,从而获得支持和推广。

在落地 DataOps 的过程中,字节跳动注重通过指标牵引来衡量数据研发团队的效能。参考业务研发团队的实践,我们确定了几个关键指标,包括交付效率、质量以及资源投入的收益等。这些指标为我们提供了衡量研发效能的依据。

DataOps 在这些指标的实现上提供了底层的支持。通过实施规范和流程的串联,确保了相关效能指标数据的收集是有效的,并且提供了改善的手段。这意味着,通过 DataOps 的实施,能够确保数据的真实性和可靠性,并在此基础上进行分析和优化,以提高数据研发的效率和质量。

在 DataOps 落地的过程中,管理者视角上的挑战尤为明显。数据开发团队可能会有疑问:为什么我要采用 DataOps?为什么不能独立开发一套自己的流程和方法?这些疑问为推广 DataOps 带来了困难。

对于数据开发团队而言,我们的目标是向管理者展示字节跳动的经验,即通过开放平台,让数据团队能够输出其专业价值。数据团队虽然是技术团队,但他们的日常工作不仅仅是编写 SQL 和配置 API,他们还拥有自己的核心价值,包括业务价值和专业价值。

业务价值方面,由于数据团队通常与特定的业务团队紧密合作,因此这部分价值相对稳定且不易被挑战。然而,专业价值方面,则较难明确表达和推广。在实践DataOps 的过程中,我们认识到,要使数据团队能够展示其专业价值,例如开发有用且高效的插件或规范。

因此,我们在中台层面提供了开发能力,使得任何数据团队都可以开发出有价值的插件或规范。只要这些插件或规范能够证明其收益,就可以在公司的其他数据团队乃至公司层面或对外进行推广,从而提升整个数据团队的专业形象和价值。

站在研发的视角上,实施 DataOps 时一个关键问题是确保研发人员能够在遵循规范的同时获得工作成就感。这可以通过以下两个方面实现:
  • 认可&执行:首先,需要确保所有数据开发人员都能认可并执行 DataOps 中的规范。由于规范往往要求改变现有的工作习惯,因此需要充分沟通,明确团队面临的挑战和个人发展机会。解释实施 DataOps 的原因,并避免强制推行,以免造成抵触情绪。
  • 参与&贡献:其次,为研发人员提供参与式开发环境,鼓励他们分享想法和反馈,甚至参与插件的开发。这样做不仅促进了个人影响力的提升,还确保了团队成员能够从工作中获得专业成就感和参与感。
DataOps 的实施不应仅仅是执行性的工作,而应是一个持续参与和贡献的过程。通过让研发人员参与到 DataOps 的各个环节,不仅能够提升他们的工作满意度,还能够加速 DataOps 的落地和优化。

从收益的视角来看,DataOps 的落地过程可以带来以下三方面的益处:
  • 规范:DataOps 能够将不同方向制定的规范转化为产品功能,确保流程的标准化和自动化。这意味着,数据开发团队不再需要依赖线下文档形式的规范来指导工作,而是通过产品功能来确保流程的遵循。例如,系统可以确保在特定时间点执行必要步骤,如果未遵循,则无法上线。
  • 质量:DataOps 能够系统性地解决风险场景中的流程规范问题,从而减少由研发流程引发的数据事故。尽管无法完全消除所有数据事故,但可以确保由研发流程引发的事故不再发生。从字节跳动最近半年推行的结果来看,实施了DataOps 的团队确实大大减少了数据事故的发生。
  • 效率:DataOps 还能为业务研发需求提供效率提升。特别是在串联能力方面,许多过去需要人工处理且耗时较长的工作现在可以得到有效提升。例如,测试环节,过去可能需要手动配置和编写大量代码进行测试,而 DataOps 引入后,测试能力包括个人测试、QA 测试和回归测试等都可以实现自动化,使得开发者可以专注于解决业务问题,从而提高整体效率。

05

未来数据研发展望与对外开放

在未来的发展中,DataOps 在字节跳动将面临一些挑战和目标。首先,DataOps 将继续围绕业务价值这一核心,数据开发团队的存在和认可最终取决于业务是否愿意为此买单。因此,一个关键命题是数据需求的价值度量标准。

业务需求的度量相对简单,例如开发一个功能,其价值很容易衡量。然而,数据需求的度量则复杂得多,因为它涉及的环节众多。例如,一个产品同学提出一个数据摸查需求,经过两周的摸查后,得出结论证明他的想法不可行,这样的需求虽然帮助形成认知,但并未在功能上产生实际收益。如何评估这类需求的价值,是一个重大挑战,字节跳动正在尝试解决。

我们希望通过清晰地度量数据需求的价值,来实现价值最大化的调度策略。在过去,这些决策更多是依赖于人工判断。未来的目标是通过智能化或自动调度策略,来决定在现有能力下,优先处理哪些数据需求。

在 DataOps 的未来规划中,字节跳动特别重视提升数据开发团队的专业性,这主要体现在质量和效率的提升上。近期,字节跳动开始探索大模型在数据开发中的应用,以解决两个关键问题:
  • 需求对接能力:由于数据开发团队通常采用短链条的支持方式,需求对接往往耗费大量人力和精力。大模型的引入有望改变这一现状,通过自动化和智能化的方式,提高需求对接的效率,减少人力投入。
  • 辅助开发能力:字节跳动正在尝试利用大模型来辅助数据开发,包括文本生成 SQL、数据追踪和相似性检测等能力。这些技术的应用有望显著提升数据开发的效率。
  • 低成本的数据测试和验证:字节跳动面临的另一个挑战是如何在需要使用生产数据的情况下,实现大规模数据测试和验证,同时控制计算资源的消耗。在某些情况下,测试可能需要消耗数百万小时级的计算资源,这对成本和效率都是巨大的挑战。

字节跳动在 DataOps 的落地实施方面已经取得了显著进展,并预计将在下半年通过火山引擎这一平台对外输出其数据中台解决方案——DataLeap。DataLeap 作为字节跳动的一站式数据中台套件,实现了内外一体,即火山引擎上的 DataLeap 版本与字节内部使用的版本基本一致。

未来,字节跳动计划继续以相同的方式支持内外部业务,确保火山引擎上的DataLeap 能够为更多用户提供高效、一致的服务,帮助他们提升数据处理和分析的能力。通过这种方式,字节跳动不仅能够内部优化其数据开发流程,还能对外输出其数据处理的最佳实践,为整个行业提供价值。

字节跳动为对 DataOps 和数据开发感兴趣的同学提供了一个交流群,可以通过扫描二维码加入。在群里,可以与团队成员和其他参与者进行更深入的讨论和交流,共同探索数据开发的最佳实践和未来趋势。欢迎有兴趣的同学积极参与,共同学习和进步。
以上就是本次分享的内容,谢谢大家。


分享嘉宾

INTRODUCTION


王洋

字节跳动

抖音直播数据研发负责人

从事大数据研发工作十年,个人经历覆盖大数据平台、数仓建设、数据治理、数据服务等多个方向。目前负责抖音直播的数据研发,围绕如何实现数据高效、高质量地帮助业务实现价值,在数据研发流程与体系建设方面有较多经验。

活动推荐

往期推荐


大模型分布式训练的第四种境界

OPPO大数据AI湖仓一体实践

哪里人才紧缺,哪里就有大模型

阿里云 DataWorks 湖仓融合数据治理与大模型应用探索

阿里通用多模态大模型 OFA 研究实践

国内卷废了?生成式AI+出海了解下!

袋鼠云在实时数据湖上的探索实践

58用户画像数据仓库建设实践

GTC 2024 回顾:揭示大模型领域的国内外前沿研究与应用

快手统一分析服务建设实践

点个在看你最好看

SPRING HAS ARRIVED

继续滑动看下一个
DataFunSummit
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存