《新兴数据湖仓设计与实践手册：数据湖仓与 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，以减少任务迁移时的改动。

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

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

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

2. 资源隔离与管理

除了数据源外，其他相关资源如工作流、任务脚本、Git引用、日历、定时、牌、环境、告警配置和资源池等，也需在生产和开发环境中分别管理，以避免交叉影响。

• 同名管理： 所有资源需要生产和开发环境名称相同，则可以直接引用而不会出现找不到资源的情况

• 工作流与任务：

  • 开发环境中的工作流和任务主要用于功能开发与调试，可允许频繁变更。

  • 生产环境中的工作流和任务需经过严格审核才能部署，并禁止未经审批的修改。

• 脚本与配置文件：

  • 脚本可以放到任务脚本当中，直接随工作流进行上下线

  • 脚本也可以放到Git当中，通过任务进行引用进行上下线操作，脚本本身走git CICD和DevOps流程

• 告警配置与资源池：为生产和开发环境分别配置告警策略和资源池，生产环境的告警应具有更高的优先级，资源池需确保高可用性，同样以名称相同的模式进行替换。

3. 上线与部署流程

为了确保生产环境的安全性，上线与部署需要经过严格的流程管理，可以采用以下方式：

• 导入导出方式（网络隔离）：

  • 在开发环境中完成工作流和任务的开发后，使用导出功能生成配置文件（Json或者Excel）。

  • 配置文件需经过其它内部审批，确保任务逻辑和资源配置符合生产要求。

  • 审批通过后，将导出的文件导入生产环境完成部署。

• 内置一键部署（网络联通）：

  • 如果开发和生产环境网络互通，可利用WhaleStudio的内置部署功能，将任务从开发环境直接迁移到生产。

  • 一键部署需结合查看改动（Diff）和审批流程，确保只有经过授权的任务可以上线。

4. 名称一致性管理

在上线和部署过程中，为了简化资源的迁移和管理，建议生产与开发环境中的资源使用一致的命名规则。包括但不限于以下资源：

• 定时器：如DailyJob-12:00，同一名称的定时器在不同环境中绑定不同的触发规则。

• 告警配置：如Dep1Email&SMSAlert，生产环境配置严格的通知规则，开发环境则可以使用模拟告警，不同告警组配置不同的规则，也可以邮件后同时短信告警，保持名称一致即可。

• 环境变量：如Python3，Python2，这样可以运行不同的Python环境。

• 资源池：如LowPriorityPool，给低优先级的任务共享一个资源池，有空闲的时候再运行相关任务等。

6. 安全与权限控制

生产环境的任务执行涉及敏感数据和核心业务逻辑，其安全性需作为重点关注对象：

• 权限隔离：可以单独设定角色，限制开发人员对生产环境的直接访问，仅授权运维和管理员进行操作。

• 只读访问：设定开发人员为在生产环境为类似来宾权限，无法运行只可以看日志和出错信息，重新运行则需要运维人员处理。

开发环境与生产环境的隔离与一致性设计是保障任务安全运行的关键，通过以上规范的实施，可以在WhaleStudio中实现开发环境与生产环境的高效隔离与协作。一方面保障生产环境的安全与稳定，另一方面也为开发环境提供了更高的灵活性和便利性，从而提升整个数据调度体系的可靠性与运维效率。

1.5 逻辑任务设计

逻辑任务是WhaleStudio中的核心任务类型之一，在ETL开发过程中用于协调多个任务的执行顺序和条件，是确保数据处理流程高效、灵活和可靠的关键部分。设计逻辑任务时，需要关注依赖管理、任务重用以及子工作流的合理应用，以提升整体系统的可维护性和可扩展性：

• 协调任务执行顺序：根据任务间的依赖关系，确保数据处理流程按照预定顺序执行，避免数据冲突或处理错误。

• 增强任务的灵活性：通过条件判断和分支逻辑，实现动态任务流转，满足复杂业务场景的需求。

• 简化任务管理：使用子工作流复用通用的任务模块，减少重复开发，提高系统的模块化水平。

逻辑组件WhaleStudio非常多，例如监控触发组件Trigger，循环组件dynamic，翻牌组件NextLoop，子工作流组件SubProcess，依赖组件Dependent等，这里和ETL与设计架构影响最大的就是依赖和子工作流组件, 以下是逻辑任务设计中的核心注意点和最佳实践，：

依赖任务的使用

依赖任务是逻辑任务中最基础的部分，用于定义任务间的执行顺序和约束条件，以下是设计依赖任务时需要注意的关键点：

1. 跨项目/跨工作流任务依赖关系：

   • 对于某个任务会跨项目/工作流依赖某几个任务或者某几个工作流提供支持。

   • 可以将工作流中的任务链路分为多个阶段（如ODS、DWD、DWS），确保逻辑清晰。

   • 复杂的有and or的这种依赖关系，可以使用依赖节点

2. 周期性依赖：

   • 对于某一个周期的任务依赖，例如，天的调度，依赖24小时24个任务都执行完成之后才可以执行，月的调度要等这个月所有工作日的调度完成才执行，这样避免月度任务只依赖某一个小时的任务而提前抢跑，数据出错。

3. 弱依赖与强制等待：

   • 对非关键任务设置，可以设置超时失败，然后运行标志选择失败继续，这样的效果就是一个弱依赖，等待超过这个时间就继续执行下一个操作，不等这个任务。

   • 强制等待可以把依赖策略设置失败等待，这样上游任务失败，这个等待任务不会失败，一直等待上游成功再继续运行，而选择失败失败，就是上游失败，本链路也失败，这样有利于告警和处理。依赖链重跑上游即可处理强依赖的项目。

子工作流任务的使用

子工作流任务是逻辑任务的重要扩展，用于封装一组具有独立功能的工作流成为本工作流当中的一个任务节点，便于重用和管理。在ETL开发中，子工作流主要发挥以下作用：

1. 模块化任务流设计：

   • 将常用的任务组（如数据质量校验、增量同步并进行特殊数据处理）设计为子工作流，在多个工作流中复用，减少重复开发。

   • 子工作流可以独立维护和调试，提高系统的可维护性。

2. 简化主工作流结构：

   • 在主工作流中，通过调用子工作流简化复杂的依赖链路，使主工作流更易于阅读和管理。

   • 子工作流的输入和输出应明确，避免因接口不清导致的任务失败。

3. 隔离任务失败影响：

   • 子工作流可以单独配置失败重试逻辑，避免单点失败影响整个主工作流。

   • 在需要时，可以单独重跑子工作流，提高问题修复效率。

4. 动态参数传递：

   • 支持在主工作流中向子工作流传递动态参数，满足灵活的任务调度需求。

   • 确保子工作流参数与主工作流解耦，增强可移植性。

下篇预告：《ETL 与 DataOps 开发命名规范》