ETL 架构：asapBI、Trino、Spark、Airflow，适用于数据工程师

# ETL 架构：asapBI 如何统一 Trino、Spark 和 Airflow 的单一界面

asapBI 平台提供了一种简化的 ETL 流程设计方式，通过单一界面协调 Trino、Spark 和 Airflow 等工具——无需绑定任何供应商。它能自动生成常规任务的代码，同时允许手动调整复杂任务，并支持本地开发与无缝同步。

asapBI 统一界面的工作原理

asapBI 的核心理念是为分散在各系统中的资源提供单一控制点。这将原本孤立的数据模型和 ETL 流程紧密连接。界面是可选的：移除它，系统仍能运行，但配置会变得繁琐。平台的架构以编排为中心，asapBI 作为中央枢纽，与外部集群和数据库交互。

系统满足的关键需求：

• 对于简单流程（如表间数据迁移），使用拖拽式字段映射，覆盖约 90% 的日常任务。
• 复杂工作流需手写 SQL、Python、Java、Scala 或 R 代码。
• 重量级计算在 Trino、Spark 或 Impala 等外部集群上运行，实现存储与计算分离。
• 所有加载任务从一处管理，简化监控。
• 支持离线开发：无需联网本地工作，然后同步变更。
• 仅使用开源组件，避免供应商锁定，便于维护。

创建和配置数据传输流程 (DTP)

asapBI 中 ETL 的基本构建块是 DTP（数据传输流程）——一种从其他表填充目标表的算法，可能跨不同数据库。从创建 DTP 开始，通过图形界面设置字段映射。它处理如 Greenplum 到 ClickHouse 的数据迁移，使用 Trino 或 Spark 作为执行引擎。

配置完成后，将 DTP 部署到 Airflow 编排器。asapBI 连接 Airflow，后者可将任务传递给 Spark 集群。选择实现语言：Spark 用 SQL 或 Python。生成的代码可在 代码标签页查看和编辑，确保完全透明。

Spark DTP 的自动生成 Python 代码示例：

# Spark 中 DTP 的生成代码示例
from pyspark.sql import SparkSession
spark = SparkSession.builder.appName("DTP_Example").getOrCreate()
df_source = spark.read.format("jdbc").option("url", "jdbc:postgresql://host/db").option("dbtable", "source_table").load()
df_target = df_source.selectExpr("col1", "col2", "col3")
df_target.write.format("jdbc").option("url", "jdbc:clickhouse://host/db").option("dbtable", "target_table").mode("overwrite").save()

保存 DTP 到 Airflow 会自动创建可运行的 DAG。通过 Airflow UI 或 asapBI 启动和调试这些 DAG，同时跟踪运行日志。

编排加载链和工作流管理

将 DTP 串联成工作流，在 Airflow 中即为 DAG。简单链通过向任务树添加 DTP 构建。对于条件、循环或高级逻辑，手动编辑自动生成的 DAG 代码。

Airflow 的优势在于并行运行多个 DAG，实现：

• 通过并行独立步骤加速加载。
• 失败任务自动或手动重试，不中断整个链条。
• 真正的流程独立性。

没有 Airflow 或 Dagster 等编排器？asapBI 可部署到您选择的数据库，自动生成运行 DTP 的函数。代码也可编辑以增加灵活性。

关键要点

• asapBI 提供用户友好的界面，基于开源工具编排 ETL，避免供应商锁定。
• 自动生成常规任务代码，但允许手动编辑复杂场景。
• 离线开发和本地测试无缝同步。
• 从单一仪表板监控和管理一切。
• 无黑盒：始终可查看和调整生成代码。

ETL 的未来与 AI 在数据工程中的角色

随着 AI 进步，传统 ETL 和数据模型面临质疑。理论上，将一切存入数据湖屋，让 AI 直接分析洞察——无需仪表板。但 asapBI 当前聚焦自动化如字段透传的苦力活，将复杂逻辑留给工程师。在 AI 能自主处理数据前，asapBI 等工具仍是结构化和编排 ETL 的关键。

— Editorial Team