一、大规模数据报表生产的挑战与诉求
首先和大家分享百度商业数据产品及其对数据平台的诉求。
1、百度商业数据产品矩阵介绍
以上百度商业矩阵主要体现其核心商业产品和数据形式：
- 百度核心商业数据产品，主要包括用于网站埋点统计和全流程托管分析的百度统计，反映词汇趋势热度及分析洞察的百度指数，支撑广告主追踪热点并完成投放决策的观星盘，以及其他面向产品、销售、运营等人员的数据产品；
- 成体系化的数据流转，一是 B 端广告主投放广告的物料数据和投放行为日志，二是 C 端用户访问、搜索及消费相关的行为日志。两端数据经过用商一体的加工分析流转到各个数据产品后以丰富多样的形式呈现。
2、百度商业数据产品背后的大数据体系演进历史
从 08 年到现在的 15 年时间内，百度商业数据产品背后的大数据体系已经经过了四个阶段的演进。第一个阶段为单一业务时代，主要基于 MR 和 Linux 的定时任务，支撑小规模的产品孵化，技术相对老旧。第二个阶段进入多元业务时代，面向不同角色的产品矩阵逐渐出现，逐渐开始封装研发框架、调度系统等，进入小规模的 DevOps 迭代。第三阶段开始平台化试水，为解决数据一致性和产品割裂问题，尝试数据产品一盘棋，将数据任务开发运维全面托管并建立标准化的 DataOps。第四阶段在确定 DataOps 体系有效后，将百度商业数据产品全面托管，帮助业务实现架构现代化。
3、大规模报表生产背后的数据挑战
经过分析总结，百度商业数据产品在集团内部主要面临以下三类挑战：
- 海量数据：百度具有数万份的数据集、数十万条数据血缘关系、每天数万次例行计算，海量数据形成复杂的拓扑网络在管理上带来挑战，一体化的数据平台统一纳管便于数据及血缘的查找和追踪。
- 数百名数据开发工程师：开发丰富的数据产品需要大量的高成本数据开发工程师，企业会产生高昂的用人成本，便捷高效的辅助开发产品或平台能为生产提效，节省人力成本达到降本增效的目的。
- 数万个核心报表指标和数十个商业产品出口：大量的指标和出口产品一旦发生故障都需要能快速解决修复，清晰的血缘管理能高效辅助问题定位和排查分析，提高数据及产品的交付质量和用户满意度。
4、大规模报表生产对数据平台的诉求
面对数据挑战，百度数据平台通过建设大规模稳定可靠的流水线数据报表生产链路，解决相关诉求，其核心建设思路和目标主要包括以下两点：
- 提升研发效率：通过统一流程、统一技术栈、统一研发套件形成生产级的流程规范，解决各个产品线数据源的基础设施割裂带来的效率问题和规范问题；
- 优化产出稳定性：通过建设监控能力、运维能力、治理能力等一系列开箱即用的套件，解决面对大规模数据和任务手工无法解决的延迟多、恢复慢、优化难等稳定性隐患。
下面，重点分享全流程 DataOps 的设计思考。
二、全流程 DataOps 的设计思考
1、面向大规模数据报表生产的分层架构
一般来说，在做数据产品交付时，我们会采用分层设计的方式，百度的数据分层架构主要分为：原始数据层、数仓层、指标层、报表层，各层之间通过统一制品的技术中间件衔接。如果将数据生产类比为一般的工业生产，那么分层架构可以看作统一操作规范的生产流水线，统一制品的技术中间件可以看作统一标准规格的生产工具，两者结合保证了数据报表生产的质量和效率。
2、如何选型
面向统一的分层架构，如何选型以实现流水线的生产和高效运维呢？不同于传统的完全割裂的开发运维方案，DevOps 通过任务调度平台和一些数据功能的拼凑实现统一业务框架，DataOPs 则以数据为视角，重塑全流程，实现数据生产流水线，因此DataOps理念更符合我们对统一平台的设想和预期。
3、面向大规模数据报表生产的DataOps平台设计思考
DataOps 以数据为视角，不仅要实现数据研发流程托管，还需要考虑数据治理、任务监控与运维，保证数据生产的全流程在一个平台内完成，平台也贯穿数据和报表的全生命周期。
4、面向大规模数据报表生产的 DataOps 流水
百度将流水线生产与开箱即用能力的 DataOps 理念落地到 DataBoot 平台，实现了数据端到端开箱即用的监控运维与治理能力，覆盖从数据的引入到使用过程数据接入层、加工层、网关层所有的处理套件与能力，见证了从原始数据到报表制品的转化。
5、商业数据产品 DataOps 平台- DataBoot 整体介绍
DataBoot 统一平台基建基于百度的 IaaS 和 PaaS 平台，构建相关的流程工具套件如集成、建模、开发、运维、监控等，结合计算框架、统一网关、血缘采集探针等中间件，并基于数据血缘建设包括全链路运维、全链路可观测性、全局监控分析等进阶治理能力。
三、全流程 DataOps 平台化实践
1、开发环节-大数据任务开发一站式 WebIDE 套件
在开发环节，我们基于 Monaco 搭建轻量级数据开发 WebIDE，通过代码和配置并结合 jar 包支撑数据开发。在此基础上，打通百度 Icode 代码管理平台保证代码不丢不漏实现代码提交，打通各种计算集群使用户无需自己搭建环境在 Web 实现作业调试，最后通过调度平台实现作业上线。
整个数据任务开发 WebIDE 套件将数据集成加工的各种资源和插件打包形成SaaS服务，其中插件即数据集成与加工场景的各种能力，如集成插件、开发框架插件等。
2、部署环节
- 弹性可扩展 Serverless 部署架构。
任务部署的目标是屏蔽与数据处理无关的流程与设施，使部署过程对用户无感，百度Serverless 部署架构从上到下分为控制层、服务层、计算层三层。控制层采用微服务应用部署数据集成加工能力的各种插件，通过 Driver 模块与服务层进行交互。服务层为异步和长作业的模式，通过函数托管平台部署，例如质量检查，数据计算等所有服务均通过函数封装，基于 workflow 实现函数编排，支持 corn 调度和手动触发执行。最后计算层通过独立集群分池部署实现不同场景不同策略的优化和弹性扩缩容资源机制。
- 服务层 Serverless 部署设计。
服务层采用 FaaS 部署，主要是基于逻辑扩展性和极致资源弹性的考虑。其中逻辑扩展性主要体现在可以基于函数粒度完成逻辑拆分与组合编排，复用通用插件和控制流插件。而极致资源弹性主要是数据报表生产的潮汐特点和突发流量资源风险需要依赖弹性扩缩容机制以快速完成资源准备和故障恢复。
- 计算层 Serverless 部署设计。
计算层支持资源池化和多租户。部署图中的 PoolManager 负责资源扩缩容和回收，类似 JVM GC 的功能。SessionPool 可以自动扩缩容，并且可配置化的实现不同的资源分配规则以达到任务的分级保障目的。底层的每个 K8s Pod 是一个计算实例，每个 Pod 有多个container，主 container 负责和 Spark 集群进行交互产生计算。
- 数据血缘探针织入式部署。
DataOps 全流程数据治理需要依赖于高置信的数据血缘，而传统数据血缘采集方案一是侵入强难以落地；二是粒度难以到达字段级和算子级，仅能到表级血缘，无法满足精确控制场景；三是准度差，复杂场景无法识别；四是时效弱，T+1 的血缘无法满足实时管控的生产要求。
因此百度设计织入式部署模式，无需业务修改代码即可完成实时血缘采集。首先，通过 Spark 扩展探针和 Java Agent 探针在用户提交命令时拦截实现无侵入探针织入，其次通过探针解析语法树和实时通信的方式回写到服务端的存储模块，最后在存储模块通过匹配策略识别高置信血缘。
3、发布环节-数据进退场风险管控
通常在数据发布到生产环境的过程中主要存在两种类型的问题造成严重生产事故。一是发布的代码逻辑存在问题造成发布节点及下游所有任务执行异常，引发全链路任务雪崩。二是发布的代码性能下降造成发布节点及下游节点数据产出延迟的连锁效应引发全链路时效性退化。
针对上述风险，如何实现数据进退场的安全可靠呢？目前主要通过规避单点风险和识别数据链路风险的方式保证。单点风险致力于解决单个任务的异常问题，主要通过标准化的 CI/CD Pipeline 实现冒烟测试和基于历史数据的 Mock 测试发现是否存在数据问题。链路风险主要基于数据血缘、冒烟测试结果、设定的 SLA 期望值和周期性任务运行统计数据以及推测算法判断是否存在时效退化等情况，辅助用户决策是否上线相关任务。
除了单个任务的发布以外，平台的框架和网关的升级也存在风险，因此将平台所有中间件依赖包以组件形式封装，并且通过先选举重要程度相对低的任务灰度发布，如果验证无误后再将线上任务全部更新到组件的最新版本。最后结合平台化的管理功能如组件管理、版本管理等实现一定程度的风险规避。
提供端到端一体化的监控分析能力，不仅仅针对一个任务或一个数据集，而是基于血缘拓扑的基础能力监控报表全链路并度量，例如计算每份数据的就绪时间和资源的分位值，根据资源的到位时间和内存及 CPU 等资源的开销，能够对数据延迟进行归因和分析。
数据任务一旦发布用户无需自研监控设施即可开箱即用的达成数据报表的全链路可观测。线上化的监控能实现平台级、产品线级、报表级、任务级、子阶段等通过多层级覆盖，辅助快速识别风险的等级快速定位问题。另外，监控分析一体化能够自动化计算出分阶段耗时，自动故障自动归因等在提高故障定位效率的同时节约了大规模的人力投入，通过 timeline 工具套件实现数据报表的全链路分析，示例如下：
4、运维环节-全链路数据回溯能力
然而，如果源头数据存在脏数据污染下游所有指标或报表，报表数据异常需要回溯，在没有 DataOps 时，所有的数据回溯都需要工程师手动完成，其运维复杂度和风险都非常高，如误操作、资源负载突增抢占、手动恢复缓慢。目前平台提供系统云控功能，用户完成简单触发即可自动完成全流程的数据回溯，做到精确追踪、有序运行、及时恢复。
百度云控系统在租户级别实现自动化全链路数据回溯，跨租户时需要规避安全和权限风险，主要通过事件通知由具有相应权限的管理或运维人员手动触发完成回溯。数据回溯的血缘触发通过 Execute Engine 实现时序控制、基于计算资源的并发控制、容错机制和监控报警等功能自动生成回溯的执行计划并将计算任务的有序分发到计算引擎。详细实现如下：
5、优化环节
最后，分享一些关于大数据计算在优化过程中遇到的问题和解决方案。
- 问题分析与技术思考。
传统大数据调优方法的局限主要在三个方面，一是性能和成本的平衡，在实际业务场景下，任务的重要程度和优先级是有区别的，要考虑如何在满足性能和产出稳定性要求的情况下，平衡资源成本，提高投入产出比；二是调优效率，Spark 作业在性能调优时复杂程度很高，长作业多轮调参消耗掉大量的时间和人力成本；三是缺乏全局视角，研发工程师往往仅能基于一个任务或一份数据进行调优，单点调优做得再完美或许也无法解全局的难题。
面临如上问题时，百度商业数据平台在系统设计目标层面达成统一，首先通过声明式设计，以终为始，锚定数据报表的预期产出时间为时效性目标进行优化，减少了用户的心智负担。其次，完成目标生成、单点自动化调优和效果试验比对实现流程闭环。
- 全局数据报表时效性优化实验。
百度时效性优化系统负责将该系统设计目标和优化思路落地。主要通过设新建优化目标并基于全局优化策略生成待优化项，然后匹配系统效果数据生成试验评估效果，并自动完成优化前后的各类指标的可视化对比分析。
- 单点声明式动态调优。
除了全链路调优，百度在基于单点的声明式动态调优也具备实践。主要通过探针采集作业的日常开销和实效性等指标并回传到 Receiver 模块存储，然后通过 Validator 判断调优效果是否符合预期，如果符合预期则退出，不符合则再通过 Calculator 生成策略并由Processor 实现 Spark 的动态调参，如此反复经过多轮调整后达到调优效果。
四、总结与展望
当前企业内部逐渐重视数据价值，大家发现基于数据的视角 DataOps 的理念能符合大家的预期，但是随着大模型的普及，AIOps 势必能够与 DataOps 良好结合，目前百度内部也在积极的探索和实践，期待由机器自动化识别和调用已有套件进一步实现大数据工程师生产力的飞跃。
