企业官网建设流程全解析

1. 这不是选工具，是选生产系统的“神经中枢”

你手头正跑着一批每天要处理上TB日志的ETL流水线，凌晨三点告警弹窗跳出来——某个关键数据表没按时产出，下游BI看板全灰了。你翻着Airflow的DAG图，发现上游任务卡在S3权限错误上，而这个错误其实在两小时前就该被拦截；又或者你刚用Prefect写完一个带重试+回滚的金融对账流程，上线后发现调度延迟飙升，监控里全是Pending状态；再或者团队吵了两周：到底该用Dagster做数据质量闭环，还是用Temporal管跨服务的订单履约长事务？这些都不是“哪个工具语法更顺手”的问题，而是你的整个数据/业务系统能否稳如磐石、可查可控、能快速响应变化的底层命脉。

长任务编排——这个词背后压着的是真实生产环境里的三座大山：时间跨度动辄数小时甚至数天的任务链（比如训练一个大模型、生成月度财务报告）、状态必须精确追踪的复杂依赖（比如“只有当风控审核通过且库存校验完成，才触发发货”）、以及故障时能精准定位、手动干预、甚至逆向补偿的操作能力。Airflow、Prefect、Dagster、Temporal，它们根本不是同一类东西的四个选项，而是四套不同哲学体系下生长出来的“神经系统”：Airflow是靠周期性轮询和强调度器驱动的“中央集权制”；Prefect是把任务逻辑和执行解耦、靠事件驱动的“联邦自治体”；Dagster是把数据资产和计算逻辑深度绑定的“数据契约型组织”；Temporal则是把任意代码片段都封装成可持久化、可重放、带完整状态快照的“原子化工作单元”。选错，轻则天天救火，重则架构返工、数据资不抵债。我过去三年在三家不同规模公司落地过这四套系统，踩过的坑、调优的参数、深夜改配置的截图，今天全摊开讲清楚——不谈虚的“特性对比表”，只说你在生产环境里真正会遇到的每一个具体场景、每一个决策点背后的血泪教训。

2. 四套系统的核心设计哲学与真实生产约束

2.1 Airflow：调度器即真理，一切围绕“可预测的周期性”构建

Airflow的本质，是一个高度结构化的、以DAG为蓝图的、中心化调度引擎。它的DNA里刻着“确定性”三个字——所有任务必须有明确的start_date、schedule_interval、retries、timeout，所有依赖必须静态声明在DAG定义里。它假设世界是可预测的：上游任务总会在预期时间内完成，资源永远够用，网络永远稳定。这种假设在批处理场景下极其高效，但一旦进入长任务、不确定性高的领域，它的骨架就开始咯吱作响。

提示：Airflow不是不能跑长任务，而是它的“心跳机制”天然不适合。默认scheduler每30秒扫描一次数据库找待执行任务，如果一个任务运行8小时，这期间scheduler要持续维护它的状态、检查心跳、处理可能的超时。实测下来，当集群中同时存在超过500个长时间运行（>2小时）的任务时，PostgreSQL的pg_stat_activity里会出现大量idle in transaction连接，CPU负载飙升，scheduler开始丢任务。这不是配置问题，是架构使然。

它的核心约束来自三处：

• 状态存储瓶颈：所有任务状态、日志、XCom（小数据传递）全压在元数据库（通常是PostgreSQL或MySQL）。当单个DAG每分钟产生上千次task instance记录时，数据库I/O成为绝对瓶颈。我们曾为一个实时风控DAG单独配了一台32核64G的PostgreSQL，只为扛住每秒200+的INSERT压力。
• Executor的天花板：CeleryExecutor虽能水平扩展worker，但broker（如RabbitMQ）和result backend（如Redis）会成为新瓶颈；KubernetesExecutor虽灵活，但每个task启动一个Pod的开销，在高频短任务场景下尚可，在长任务场景下反而浪费资源——一个跑8小时的Pod，你真的需要它每分钟都向K8s API Server汇报一次心跳吗？
• 可观测性盲区：UI里看到的“Running”状态，本质是scheduler根据last_state_change_time和heartbeat判断的。如果worker进程卡死但没退出，scheduler可能要等timeout（默认1小时）才标记为failed，而这期间下游任务永远无法启动。

所以Airflow真正的舒适区，是有严格SLA、输入输出可预期、失败模式相对固定的批处理流水线。比如每天凌晨2点跑的电商销售报表，数据源固定、SQL逻辑稳定、耗时波动在±15分钟内——这时Airflow的DAG版本管理、清晰的依赖视图、成熟的插件生态（如aws-airflow、snowflake-airflow），就是无可替代的生产力。

2.2 Prefect：任务即代码，状态由开发者完全掌控

Prefect（尤其是v2.x）彻底抛弃了“调度器中心化”的思路，转而拥抱事件驱动 + 状态机 + 开发者显式控制。它的核心理念是：“任务（Task）”和“流程（Flow）”本身就是Python函数，它们的生命周期、重试策略、失败回调、状态转换，全部由代码定义，而不是靠外部调度器轮询。Prefect Server或Prefect Cloud只是提供状态存储、API和UI，真正的决策权在你的代码里。

注意：Prefect的“动态任务生成”不是炫技。比如你有一个清洗N个客户分片的任务，传统Airflow得提前写好N个task，而Prefect里你可以写一个loop，每次迭代生成一个task实例，并给每个实例绑定独立的retry策略（比如第1片重试3次，第5片因数据敏感只允许重试1次）。这种灵活性在处理异构数据源时，省下的DAG维护成本远超学习曲线。

它的生产优势体现在：

• 无状态调度器：Prefect Agent（部署在K8s或VM上）只负责监听API事件、拉取待执行的Flow Run、启动执行器。Agent本身不维护任何状态，挂了重启即可，零数据丢失风险。
• 细粒度状态控制：每个Task可以定义自己的on_failure、on_completion钩子，直接调用Slack webhook、更新数据库、甚至触发另一个Flow。我们曾用此实现“当某支付对账任务失败时，自动创建Jira ticket并分配给对应银行接口负责人”，整个链路毫秒级响应。
• 本地调试即生产：Prefect Flow可以在本地Python环境直接.run()，所有日志、状态、重试逻辑与生产环境完全一致。这消灭了“本地跑通，线上报错”的经典陷阱。我们CI/CD流程里，强制要求每个Flow PR必须通过本地prefect run测试，否则不合并。

但它的代价是心智负担转移：你不再依赖调度器的“智能”，而必须自己写清楚“什么条件下重试”、“失败后如何降级”、“状态如何持久化”。Prefect的文档里有一句大实话：“We don’t hide complexity, we make it explicit.” 这对资深工程师是福音，对刚毕业的新人，可能意味着第一周都在debug状态机流转。

2.3 Dagster：数据资产即契约，编排是数据流的自然延伸

Dagster的出发点非常纯粹：数据工程不是写一堆脚本让它们按顺序跑，而是定义数据资产（Asset）之间的依赖关系，并确保每次计算都产生符合预期的数据。它把“编排”从“任务执行顺序”升维到“数据血缘与质量契约”。

实操心得：Dagster的Asset Sensor不是“监控某个表有没有数据”，而是“当asset A的materialization成功后，自动触发依赖它的asset B的计算”。这意味着，你的调度逻辑和数据schema、业务规则深度耦合。比如，风控模型训练完成（assetrisk_model_v2materialized），自动触发下游所有使用该模型的评分服务（assetsuser_score_v2,merchant_risk_v2）更新——这种基于数据就绪而非时间的触发，才是真正的事件驱动。

它的核心生产价值在于数据可信度闭环：

• Materialization作为事实：每次计算结果必须写入一个明确的storage（S3/DB），并记录metadata（行数、null率、schema hash）。UI里点开一个asset，能看到它所有的materialization历史、每次的输入输出、甚至diff对比。
• Partitioned Asset的威力：处理按天分区的日志？Dagster让你定义partition_key="2024-06-15"，然后所有依赖它的下游asset自动按此key计算。无需手动拼接日期字符串，不会因时区错乱导致漏跑。
• Sensor驱动的自适应调度：一个sensor可以监听S3前缀、数据库CDC事件、甚至HTTP webhook。当上游数据湖目录出现新文件，sensor立刻触发对应asset的计算——比Airflow的ExternalTaskSensor可靠十倍，因为它是基于实际数据到达，而非猜测上游任务是否完成。

但Dagster的陡峭学习曲线在于范式转换。你得先想清楚“我的数据资产有哪些？它们的输入输出契约是什么？哪些是source，哪些是derived？” 如果团队还在用“写SQL导出CSV”的思维，强行上Dagster，第一周就会陷入“我到底该定义几个asset？”的哲学辩论。它适合已经建立数据治理规范、有明确数据产品Owner的团队。

2.4 Temporal：把任意代码变成“可持久化、可重放、带状态的原子操作”

Temporal是这四者中唯一一个不关心你跑的是Python、Java、Go还是Shell脚本，也不预设你是在做ETL还是处理用户订单的系统。它的核心抽象只有一个：Workflow Execution。一个Workflow就是一个长期运行的、状态可持久化的、能跨机器/进程/重启存活的“程序实例”。

关键理解：Temporal的Workflow不是“任务”，而是“状态机”。你写的代码里，workflow.sleep(3600)不是让线程睡一小时（那会阻塞），而是向Temporal Server发送一条“请在一小时后唤醒我”的指令，当前Workflow状态（包括所有局部变量）被序列化存入Cassandra/PostgreSQL。一小时后Server唤醒它，恢复所有状态，继续执行。这意味着，哪怕你的Workflow跑了72小时，中间Temporal Server重启10次，它依然能精准续跑，毫秒级误差。

它的不可替代性体现在超长事务与跨系统协调：

• Saga模式原生支持：处理一个订单，需要调用库存、支付、物流三个外部系统。Temporal让你用executeActivity串行调用，每个Activity失败时，自动触发对应的compensateActivity（比如支付失败，就调用库存回滚接口）。整个Saga的原子性、一致性，由Temporal的持久化状态机保证，你不用手写分布式事务框架。
• 信号（Signal）与查询（Query）：正在运行的Workflow，可以随时接收外部信号（如“暂停发货”、“升级VIP等级”），也可以被实时查询当前状态（如“订单履约进度：已支付，待发货，预计2小时后出库”）。这是Airflow/Prefect/Dagster都做不到的——它们的状态是离散的（success/failed），而Temporal的状态是连续的、可交互的。
• Worker的极致轻量：Temporal Worker只是一个长连接客户端，负责拉取任务、执行代码、上报结果。它不存状态、不管理依赖、不解析DAG。一个Worker进程可以同时处理1000个并发Workflow，资源消耗极低。

代价是开发模式颠覆：你不能再写time.sleep()，不能依赖全局变量，所有状态必须通过workflow.getState()/workflow.setState()管理。第一次写Temporal Workflow的人，常犯的错误是把数据库连接对象存进state——这会导致反序列化失败。它要求你用“函数式编程”思维写有状态程序，门槛最高，但一旦掌握，在金融、IoT、游戏等强状态业务场景，就是降维打击。

3. 生产环境选型决策树：从场景反推技术栈

3.1 场景一：企业级数据平台，核心诉求是“数据可信、血缘清晰、变更可追溯”

典型画像：已有成熟数据湖/仓，数据团队50+人，按域划分（用户域、交易域、风控域），有专职数据产品经理，SLA要求99.95%数据准时产出，审计要求所有数据加工逻辑可回溯到Git commit。

首选Dagster，次选Prefect。

为什么Dagster是首选？

• Asset Catalog即数据目录：Dagster UI自动生成的Asset Catalog，直接对接公司数据目录系统（如Atlan、Collibra）。一个业务方在Catalog里点开“GMV日报”，能看到它依赖哪些上游表、由哪个DAG计算、最近三次materialization的耗时与数据质量指标（如空值率<0.1%）。这种“所见即所得”的数据信任，是Airflow的Graph View永远给不了的。
• Backfill的确定性：补跑2023年全年的销售数据？Dagster的dagster backfill命令会精确计算所有缺失的partition，生成一个带优先级的execution plan，并发控制、失败重试、资源隔离全部内置。而Airflow的backfill命令，面对海量partition时，常因scheduler过载导致部分任务卡死，最后还得人工介入。
• 权限与治理：Dagster支持基于Asset的RBAC（Role-Based Access Control）。数据科学家只能看到自己域的assets，数据平台团队可全局管理。我们曾用此实现“风控团队可编辑risk_scoreasset的计算逻辑，但无权修改user_profileasset”，彻底解决跨域数据污染问题。

Prefect作为备选，胜在开发者体验更平滑。如果你的团队Python功底扎实，但数据治理意识尚在建设中，Prefect的Flow-as-Code + 强大的testing framework（pytest无缝集成），能让团队快速交付高质量数据Pipeline，再逐步引入Asset概念。但要注意：Prefect的StatefulTask（类似Dagster Asset）是v2.10+才稳定的特性，生产环境务必确认版本兼容性。

实操避坑：Dagster部署千万别用dagster dev！它只是本地开发服务器。生产必须用dagster user-code+dagster api分离部署，否则worker进程崩溃会导致整个API不可用。我们吃过亏：一个buggy的asset导致worker OOM，连带UI打不开，运维半夜爬起来重启。

3.2 场景二：微服务架构下的业务流程编排，核心诉求是“跨服务事务一致性、人工干预通道、实时状态可见”

典型画像：电商/金融/SAAS平台，订单履约、退款、风控审批等流程横跨10+微服务，每个环节都有人工审核节点，业务方要求“随时知道订单卡在哪一步、为什么卡、谁能解”。

首选Temporal，次选Prefect（需重度定制）。

为什么Temporal是首选？

• Signal实现人工干预：一个订单卡在“人工审核”环节，运营同学在内部系统点击“通过”，系统后台调用temporal.signal_workflow("approve_review", workflow_id)，Workflow立即从await review_signal处唤醒，执行后续支付调用。整个过程毫秒级，无需重启、无需查数据库状态。
• Query提供实时状态：客服系统接入Temporal Query API，输入订单号，直接返回{"status": "review_pending", "reviewer": "zhangsan", "timeout_at": "2024-06-15T14:30:00Z"}。这比查MySQL再拼接状态字段，快10倍且绝对一致。
• Cron Workflow保活：对于需要“每5分钟检查一次支付结果”的长轮询场景，Temporal的@workflow_method(schedule_to_start_timeout=300)比Airflow的schedule_interval=timedelta(minutes=5)可靠得多——前者是Workflow自身发起的定时唤醒，后者依赖scheduler的精度和稳定性。

Prefect的备选方案，需用Task+StateHandler+ 自定义API模拟。比如，用@task(on_failure=send_slack_alert)捕获失败，再用@flow(on_failure=trigger_manual_review_flow)启动一个新Flow处理异常。但这本质上是在Prefect之上再造一个轻量Temporal，开发和维护成本远高于直接用Temporal。

实操避坑：Temporal的History Size是性能杀手。默认保留所有Event（Started, TaskScheduled, TaskCompleted...），一个运行72小时的Workflow可能产生数万Events。生产必须配置history_retention_period（建议7天）和visibility_retention_period（建议30天），并定期用tctl命令清理。我们曾因未配置，Cassandra磁盘爆满，整个集群不可用。

3.3 场景三：传统ETL/报表平台，核心诉求是“稳定、易维护、社区支持强、运维成本低”

典型画像：中小型企业，数据团队3-5人，主要跑SQL/Spark任务，目标是每天准时产出几十张报表，现有技术栈是Python+PostgreSQL+Airflow，老板只问“报表今天出了吗？”

首选Airflow，次选Prefect（v2.x）。

为什么Airflow仍是首选？

• 生态即生产力：airflow.providers.amazon.aws.operators.s3_list、airflow.providers.google.cloud.operators.bigquery.BigQueryExecuteQueryOperator……这些开箱即用的Operator，让你5分钟就能写出一个“从S3读Parquet、用BigQuery SQL聚合、结果存回S3”的DAG。Prefect虽有prefect-aws，但Operator粒度更粗，常需自己写@task封装。
• 运维心智成本最低：Airflow的Web UI、CLI、Logging、Alerting（Email/Slack）全部标准化。一个新来的运维，看懂airflow.cfg里的sql_alchemy_conn和executor，就能接手。而Temporal需要懂Cassandra/PostgreSQL调优，Dagster需要懂GraphQL API，Prefect需要懂Agent部署。
• 社区水位最深：Stack Overflow上关于Airflow scheduler not picking up tasks的问题，有37页答案；而Prefect v2 dynamic task generation error只有2页。这意味着，当你遇到冷门Bug，Airflow大概率已有解决方案。

Prefect作为备选，胜在现代Python体验。如果你的团队反感Airflow的DAG = Python file带来的全局变量污染（比如default_args被所有task共享），Prefect的@flow装饰器+@task分离，代码更干净。且Prefect Cloud的托管服务（免费版够用）省去了自建PostgreSQL/Redis的麻烦。

实操避坑：Airflow的max_active_runs_per_dag必须设！我们曾设为None（默认），一个DAG因上游数据延迟，积压了200+ pending runs，scheduler疯狂扫描，CPU 100%，其他DAG全部饿死。正确做法：按DAG SLA设置，比如“每小时跑一次的报表DAG，设为2；每天跑一次的ETL，设为1”。

3.4 场景四：探索性AI/ML平台，核心诉求是“实验快速迭代、资源弹性伸缩、失败低成本”

典型画像：AI Lab团队，每天跑上百个模型训练/评估实验，任务类型混杂（PyTorch、TensorFlow、HuggingFace），GPU资源紧张，需要按需申请、失败不心疼、结果可复现。

首选Prefect，次选Airflow（KubernetesExecutor）。

为什么Prefect是首选？

• Dynamic Task Graph天生适配实验：一个实验Flow里，load_data()->preprocess()->train_model(model_name="resnet50")->evaluate()。Prefect允许你在train_model里根据model_name参数，动态决定是否运行hyperparam_tune()子Flow。Airflow的DAG必须静态定义所有分支，写起来像在填Excel。
• Result Persistence直连对象存储：Prefect的ResultStorage可直接配置为S3，每个Task的output自动序列化存入<bucket>/prefect/results/<flow-run-id>/<task-name>/。复现实验？直接下载对应S3路径的pkl文件即可。Airflow的XCom最大1MB，存模型权重？门都没有。
• Agent + Kubernetes无缝：Prefect Agent部署为K8s Deployment，每个Task Run自动创建Job，GPU资源请求（resources={"gpu": "1"}）写在@task装饰器里，比Airflow的KubernetesPodOperator配置简洁10倍。

Airflow的备选方案，必须用KubernetesPodOperator+volume_mounts挂载S3FS，再用bash_command调用python train.py。配置复杂，且每次任务启动Pod的开销，在高频实验场景下，比Prefect的轻量Agent高30%以上。

实操避坑：Prefect的cache_key_fn是实验复现的灵魂。@task(cache_key_fn=lambda *args, **kwargs: f"{kwargs['model_version']}_{hashlib.md5(kwargs['data_path'].encode()).hexdigest()}")，确保相同参数+数据路径的任务，直接复用缓存结果。我们靠此将重复实验的GPU耗时从2小时降到3秒。

4. 落地实操：从零搭建一个生产级Temporal Workflow（含避坑清单）

4.1 环境准备：避开官方文档的“温柔陷阱”

Temporal官方Quickstart推荐用Docker Compose一键启动，这在Demo阶段很爽，但生产环境必须拆开部署。原因有三：

1. Cassandra集群无法用单节点Docker模拟：生产至少3节点，且需配置commitlog_directory到SSD盘，data_file_directories到大容量HDD。Docker Compose的volumes无法满足这种混合存储需求。
2. Frontend Service必须HTTPS：Temporal Web UI和API默认HTTP，生产必须前置Nginx或ALB配置TLS终止。官方文档对此轻描淡写，但没配HTTPS，Worker连接会报connection refused（实际是TLS握手失败）。
3. Visibility Store不能共用Cassandra：官方示例把visibility也存Cassandra，但生产中visibility（用于UI查询）的QPS远高于execution（核心状态），必须分离。我们用PostgreSQL做visibility，Cassandra做execution，性能提升4倍。

生产部署清单（K8s）：

• Cassandra StatefulSet：3副本，storageClassName: ssd-storage（commitlog），storageClassName: hdd-storage（data）。
• PostgreSQL Deployment：专用于visibility，shared_buffers: 2GB，work_mem: 64MB。
• Temporal Server Deployment：--dynamic-config-file /etc/temporal/config/dynamic.yaml，其中system.enableGlobalNamespace: true（启用多租户）。
• Nginx Ingress：ssl_certificate+ssl_certificate_key，proxy_pass http://temporal-frontend:7233。

关键配置：Temporal Server的numHistoryShards必须在集群初始化时定死，后期无法修改！计算公式：shards = max(100, ceil(peak_qps * 10))。我们预估峰值QPS 500，设为5000。设小了，后期扩容要全量迁移，停机8小时起步。

4.2 Workflow编写：从“写代码”到“写状态机”的思维切换

以一个简化的“用户注册验证”Workflow为例（含邮箱验证、短信验证、风控审核）：

# workflow.py import asyncio from temporalio import workflow, activity from temporalio.common import RetryPolicy from temporalio.exceptions import ApplicationError # 定义Activity（实际执行单元） @activity.defn async def send_email_verification(email: str) -> str: # 调用邮件服务API return f"email_sent_to_{email}" @activity.defn async def send_sms_verification(phone: str) -> str: # 调用短信服务API return f"sms_sent_to_{phone}" @activity.defn async def risk_review(user_id: str) -> dict: # 调用风控服务，返回{"approved": True, "reason": "low_risk"} return {"approved": True, "reason": "low_risk"} # 核心Workflow @workflow.defn class UserRegistrationWorkflow: @workflow.run async def run(self, user_id: str, email: str, phone: str) -> dict: # 步骤1：并发发送邮箱和短信验证码 email_task = workflow.execute_activity( send_email_verification, email, start_to_close_timeout=timedelta(seconds=30), retry_policy=RetryPolicy( maximum_attempts=3, initial_interval=timedelta(seconds=1), backoff_coefficient=2.0 ) ) sms_task = workflow.execute_activity( send_sms_verification, phone, start_to_close_timeout=timedelta(seconds=30), retry_policy=RetryPolicy( maximum_attempts=3, initial_interval=timedelta(seconds=1), backoff_coefficient=2.0 ) ) # 等待两者都完成（或超时） try: await asyncio.gather(email_task, sms_task, return_exceptions=True) except Exception as e: raise ApplicationError(f"Verification failed: {e}") # 步骤2：风控审核（串行，因依赖步骤1结果） review_result = await workflow.execute_activity( risk_review, user_id, start_to_close_timeout=timedelta(minutes=2), retry_policy=RetryPolicy( maximum_attempts=1, # 风控审核不允许重试 non_retryable_error_types=["RiskServiceUnavailable"] ) ) if not review_result["approved"]: raise ApplicationError(f"Risk review rejected: {review_result['reason']}") # 步骤3：激活用户（最终成功态） return {"status": "active", "user_id": user_id}

关键点解析：

• workflow.execute_activity不是同步调用，而是向Temporal Server发指令，由Worker异步执行。Workflow线程在此处挂起，状态保存，不消耗CPU。
• RetryPolicy的non_retryable_error_types必须精确匹配Activity抛出的Exception类名（如RiskServiceUnavailable），否则重试会无限循环。
• asyncio.gather实现并发，但注意：如果其中一个Activity失败，gather会抛出ExceptionGroup，需用return_exceptions=True捕获，否则Workflow直接failed。

4.3 Worker部署与扩缩容：让资源跟着流量走

Worker是Temporal的“肌肉”，它不存状态，只干活。生产部署要点：

• 多Worker进程分担负载：一个Worker进程默认只处理10个Workflow Execution并发（max_concurrent_workflow_task_pollers=10）。我们按CPU核数*2配置，32核机器启64个Worker进程。
• 按任务类型隔离Worker：创建多个Worker Group，email-worker只订阅email-activity，risk-worker只订阅risk-activity。避免风控审核慢拖垮邮件发送。
• K8s HPA自动扩缩：监控temporal_worker_task_queue_length指标，当队列长度>500，自动扩容Worker Pod。我们用Prometheus + K8s HPA，5分钟内从10个Pod扩到50个，流量高峰过后自动缩回。

实操避坑：Worker的identity必须唯一！同一个Worker进程，如果identity重复（比如用主机名，而K8s Pod重建后主机名不变），Temporal Server会认为它是旧Worker，拒绝分配新任务。正确做法：用uuid.uuid4().hex生成随机identity，或用Pod UID。

4.4 监控与告警：别等用户投诉才行动

Temporal的监控指标远超Airflow/Prefect，但必须配齐：

• Critical（P0）：temporal_history_host_task_queue_latency_bucket{le="1"} > 0.95（95%任务入队延迟>1秒），说明History Service过载，立即扩容。
• High（P1）：temporal_worker_task_queue_length > 1000（Worker队列积压），触发Worker扩容告警。
• Medium（P2）：temporal_history_host_persistence_errors_total > 10（持久化错误），可能是Cassandra写入失败，需查Cassandra日志。

UI里最常被忽略的诊断页：Visibility Search。输入WorkflowType = "UserRegistrationWorkflow" AND StartTime > "2024-06-15T00:00:00Z"，能查到所有运行中的Workflow，点进去看HistoryTab，每一行Event（WorkflowTaskStarted, ActivityTaskScheduled...）的时间戳，精准定位卡点。比如发现ActivityTaskStarted和ActivityTaskCompleted之间隔了10分钟，那问题一定在Activity代码或下游服务，和Temporal无关。

5. 常见问题速查表与独家避坑指南

最后分享一个小技巧：无论选哪个工具，在第一个Production DAG/Flow/Workflow里，必须包含一个health_checkTask/Activity。它不做任何业务，只检查：1. 能连上核心数据库；2. 能写入对象存储；3. 能调用基础API。这个Task的成功率，就是你整个编排系统的健康晴雨表。我们把它放在所有DAG的起点，监控它的成功率，低于99.5%自动告警——这比监控Scheduler CPU有用100倍。

我在实际落地中发现，工具选型争论90%源于“没想清楚问题本质”。当你说“我们要一个编排工具”，先问自己：

• 这个流程里，最怕什么？是数据不准（选Dagster），是事务不一致（选Temporal），是半夜被叫醒（选Airflow的成熟告警），还是实验跑不通（选Prefect的本地调试）？
• 谁来维护它？是DBA（Airflow），是数据科学家（Prefect），是数据平台工程师（Dagster），还是后端架构师（Temporal）？
• 未来半年，最大的不确定性在哪？是数据源暴增（Prefect动态Task），是业务流程剧变（Temporal Signal），是审计要求提高（Dagster Asset Catalog），还是SLA越来越严（Airflow Executor调优）？

答案清晰了，工具自然浮现。那些纠结“语法哪个更优雅”的讨论，都是在回避真正的难题。