（一）从 ETL 到 DataOps：新一代数据湖仓开发架构全解读

                                                                                                                                                <p><img src="https://oscimg.oschina.net/oscnet//3fc2b632ccb3bd7fbd3ae08589eb3ecb.jpg" alt=""></p> 

《新兴数据湖仓设计与实践手册：数据湖仓与 DataOps 开发规范（2025）》是一份面向数据工程师、数据架构师与企业数据团队的系统性实践指南，全面总结了当下湖仓一体架构在企业落地过程中的关键设计方法、开发规范与工程经验。本手册不仅覆盖项目规划、权限体系、工作流编排、ETL 与实时/离线融合开发模式 ，也结合 WhaleStudio 与 DolphinScheduler 的实际能力，为读者提供可在真实生产环境中直接复用的架构与流程参考。

手册第一部分重点聚焦 ETL 与 DataOps 开发架构设计，从项目与权限规划、湖仓分层与工作流的组织结构，到批流一体任务设计、开发/生产环境隔离策略、逻辑任务最佳实践等，构建了一个完整的端到端数据处理体系。这一部分对数据平台搭建者、数据开发工程师、调度与运维人员尤其有价值，可帮助团队快速建立高标准、可治理、可扩展的数据湖仓工程体系，显著提升数据任务的稳定性、可维护性与协作效率。

1.1 项目与权限设计

项目与权限管理是ETL与DataOps开发架构设计的基础环节，直接影响到系统数据任务的安全性与协作效率。在DolphinScheduler和WhaleStudio当中，整体开发管理是项目-工作流-任务三个层次来进行管理的，所有的资源权限都是在项目级别来控制的，因此需按照以下原则设计项目与权限：

• 项目管理：根据业务模块划分项目，确保每个项目针对每个团队独立可控，避免权限混乱，例如，不同业务部门有自己的项目

• 角色权限：在WhaleStudio当中还可以配置精细化的角色权限（如开发、测试、运维角色），确保不同角色的权限范围明确，避免越权操作。

• 资源隔离：不同项目的资源（如资源中心脚本、数据源配置、workfer分组等）需隔离，可以通过资源授权的方式给其它项目或者公共资源使用。

如果一个人员小组内，有多个不同的分层或者多个源系统，如果在源系统内复杂任务多或者考虑到跨部门不同源系统人员需要访问监控的时候，也可以考虑使用项目来做隔离，整体上，项目是在工作流更高级别的控制的，如果系统复杂度不高，可以不使用太多的项目来进行管理。

1.2 工作流与数据湖仓架构设计

在数据湖仓与工作流的对接设计中，合理的工作流分类和组织是保障数据开发与运维效率的关键。根据团队大小，数据仓库复杂度，项目、工作流、任务的配置方法各有不同，整体上遵循一个规律：

权限不同放在不同项目、任务多分多个工作流、工作流多了分不同项目/目录。

而在实际使用当中，如何切分需要结合数据湖仓的架构和人员规模来看，一般有三种模式建立数据湖仓工作流方法：

1. 复杂数据仓库，数据开发人员较多（例如，数据仓库规划原子层以上表超过500张，数据ETL脚本开发人员超过5人）

• 数据湖仓分层与工作流对应关系：数据湖仓的每一层都是一个或者多个工作流，依赖通过对表任务的依赖进行跨项目/跨工作流依赖，工作流可以根据需求放在在不同项目或者统一个项目的不同目录下，根据业务逻辑划分来规范工作流的划分；如果任务不多的情况下也可以合并分层的任务到某一个工作流下。

• 工作流不放在同一个项目下：因为每个项目是要设置权限的，所以是否把工作流放在一个项目下，可以根据1.1章节中的项目权限设置综合考虑，如果工作流很多，参与的团队人员也不同，就考虑中不同项目；如果参与团队比较固定，可以考虑用WhaleStudio的目录的方式来对工作流进行管理。

• 依赖设计：内聚的任务都在一个工作流当中通过连线处理，对外的依赖通过依赖逻辑节点，直接依赖对应的工作流或者依赖处理的表任务，这样可以大大提高整体任务执行效率，而不需要等待所有层结束再运行。当然，因为会有跨项目、跨工作流依赖，维护复杂性会增大，可以通过WhaleStudio的影响分析来看运行实例全局跨任务和工作流的影响分析，而不仅仅通过工作流实例来进行。

• 不同部门数据集市因为要权限要求，因此建议使用不同项目来进行处理和管控。

2. 中等复杂数据仓库，数据开发人员（例如，数据仓库规划原子层以上表超过100-500张，数据ETL脚本开发人员超过2-5人）

• 根据不同的业务需求和技术场景，建议从顶层设计上将工作流划分为以下三类：数仓分层工作流、数仓主管理工作流和异常容错工作流。这三类工作流各自承担特定功能，形成完整的数据调度体系。数仓主任务管理工作流主要负责全局的任务调度和依赖管理，将数仓分层工作流通过任务依赖关系串联起来，实现统一管理和调度，也就是主任务会控制整体数据工作流启动时间，然后通过WhaleStudio子工作流的方式来进行管理。

• 依赖串联：将数仓各层的工作流以依赖关系串联起来，形成一个完整的链路。例如，ODS层任务完成后触发DIM层，再依次触发DW和ADS层任务。如果有其它数据集市，可以直接跨项目依赖相关层的子任务完成，或者直接跨项目依赖某一层当中的工作流当中的某几个表的任务，然后可以通过影响分析来分析到跨项目、跨周期的调用和依赖。

3. 中等复杂数据仓库，数据开发人员（例如，数据仓库规划原子层以上表少于100张，数据ETL脚本开发人员超过1-3人）

   • 这一般在中小企业初步建立数据仓库的时候比较常见，此时主要人力在于通过WhaleStudio采集元数据，处理业务的ETL，因此不要做太复杂的项目和工作流设置，建议用一个工作流内的DAG图把所有任务放到一起。

   • 不同工作流一般是日调度、月调度、季度调度，所有任务都在工作流内执行，月调度通过逻辑组件中的依赖组件来依赖最后一天的日调度。

   • 生产和开发大数据集群如果没有两套环境，可以采用工作流的上线和下线来控制工作流的定时是否被触发，缺点就是数据权限无法控制，开发会影响生产环境数据。

在以上几种场景中，可以关注以下常见功能：

1. 关键路径优化：可以通过影响分析和甘特图分析，识别子任务链路中的关键路径，并重点优化其执行时间，以缩短整体任务运行时间。

2. 统一调度：统一调度和统一定时管理，可以集中管理任务的触发、监控和运行状态，便于排查问题和进行统一的资源调度。定时采用统一管理，未来修改定时也可以修改，例如，为了避免并行同时任务启动对数据仓库压力过大（例如上千个0点启动任务），可以有0:00，0:05，0:10等定时设置。

3. 资源池使用：为了限制不同部门/团队对数据仓库和平台的使用，可以设定资源池来控制任务的并发度，这样来限制不同任务和工作流/团队，对于底层平台的使用，避免同时并发太多导致数据仓库/湖，处理效率低下，可以设置组内优先级来控制资源池内部的优先级。

4. 工作流调度策略：

• 时间触发：最常见的是按照预设的调度时间（如每天凌晨）触发全链路任务。

• 事件触发：当源数据更新时（文件接口、数据库内容、Kafka、S3），在工作流定时启动后，立即触发相应的分层任务，提高数据的实时性，可以用子工作流的方式设定成循环工作流而不用定时触发，建议配置串行等待或者串行抛弃策略避免产生大量并行工作流。

• 执行策略：并行/串行等待/抛弃，来应对微批和多工作流实例之间的互斥关系。

5. 异常容错工作流设计

在数仓运行过程中，任务失败或结果异常是常见问题。异常容错工作流的设计旨在快速恢复数据环境，减少人工干预，保障数仓运行的稳定性，一般会清空一些当天做的临时表和相关处理数据（如果SQL脚本未处理或者接口文件需要恢复原状的情况以实现工作流级别的幂等处理），如果在相关任务脚本已经做了容错处理，则不需要单独做工作流来做容错。

• 自动复原：通过异常容错工作流，清理失败任务的中间表和临时数据，为重跑任务准备干净的数据环境。

• 手动介入：对于复杂异常场景，提供人工确认和干预的操作入口。

• 任务失败：当任务因系统错误或数据质量问题失败时，触发容错工作流清理受影响的中间数据。

• 结果异常：当任务结果不符合预期（如指标值超出合理范围），触发容错逻辑回滚数据。

• 中间表清理：将中间表的清理逻辑封装为单独的任务，按需触发。

• 分段重跑：支持按分层或任务粒度进行重跑，避免全链路重跑造成的资源浪费。

• 数据验证：在重跑任务前后，增加数据验证环节，确保重跑后的数据与预期一致。

• 灵活扩展： 异常容错工作流应支持灵活配置，便于新增数据清理规则或调整异常处理逻辑。

1.3 ETL任务架构设计

在新一代的EtLT架构中，复杂的业务逻辑已经不在Transform当中实现，而是在数据进入数据湖仓后，使用SQL来实现。因为处理最复杂的业务逻辑SQL人员容易找，而且不会受制于某个开发工具或者某种数据仓库，所以目前普遍都在用EtLT架构。基于这个思路，在数据库分层当中贴源层（ODS或者STG）数据表更贴近源端，而后续原子层（DWD）和汇总层（DWS）更贴近业务，相关的同步任务和SQL任务设计根据实时非实时会有两种设计思路：

1. 批量湖仓ETL任务设计思路：

• 贴源层，利用WhaleStudio的多表同步功能，一个数据源建立一个数据同步任务，用批量方式写入到目标端

• 原子层，书写SQL任务，根据前面手册当中的建表规范，可以建立SQL任务来处理数据，其中数据日期可以通过全局参数或者牌来传递数据处理日期到SQL当中，也可以建立pre-SQL或者post-SQL来做清空表或者其他操作。也可以利用Shell或者Python来进行处理。

• 汇总层与指标层，类似原子层，根据模型设计撰写SQL相关脚本来进行处理，任务、工作流和项目以及依赖的设计，参见1.2章节相关内容。

2. 实时湖仓ETL任务设计思路：

本思路适用于实时湖仓，或者源端进行实时采集，贴源层使用实时数据加载，而后续用批量进行数据处理的（混合实时数仓）的模式。

• 贴源层，利用WhaleStudio的多表CDC同步功能，一个数据源建立一个数据同步任务，用Streaming方式写入到目标端（例如Iceberg、Hudi、Doris、StarRocks等）

• 原子层，如果是秒级别实时数据，建议略过本层，直接在汇总层或者指标层建立物化视图，如果是分钟级别的，则可以用混合实时湖仓模式，本层利用WhaleStudio的SQL任务，利用微批任务进行处理。如果是确定分钟级别出数据，可以工作流设置为并行，这样确保每分钟都会计算出来数据；如果只是要保持相对实时就可以，就可以选择串行抛弃，这样上一个微批任务没有执行完就可以抛弃掉不执行，节约系统资源。

• 汇总层与指标层，如果是全实时处理，建议使用物化视图模式来直接从贴源层进行实时计算，如果准实时处理可以利用和原子层同样的方式来进行处理。

• 当然如果其中用到Flink Streaming或者Spark Streaming，也可以用WhaleStudio当中的实时任务来进行管理。

1.4 生产环境与开发环境设计

为了保障生产环境的安全性和稳定性，同时满足开发环境的灵活性和高效性，建议在架构设计中严格将生产环境与开发环境进行隔离。通过两套独立环境的设置，可以确保数据安全、任务运行的可靠性以及开发流程的规范性。以下是具体的设计建议和实践规范：

1. 数据源隔离与管理

在生产环境和开发环境中，数据源需使用相同的名称，但其配置（如数据库链接和用户名密码）应有所区分。这种设计既保证了环境的独立性，又能在环境切换时无需修改任务逻辑。

• 同名数据源：生产和开发环境的数据源需保持名称一致，例如都命名为SalesDB，以减少任务迁移时的改动。

• 配置区分：通过区分数据库连接参数（如主机地址、端口）和认证信息（如用户名、密码）实现环境隔离。例如：

  • 开发环境：连接到开发测试数据库，支持调试和数据模拟。

  • 生产环境：连接到生产数据库，需设置严格的权限和访问控制。