更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群

本文根据 ArchSummit 全球架构师峰会（深圳站）来自抖音数据研发负责人王洋的现场分享实录整理而成（有删减），本次分享主要包含字节跳动数据研发的模式与挑战、DataOps理念在字节的具象、DataOps产品化及落地、最佳实践、未来展望五个部分，分享内容皆来自于字节跳动业务实践经验。

字节跳动数据研发的模式与挑战

中台工具+数据BP模式

字节在落地DataOps的过程当中，与我们数据支持所采用的中台工具+数据BP的组织模式相结合，由中台工具团队负责打造功能的基座，实现了数据开发的各项基础能力并提供开放平台，对数据BP团队提供贴身的技术支持，同时也将这些能力通过火山引擎以内外一体的模式输出。所谓的内外一体是指字节的各类数据工具如DataLeap在面向内外部用户使用上实现了一致性。

对于数据BP团队来说，在落地DataOps的过程中，重点做了三件事情：第一件事是规范的制定，在字节内部长期实践过程中，我们认为实践团队才是规范的最佳发源地；第二件事是基于中台工具的开放平台实现插件的开发，数据 BP并不是一个纯数仓团队，其中也包含了部分工程团队，与数仓一体的工程团队可以将数仓日常的痛点以插件的形式实现并落地，不同数据BP团队可以根据自己的特点开发不同插件；最后一件事是收益评估，DataOps推广完了之后，也是放在 BP 来评估，而不是放在平台来评估，中台工具团队就可以专注于能力本身，开发数据 BP 团队专注于整个规范跟价值。最后外部客户可以同时享受到我们的平台能力，以及沉淀下来的 BP 模式，这就是字节整个团队在DataOps上落地的协作模式。

数据BP的核心指标：0987

数据BP团队做的好坏与否如何来评估，我们用了一套浅显易懂的指标0987来评价

0指不要出数据事故，这里的事故包括了时效、质量等问题，由于我们支持了较多线上和资损场景，事故在我们的评价体系中是生命线；

9指需求满足率，我们承接了来自多方的数据需求，希望能达成90%以上的需求我们都能按期交付的目标；

8指分析覆盖率，这个指标指外部团队基于数仓的查询能80%使用到经过我们建设和汇聚的表，而非原始表；

7指NPS 指标，我们每个季度会面向所有提需用户和数据使用用户发放问卷，收集对应的反馈信息，70%意味着大部分的同学对我们持正向评价且负向评价趋近于0；

来自质量挑战

在字节数据团队当前的支持模式下，由于支持模式多种多样，覆盖了各类核心决策及线上场景，我们遇到的首要挑战是来自数据质量的：

链路复杂：最长任务全链路节点数量上千个，单个任务的的下游数量最大也达到了千级别
变更频繁：每周仅直播数据团队数据链路变更次数就能达到上千次，涉及风险场景上百次
事故易发：质量事故时有发生，22年全年数据研发事故涉及到研发规范的占比56%

来自硬件成本的挑战

在降本增效大背景下硬件成本也逐步变成数据团队的一个核心挑战，在过去我们控制成本与大多数公司一致，主要基于预算，先测算出一个全年计算和存储资源目标，然后基于预算开展治理动作，清理无效任务或降低TTL；但是现在需要朝着需求的精细化控制方向前进，需要进一步看清楚我做这个需求需要多少硬件成本，从而将硬件成本的管控精细化到需求层面

来自人效的挑战

除去硬件成本外，我们的另一个成本大头就是人力成本，我现在带一个数据研发团队，在每次进行HC盘点的时候我都会遇到两个灵魂提问：

如何证明团队当前的状态是高效的？
如何用更少的人员创造更大的业务价值？

这其实是一个很现实的挑战，我们如何证明一个数据团队它的价值是什么？

DataOps理念在字节的具象

既然面临着这么多的挑战，我们就要去思考如何能够突破这些挑战，从业内取经，我们发现DataOps就是一种能够有效帮助我们解决上述问题的方案

信通院关于DataOps的定义

数据研发运营一体化（DataOps）：是数据开发的新范式，将敏捷、精益等理念融入数据开发过程，通过对数据相关人员、工具和流程的重新组织，打破协作壁垒，构建集开发、治理、运营于一体的自动化数据流水线，不断提高数据产品交付效率与质量，实现高质量数字化发展。

我们的理解

DataOps是作用于人+流程+工具的一套方法论，目标是提高数据质量和开发效率，主要通过敏捷协作、自动化/智能化、以及清晰的度量监测，让数据流水线达到持续集成、部署、交付（CI/CD），在DataLeap体系内，DataOps主要以规范研发流程为目的，涵盖对规范研发流程的“已有能力集成”，形成一站式研发体验，同时也包括规范研发流程所需关键的“新能力建设+集成”，除此以外的数据开发基础能力迭代不作为DataOps的一部分

我们认为 DataOps 的核心包括以下部分

第一个是链接，所谓的链接是要打通从需求、开发、资产、用户整个数据全链条的绑定关系。从功能上来讲它比较简单，解决了需求与代码的关系问题，业务研发侧早就已经实现了这个能力，研发人员提交的每一段代码，都能知道是哪个需求。但是在数据开发这件事情上，过去缺乏关注，所以首先需要做的事情是连接需求跟数据全环节。

第二个是规范，过去数据研发整个全流程较为缺乏规范的产品化，主要通过团队内部的文档要求来承载，包括提需评审、模型开发测试、上线验收这些环节，我们认为 DataOps在规范上面最首要的事情是要把所有数据研发过程中的这些散落的规范产品化并嵌入到日常的开发链路中。

DataOps产品化及落地-DataLeap

这张图展现的是字节数据开发的dataleap套件能力，涵盖了计算引擎、全链路开发、全域治理、资产等工具，这样的一站式大数据开发套件，能够帮助用户快速完成数据集成、开发、运维、治理、资产、安全等全套数据研发工作，帮助数据团队有效的降低工作成本和数据维护成本、挖掘数据价值、为企业决策提供数据支撑。DataLeap不是一个产品，是一个套件(Suite)。形象的类比就是类似Office，多个产品相互配合，解决同一个大的问题或者叫解决方案，产品之间是相互合作辅助的关系。

DataOps敏捷规范研发平台

这是字节整个 DataOps 的产品化的整体框架图，核心提供的一套DataOps敏捷规范研发平台。以前有一种模式是平台团队自己全包，把这些所有的规范全部给制定好，由平台团队推给数据开发团队，但这种模式不太适合我们，因为平台团队离业务远。

我们认为在这种情况下平台应该选择优先提供开放的能力，这里的开放能力包括开放数据与接口、开放流程等等，有了这套开放能力，意味着所有的数据开发团队可以自己去编排流程，去做自己的规则规范。

另外我们发现开发团队做好之后，这套DataOps敏捷规范研发平台在所有的数据开发团队都通用，举个例子，测试的能力在字节不是在平台做的，有专门的数据 BP 团队，实时这块有特殊诉求：发布完了之后数据要做盯盘，盯住实时数据的变化。依托开放平台提供的数据支持，在直播场景下会提供给到主播一些实时的数据，去辅助他们做及时的决策。这些实时数据包括用户的数据、用户的画像等等，主播可以基于这些用户的画像去调整话术。基于开放平台，数据BP团队做任务的整个发布能力，之后我们发现这套能力可以通用。

需求管理

简单的给大家看一下字节现在已经上线的内部版本的功能，包括了需求管理的各个维度，当然需求管理这里其实核心的思路是让需求能够进入到数据研发的全流程当中，大家可以看到我们会做需求的准入要求，以及跟开发过程以及交付绑定，然后需求的进度追踪、价值评估等相关的一些事情，这是一个标准需求流水线，是字节需求管理平台上的一套流程，就是从需求开始，初评、详评、排期、研发验收、价值反馈结束。

这是需求绑定页面，在做任务开发的时候需要对当前的一些需求做绑定，当然这只是提供了需求绑定开发环节的一个图，我们也会有包，比如说资产环节以及任务环节等各种修改环节都会跟需求做绑定。这个功能很简单，但是需求的全链路串联为字节带来的收益非常大，解决了第一个是可度量所有全流程的问题。

流水线管理

第二个是流水线管理，字节的流水线管理包括测试流水线、发布、离线、实时任务管理、任务优先级管理等相关的能力，这是现在线上跑的一个任务，跑完的流水线的状态，就发布会做登记、检测、检查、review，然后定时发布任务、盯盘等确认等相关的动作。

重点讲一下这里的发布跟测试环节，这两块在很多公司其实是有测试环境的，但是在数据量特别大的场景和数据，或者较为复杂的场景下测试环境是没数据的。测试环境跟业务研发相比，没办法涵盖各种各样的问题，比如说银行场景下测试环境和生产环境肯定是隔离的，但是在字节这种互联网场景下我们的选择是不分离，我们的发布和测试其实是基于的是同一套数据，同一套环境，那如何做测试跟生产的一个隔离？核心点在于我们要求所有没有经过发布流水线的任务是不能写生产的表的，读任何生产的表，但是不能写任何生产的表。这样带来的好处是我们的测试和生产是完全一致的，同时也能保证测试完了之后直接推到生产上去，这样下来后面的测试、 QA 介入的成本是极其低的，这是字节采用的一种方式。

最佳实践

推广运营：如何在公司范围内大规模落地DataOps？

做了这些工具之后要如何去推广？这也是今年初字节面临的问题，就是如何在公司内大范围去落地 DataOps 的能力。最早开始推得很辛苦，也遭遇了很多挑战，不过也总结了一些经验。

鲶鱼效应

第一个叫做鲶鱼效应，所谓的鲶鱼效应因为是数据BP 在主导这件事情，所以主导团队可以先推起来。比如说在直播场景下先试用拿到非常多的指标，总结经验，我们可以带着这些指标和经验去和其他团队沟通，以提高人效的角度切入，在这种情况之下，有的团队就会愿意来学习试用。

拆箱即用

第二个是拆箱即用，我们向其他 BP 团队提供的时候，其他 BP 团队不需要多做任何其他的事情，只需要打开他的流程开关就 OK 了，切换路径成本是非常低的。

自顶向下

第三个是自顶向下，类似的像 DataOps 这种工具跟能力，一定是需要先拿到自顶向上，或者是来自于业务侧更高层的认可之后，才能够持续不断地往下推，类似规范的事情，不是一个自下往上能推得起来的。

指标牵引

一个研发 leader 肯定会关注研发效能问题，这里给大家分享一套字节基于研发效能的指标牵引体系，该体系有四个维度的度量指标，包括效率、质量、资源投入、收益等相关的一些指标。这些指标是我们参照业务研发来形成了一套数据研发指标体系，我们会去关注数据需求的交付周期、定容率、交付数、缺陷修复时长、线上事故、业务研发的配比。最后是重点专项相关的一些事情。这里面除了最后一个是需要人工去干预的，其余的现在都能做到线上化的统计，这是非常方便的。

管理者视角

所谓管理者视角是围绕数据开发团队的价值和未来，通过开放让数据团队有可输出的专业价值。对于数据团队来讲有两类价值，一类叫做业务价值，一类叫做专业价值。业务价值很好讲，是我为业务做了多少个需求，其中哪些重点项目重点参与了，最后是为业务带来了多少效率上的提升，通过某些数据的手段让业务拿到了多少收益。其次是专业性的价值，这个事情对于很多数据团队来讲是一个很困扰的难题，数据团队到底在业界、在公司内部有哪些是不可替代的？有哪些是专业性的东西？这里我们在做 Datops 实践的时候，发现通过开放让数据团队自己有可输出的专业性价值，这非常关键，这能让数据团队很充分地来参与到这件事情当中来。