摘要：本文整理自抖音集团数据工程师黄鑫老师，在 Flink Forward Asia 2024 生产实践（二）专场中的分享。主要内容主要分为以下三个部分：
1、现状与痛点
2、DataOps 能力建设
3、未来规划与展望
一、现状与痛点
在抖音的业务场景中，整体仍然采用 Flink 作为实时数据仓库的核心处理引擎。Flink 提供了低延迟和高吞吐量的数据处理能力，使我们能够支持大量线上高优先级的业务场景。然而，高时效性也伴随着高风险，在内容体系建设过程中，我们面临着诸多架构和技术层面的挑战。此外，我们还面临一个关键问题：如何在生产环境中更有效地保障数据开发质量和运维流程的稳定性。
为了在线上环境中更安全地进行实时作业的开发与部署，我们建立了一套标准化的研发 SOP 流程，主要包括四个阶段：评估、开发、测试与部署。
评估阶段：该阶段主要涉及需求准入及后续技术方案的设计。
开发阶段：在这个阶段，我们对增量和存量作业进行业务逻辑的迭代与修改。
测试阶段：主要观测任务运行期间产出数据的准确性以及任务执行的稳定性。
部署阶段：在此阶段，我们采用多级 Review 机制来约束开发过程中的不规范行为，以降低因不规范操作引发的线上问题。
然而，在实际运行过程中，我们发现存在以下几方面的痛点：
首先，在需求流程管理方面，我们发现需求与代码之间缺乏有效的联动。由于抖音业务对数据的需求极为频繁，每个季度的整体代码变更次数可达上千次。这使得我们在对存量作业进行历史改动评估时，难以追溯代码背后的实际业务背景，从而显著提升了需求评估的成本。
其次，在开发与测试规范方面，目前整体规范主要依赖于文档形式承载，尚未形成具有强约束力的产品能力支撑。
最后，在发布管控能力方面，尽管我们已采用多级 Review 机制，但在实际执行中，Review 的效率较低且成本较高。因此，我们需要一套更加敏捷高效的发布管控工具。
二、DataOps 能力建设
基于上述痛点，需要开始思考如何有效应对这些问题。通过参考业内优秀实践，我们发现 DataOps 是一套能够有效解决当前问题的解决方案。
关于 DataOps，目前尚无统一明确的定义，不同组织与企业均有各自的解读。以下列举了几种主流机构对其的理解，包括 Gartner、维基百科和中国信通院等。综合这些定义可以看出，DataOps 可视为一种数据管理的最佳实践，旨在使数据开发过程更为简单高效。
在抖音集团的实际业务场景中，我们结合自身特点给出了 DataOps 的定义：我们认为 DataOps 是作用于“人+流程+工具”的方法论体系，其核心目标在于提升数据质量与开发效率。我们希望通过自动化手段与规范化流程，保障数据质量的同时提高整体开发效率，实现数据的快速交付，以满足业务方的数据使用需求。
同时，我们将大数据日常开发工作中常用的能力进行集成，使用户无需在多个平台间频繁切换，即可完成全部开发工作，从而形成一站式研发体验。
因此，整体能力建设围绕实时数据生命周期的全流程展开，涵盖规划、开发、测试、发布与运维等关键环节。在建设过程中，我们与公司内部的开发套件团队及 Flink 引擎团队紧密协作。针对开发所需的关键原子能力，由相应团队协助进行打磨与优化；对于缺失的能力，则推动其新建与集成。同时，他们也将底层能力开放给数据侧，使我们能够基于这些能力进行插件式开发，并进一步集成至 DataOps 体系之中。
2.1 规划
接下来，我将从数据研发生命周期全流程的角度出发，具体介绍在抖音业务场景下，我们如何基于 DataOps 实现全链路生命周期管理。
首先是需求流程管理。该模块的核心作用在于实现连接，即打通用户、需求与代码之间的绑定关系。虽然该功能实现本身较为简单，但它解决了需求与代码之间的映射问题。在工程领域，这种能力早已实现，即每段代码均可追溯至对应的具体需求。然而，在数据开发领域，这一能力长期缺失，也未受到足够重视。因此，这是我们在该阶段首要解决的问题。
借助 DataOps 的能力，我们打通了内部需求管理工具与 IDE 开发环境之间的关联。所有任务开发均需以需求为驱动，从而实现需求与代码之间的有效连接。当完成该层级的打通后，即进入开发阶段。
2.2 开发
在开发阶段，环境管理能力是重点关注的领域。这里的环境管理主要指生产环境与测试环境的管理。尽管许多企业在数据开发中具备独立测试环境，但在大规模数据量或长链路场景下，测试环境往往无法覆盖真实线上情况。例如，在直播业务场景中，需要统计七天或三天周期内的长状态数据。此时，仅依靠测试环境难以准确评估数据质量与任务稳定性。
因此，我们的核心思路是通过定义任务在不同环境间的流转规则及元信息的自动映射与替换，实现生产与测试环境的隔离。具体而言，任务可以配置多套发布环境，各环境间遵循预设的流转规则，最终方可部署至生产环境。在环境流转过程中，任务相关的元信息会根据当前环境动态替换，从而实现环境隔离。
该能力的实现也与 Flink 团队进行了深入沟通。在其多环境支持的基础上，我们通过提交的环境参数动态重写整体 SQL 配置。具体流程如下：在提交代码时，通过 Parser 方式解析整个 SQL，获取 SQL 列表；随后通过深度优先搜索方式提取 Source 与 Sink 信息，并根据提交的环境配置重写 SQL 节点信息，重新封装至 Node 类中并提交。通过这种方式，实现了单套代码在多环境下的部署，且互不影响、相互隔离。
2.3 测试
任务在测试环境完成部署后，进入自测阶段。在此阶段，我们将常用的测试集成工具以插件形式集成至 IDE。代码开发完成后，用户可以通过插件直接在 IDE 中选择自测数据模块，并勾选此次所需的自测规则。选定规则后，系统会自动生成测试用例，并将运行结果打包发送至 QA 侧，由 QA 进行最终验证。待验证通过后，任务将进入发布部署阶段。
2.4 部署
在部署阶段前，我们会对代码进行上线巡检。由于生产环境复杂，除了关注业务逻辑外，还需重点关注任务配置参数的细节，例如消费者是否全局唯一、消费模式是否正确、并发设置是否合理等。因此，我们依据日常运维经验总结归纳出若干关键配置项，并按三个维度进行分类。这些配置将在代码提交上线时生效。
同样，在代码上线后，我们会对 SQL 代码进行整体解析，并与预先录入的规则进行匹配校验。我们采用 Google 开源的 Aviator 表达式引擎进行规则计算，根据不同规则设置不同的拦截等级。对于红线类高危行为，系统将直接阻断上线流程，从而避免因疏忽导致的线上故障。
当上线检测通过后，任务进 入发布管控环节。在此阶段，我们依托平台提供的底层开放能力及流水线编排能力，将上线 SOP 拆解为流程化步骤，确保所有发布过程中需关注的信息可在一条流水线中集成。
开发人员、Review 人员及 QA 测试人员均可在同一流程中查看任务运行状态，从而实现任务的集成部署。这种流程化的管理方式不仅提高了发布的效率和透明度，还确保了各参与方能够及时获取相关信息，促进协作与沟通。
图示中的最后一个环节为发布巡检。在实时任务上线过程中，我们暂未引入类似工程侧的小流量灰度发布机制，因此任务上线即为全量生效。为尽早发现异常，我们设计了持续 30 分钟的实时盯盘机制。该机制依据任务等级设定差异化监控策略，主要监测三类指标：首先是 Flink Metrics 的采集；其次是抽样下发结果监控，包括空值率、递增趋势及异常值监控；最后是时效性采集。通过这些监控措施，我们能够快速识别和处理潜在问题，确保任务上线后的稳定运行。
2.5 运维
此阶段完成后，可以认为一次完整的开发部署流程结束。然而，任务的运行才刚刚开始。由于任务需要 7×24 小时不间断运行，必须持续保障其运行稳定性。常规做法是通过 Lag 指标配置告警以感知异常。然而在实践中，我们发现 Lag 告警存在一定局限性，因为它仅提供单任务粒度的视角。在抖音场景中，数据源众多且跨团队，若上游出现延迟，下游任务可能并无 Lag 积压，导致无法及时感知异常，从而造成用户侧感知滞后，被动应对大量用户反馈。
因此，我们转变思路，提出基于时效性的基线预警机制。具体而言，对需保障时效性的任务设立基线，结合任务全链路血缘推导各节点的延迟，构建完整的延迟基线。当整体延迟超过设定阈值时，即触发预警，从而实现异常的提前感知。这种机制不仅增强了异常检测的敏感性，还提高了问题响应的及时性，确保任务的稳定运行。
在整个过程中，我们主要解决了两个关键问题：首先是全链路血缘构建。在开发阶段，IDE 自动解析 Source 与 Sink 信息，据此构建完整的血缘关系；其次是延迟采集。通过与引擎团队多次沟通，我们决定将延迟采集能力集成至 Connector 层。通过开启配置参数实现延迟采集，并采用异步机制处理，以避免影响正常任务写入流程。这样，我们实现了任务粒度的延迟采集，并结合血缘信息，构建了完整的链路基线监控体系。该能力显著提升了线上异常的感知速度，大幅减少了风险事件的发生频率，提升了应急响应效率。
2.6 效果收益
以上即为我们基于 DataOps 在抖音业务场景下的能力建设成果。通过实践可见，在保障研发质量的基础上，我们也取得了显著的绩效收益。数据显示，通过引入 DataOps 能力，整体研发事故率下降了 60%，需求平均交付周期缩短了 20%。
三、未来规划与展望
关于未来规划与展望，我们有以下几点：
首先是自动化部署。尽管当前 SOP 已覆盖实时数据研发的全生命周期，但各流程之间并非完全串联。未来，我们希望在任务提交至测试环境后，从测试到上线再到运维的全流程实现自动化，使用户仅需关注业务逻辑即可完成开发，真正实现一站式研发体验。
其次是资产化交付。当前实时数据交付形式多样，包括指标、接口、MQ 及数据表等。我们希望在任务部署完成后，系统能够自动生成所需数据并在资产平台完成登记，供用户调用。
最后是一体化容灾机制。我们将基于多环境体系，新增容灾环境，实现代码的一致性维护，并结合 Lag 监控与时效性监控，建立熔断机制。以此实现在异常发生时的自动容灾处理，进一步提升任务运行的稳定性保障。通过这些举措，我们期待在未来能够进一步优化研发流程，提高任务运行的效率和稳定性。