ELT 这个词在数据工程圈里已经存在了 20 年但真正被大规模讨论、被写进数据平台架构其实是最近几年的事。很多人在接触现代数据栈时都会看到一句话ELT 正在取代 ETL。这个说法并不准确更合适的表述是ELT 从 20 年前的边缘方案变成了今天大多数云原生数据平台的首选。这篇文章不吹概念直接聊能落地的部分。我会先梳理 ELT 的核心能力、适用边界再用开源工具走一遍“抽取-加载-转换”的完整流程演示如何部署、如何同步、如何做批量任务最后给出资源占用观察、常见问题和排查清单。无论你是刚开始搭数据仓库还是准备把老 ETL 任务迁移到 ELT这篇文章都可以作为一份操作参考。1. ELT 核心能力速览能力项说明技术定位数据处理架构范式区别于传统 ETL强调“先加载后转换”核心流程Extract 抽取 - Load 加载 - Transform 转换主要优势充分利用目标数仓/数据湖计算能力减少中间层数据搬运适用环境云数仓、云数据湖、湖仓一体、MPP 数据库开源生态Airbyte、Meltano、Singer、Apache SeaTunnel、dbt 等部署方式Docker Compose、Kubernetes、命令行、Python 包接口能力多数开源 ELT 工具提供 REST API 或 CLI 入口批量任务支持定时同步、增量同步、断点续传、失败重试硬件门槛取决于目标数据平台本地测试一般需要 8G 以上内存适合场景数据仓库建设、数据湖入湖、日志采集、业务库镜像、报表分析底座需要说明的是ELT 不是一个单独可以安装的软件它是一条架构路线。实际落地时要组合使用“同步工具 转换工具 目标数据平台”。本文演示的是通用开源组合不绑定特定云厂商。2. 为什么说 ELT 走了 20 年20 年前也就是数据仓库刚普及的阶段大多数团队采用的是 ETL 流程先把数据从源端抽取出来在中间的转换服务器上完成清洗、关联、聚合再加载到目标数据库。这个流程在数据量不大、目标库计算能力有限的时代是合理的。但随着业务系统越来越多、数据量从 GB 涨到 TB 再到 PBETL 的问题开始暴露转换层服务器需要跟源系统和目标库同时保持高带宽数据搬运成本高。原始数据被提前加工后期想重新分析历史数据时需要重新抽取。数据模型变更时整条 ETL 链路都要跟着改维护成本很大。目标数仓往往性能比中间服务器更强但 ETL 架构里计算资源却被闲置。ELT 的思路正好反过来先把源数据完整加载到目标平台再用目标平台的计算引擎做转换。这样一来数据只搬运一次转换逻辑写在数仓内部数据和加工逻辑解耦。20 年里ELT 从少数公司的特殊做法逐步变成了云数仓和开源数据栈的默认选择。3. ELT 与 ETL 的对比对比项ETLELT处理顺序抽取 - 转换 - 加载抽取 - 加载 - 转换转换位置独立转换服务器或中间层目标数据库/数仓/数据湖内数据搬运次数多次中间产物多一次直接入湖入库存储方式通常只保存转换后结果先保留原始数据再按需加工扩展性受中间服务器性能限制依赖目标平台水平扩展能力成本需要单独维护转换集群把计算压力转移到数仓适用数据量中小规模大规模、原始数据长期留存建模灵活性建模前置改模型成本高建模后置可按需重跑典型工具组合Informatica、DataStage、KettleAirbyte、dbt、Snowflake/Databricks/ClickHouse从对比可以看出ELT 最大的收益不是“少写代码”而是改变了数据管线的信任模型。ELT 里目标数据平台始终有一份接近原始的数据副本任何一次转换失败都可以清掉重来不用重新从源端拉取。4. 适用场景与使用边界4.1 适合哪些场景ELT 比较适合下面几类情况业务数据入库后做报表和分析比如 MySQL、PostgreSQL、MongoDB 同步到 ClickHouse、StarRocks 或 Snowflake。数据湖建设需要长期保存原始日志与应用数据后续做批量分析和机器学习特征工程。多源数据汇聚比如把 CRM、订单、广告投放、用户行为日志统一同步到一个平台。数据模型频繁调整的阶段ELT 可以只改 SQL 模型不用重跑同步任务。团队有 SQL 能力但缺少 Java/Scala 工程能力ELT 把复杂的转换收敛进 SQL。4.2 不适合哪些场景ELT 也不是万能的强实时场景秒级或毫秒级延迟需求建议使用 CDC 流处理引擎而不是纯 ELT 批量同步。源端数据量极小但关系复杂ETL 在中间层做一次集中处理可能更简单。目标平台计算能力弱比如小型单机数据库把所有转换压到目标库反而更慢。敏感数据需要源端脱敏后才能离开源系统这种情况下不能简单“先加载后转换”。4.3 数据合规边界ELT 会把原始数据完整同步到目标平台。这意味着数据一旦离开源系统就需要重新确认访问控制、加密策略、脱敏规则与保存周期。涉及个人隐私、金融机构数据、用户行为日志时应在同步前完成字段级脱敏或先做必要的过滤。批处理任务里尤其要注意不要为了省事把全部字段原样同步到分析环境要建立最小必要原则。5. 环境准备与前置条件本地跑一套 ELT 演示环境不需要特别高配置但需要提前确认以下几项。5.1 操作系统与基础依赖操作系统Linux、macOS、Windows WSL2 均可。Docker建议安装 Docker Engine 20.10 以上和 Docker Compose v2。Python3.10 或 3.11用于安装 Singer 生态和 dbt。数据库客户端准备一个源数据库和一个目标数据库本地测试可选 PostgreSQL 和 ClickHouse。5.2 本地资源检查以下是通用检查项实际资源占用以容器和数据库配置为准# 查看系统内存 free -h # 查看磁盘空间 df -h # 查看 Docker 状态 docker version docker compose version如果同时启动源库、目标库、同步工具和调度器建议预留 8G 内存和 20G 磁盘。如果资源有限可以分步启动先只启动源库和目标库再启动同步工具。5.3 端口规划开源工具默认端口容易冲突启动前先检查ss -lntp | grep -E 8000|8080|5432|8123|9000如果端口被占用可以在容器映射时换成自定义端口比如把8000:8000改成18000:8000。6. 开源 ELT 技术栈部署示例下面用“PostgreSQL 作为源库ClickHouse 作为目标数仓Airbyte 作为同步工具dbt 作为转换工具”的组合演示 ELT 流程。这套组合不是唯一选择但流程清晰、组件都是开源方案适合用来理解 ELT 的完整路径。6.1 启动源库和目标库先创建一个 Docker 网络让组件之间可以直接通过容器名通信docker network create elt-demo启动 PostgreSQL 作为业务源库docker run -d \ --name postgres-source \ --network elt-demo \ -e POSTGRES_USERsource_user \ -e POSTGRES_PASSWORDsource_pass \ -e POSTGRES_DBsource_db \ -p 5432:5432 \ postgres:15启动 ClickHouse 作为目标数仓docker run -d \ --name clickhouse-target \ --network elt-demo \ -p 8123:8123 \ -p 9000:9000 \ clickhouse/clickhouse-server:24.8启动完成后先向源库写入一批测试数据。可以用 Docker 自带的 psql 执行docker exec -i postgres-source psql -U source_user -d source_db SQL CREATE TABLE orders ( id serial PRIMARY KEY, customer_id integer NOT NULL, amount numeric(10,2) NOT NULL, created_at timestamp NOT NULL DEFAULT now() ); INSERT INTO orders (customer_id, amount, created_at) SELECT (random() * 1000)::int, round((random() * 1000)::numeric, 2), now() - (random() * interval 30 days) FROM generate_series(1, 5000); SQL这一步的目的是制造一份可反复验证的数据集方便后面观察同步结果。6.2 启动 Airbyte 同步服务Airbyte 是目前比较主流的开源数据同步工具支持从数据库、API、文件等多种源头抽取数据并加载到数仓、数据湖等目标。本地测试可以用 Docker Compose 启动。先在空目录创建docker-compose.ymlversion: 3.8 services: airbyte-db: image: airbyte/db:0.50.32 container_name: airbyte-db environment: - POSTGRES_DBairbyte - POSTGRES_USERairbyte - POSTGRES_PASSWORDairbyte volumes: - airbyte_db_data:/var/lib/postgresql/data networks: - airbyte-network airbyte-server: image: airbyte/server:0.50.32 container_name: airbyte-server depends_on: - airbyte-db environment: - DATABASE_HOSTairbyte-db - DATABASE_PORT5432 - DATABASE_DBairbyte - DATABASE_USERairbyte - DATABASE_PASSWORDairbyte - LOG_LEVELINFO ports: - 8001:8001 networks: - airbyte-network volumes: - airbyte_server_data:/tmp/airbyte_local airbyte-webapp: image: airbyte/webapp:0.50.32 container_name: airbyte-webapp depends_on: - airbyte-server ports: - 8000:80 networks: - airbyte-network volumes: airbyte_db_data: airbyte_server_data: networks: airbyte-network: external: true name: elt-demo这里要把 Airbyte 容器接入前面创建的elt-demo网络才能直接连通 PostgreSQL 和 ClickHouse。不同版本的 Airbyte 镜像标签差异较大上面这段配置是演示模板实际使用时建议去官方文档获取当前版本对应的 compose 文件避免镜像标签过期。启动服务docker compose up -d docker compose ps启动后访问http://localhost:8000如果能看到 Airbyte 的 Web 界面说明同步服务已经就绪。实际登录密码和初始配置以 Airbyte Web UI 提示为准。6.3 使用 Singer 类命令行工具如果不想启动完整的 Web 服务也可以用 Singer 生态的命令行方式体验 ELT。Singer 把同步过程拆成 tap 和 target前者负责抽取后者负责加载。例如pip install pipelinewise-tap-postgresql target-jsonl准备源配置source.json{ host: localhost, port: 5432, user: source_user, password: source_pass, dbname: source_db, tap: postgresql }准备目标配置target.json{ destination_path: ./output }执行同步tap-postgresql --config source.json | target-jsonl --config target.json这段命令会把 PostgreSQL 里的数据抽取成 JSONL 文件。实际包名和参数会随版本不同这里主要用于说明 ELT 的“抽取-加载”阶段可以通过简单的管道命令完成。6.4 使用 dbt 完成转换数据加载到目标数仓后转换层交给 dbt。dbt 的核心是让用户用 SQL 定义模型dbt 负责在目标平台上执行这些 SQL。创建一个最小 dbt 项目pip install dbt-postgres dbt-clickhouse dbt init elt_demo编辑dbt_project.ymlname: elt_demo version: 1.0.0 config-version: 2 profile: elt_demo model-paths: [models] target-path: target clean-targets: [target, dbt_packages] models: elt_demo: staging: materialized: view mart: materialized: table在models/mart/daily_orders.sql中写转换逻辑SELECT toDate(created_at) AS order_date, count(*) AS order_count, sum(amount) AS total_amount FROM {{ ref(stg_orders) }} GROUP BY toDate(created_at) ORDER BY order_date这里假设已经有一个stg_orders模型描述了同步到 ClickHouse 的订单表。dbt 会通过 profile 连接目标库并执行 SQLdbt run跑完后可以在目标数仓查询结果表daily_orders。这样一套流程就完整走完了“抽取 - 加载 - 转换”。7. ELT 同步流程功能测试7.1 测试基础抽取加载在 Airbyte Web UI 中创建 PostgreSQL 数据源、ClickHouse 目标然后建立连接。手动触发一次同步后到 ClickHouse 检查表是否生成、行数是否正确docker exec -it clickhouse-target clickhouse-client --query SELECT count(*) FROM orders如果行数与源库一致说明抽取加载链路正常。判断标准的顺序是连接测试通过、同步任务成功、目标表行数匹配、字段类型可被目标库识别。7.2 测试增量同步ELT 生产环境最常用的是增量同步。先修改源库里的订单数据再触发一次增量同步INSERT INTO orders (customer_id, amount, created_at) VALUES (888, 199.99, now());Airbyte 会在源表主键或updated_at字段上记录游标。第二次同步完成后目标库行数应该只增加新增数据。如果目标库行数翻倍说明没有正确配置主键或游标字段需要回到连接配置里检查。7.3 测试转换层幂等性在 dbt 中重复执行dbt run结果表行数不应该翻倍因为 dbt 的表模型默认会重建整张表而不是增量插入。这是判断 ELT 转换模型是否规范的重要标准。dbt run dbt run运行两次后如果数据翻倍说明模型没有写好幂等逻辑。生产环境要求在重复执行时不产生脏数据。7.4 测试数据质量在 dbt 模型里加入测试version: 2 models: - name: daily_orders columns: - name: order_date tests: - not_null - name: order_count tests: - positive_values执行dbt test测试通过后说明转换层的字段结构符合预期。ELT 里数据质量测试应该和同步流程集成而不是靠人工抽查。8. ELT 接口与批量任务调度8.1 通过 API 触发同步任务Airbyte 的 Server 组件会暴露 REST API可以用来创建数据源、目标、连接和触发同步。不同版本接口路径会有差异下面是一个通用调用示例# 替换为实际 host 和 connection_id curl -X POST http://localhost:8001/api/v1/connections/sync \ -H Content-Type: application/json \ -d {connectionId: your-connection-id}这是一个演示请求实际字段名以 Airbyte OpenAPI 定义为准。如果接口版本不匹配返回 404 或 422 时先查看服务日志确认接口路径。8.2 用 Python 封装同步调用import requests BASE_URL http://localhost:8001/api/v1 connection_id your-connection-id def trigger_sync(connection_id: str) - dict: resp requests.post( f{BASE_URL}/connections/sync, json{connectionId: connection_id}, timeout30, ) resp.raise_for_status() return resp.json() if __name__ __main__: result trigger_sync(connection_id) print(result)调用成功后再去查询目标库确认数据已经写入。这里的重点是把“同步”变成可编程操作为批量调度打基础。8.3 批量任务调度ELT 批量任务通常用 Apache Airflow 或 Dagster 编排。下面以 Airflow 为例把“同步 转换”串成一条每日执行的 DAGfrom datetime import datetime from airflow import DAG from airflow.operators.bash import BashOperator from airflow.operators.python import PythonOperator default_args { owner: data, retries: 1, retry_delay: 300, } with DAG( dag_idelt_daily, schedule0 2 * * *, start_datedatetime(2025, 1, 1), catchupFalse, default_argsdefault_args, ) as dag: sync_data BashOperator( task_idsync_source_to_warehouse, bash_commandcurl -X POST http://airbyte-server:8001/api/v1/connections/sync, ) run_dbt BashOperator( task_idrun_dbt_models, bash_commandcd /opt/elt_demo dbt run dbt test, ) sync_data run_dbt这个 DAG 每天凌晨 2 点先触发同步再执行 dbt 转换和测试。批量任务的要点不是简单地循环调用而是要有重试、日志、失败告警和幂等保障。9. 资源占用与性能观察9.1 如何观察资源占用ELT 的资源占用主要分三块同步工具本身、目标数仓、转换任务。# 查看容器 CPU 和内存 docker stats --no-stream # 查看历史容器日志 docker logs airbyte-server --tail 200 # 查看目标库正在执行的查询 docker exec -it clickhouse-target clickhouse-client \ --query SELECT query, elapsed FROM system.processes如果同步任务吃满 CPU通常不是目标库性能问题而是源端查询没有走索引或全表扫描。转换任务耗时高时要定位到具体 SQL 模型分析是否缺少分区裁剪或聚合下推。9.2 影响 ELT 性能的因素影响 ELT 性能的因素比较多常见的有源端抽取 SQL 是否使用增量条件全表同步只适合第一次。目标库分区键选择是否合理分区不合理会导致写入放大。转换模型是否存在重复扫描同一张表。批量条数、连接池大小、网络带宽是否成为瓶颈。数据倾斜比如某个客户的数据量特别大导致单分片热点。9.3 如何降低资源消耗第一次同步做全量之后全部走增量。在目标库设计合适的分区键和排序键减少查询扫描范围。dbt 层级分 staging、intermediate、mart避免大量 view 嵌套。把大任务的批次缩小先验证一个分区再跑全量。给批处理任务设置超时和重试次数避免任务卡死占住资源。10. 常见问题与排查方法下面列出的问题在 ELT 落地过程中出现频率较高按“现象、原因、排查、解决”四步整理。问题现象可能原因排查方式解决方案同步任务一直 pending连接数占满、容器内存不足docker stats查看资源扩大内存限制调大连接池目标表行数比源表多主键未配置重复同步对比源主键和目标表去重逻辑配置主键改用 upsert 策略增量同步没有新数据游标字段选择错误查看源表是否有 updated_at选择合适游标或启用 CDCClickHouse 中日期字段异常时区没有统一对比源时间和目标时间在抽取阶段指定时区统一为 UTCdbt run 失败目标库用户权限不足查看 dbt logs授予对应 schema 的读写权限API 调用返回 404接口路径版本不匹配查看 API 文档和日志替换为当前版本路径批处理任务卡住某个同步子任务未结束查看进程和日志设置 task 超时时间增加失败重试数据量较大时内存飙升批量加载条数过大查看目标库写入参数降低 batch size分批写入排查时建议先看日志再看资源最后检查配置。ELT 链路里每个组件都会产生日志把日志规范到统一目录可以显著缩短定位时间。11. ELT 最佳实践11.1 数据分层设计ELT 的目标数仓内部建议分三层staging与源表结构基本一致只做加载和简单类型转换。core做清洗、去重、关联、维表加工形成企业级核心模型。mart面向报表和应用按业务主题进行聚合。分层的目的是把“加载”和“转换”彻底分开。staging 层保留原始数据core 层承担脏数据治理mart 层负责业务口径。11.2 增量策略和幂等生产环境一定要用增量同步但增量同步也会遇到源库数据修改历史变更的问题。稳妥的做法是有修改时间字段的表用updated_at作为游标。需要精确捕捉删除和更新的表用 CDC 模式。目标表写入时使用“先删分区再写入”或“upsert”的方式保证重复执行不产生重复数据。每次同步前记录批次号方便回滚和定位问题。11.3 流程自动化与告警ELT 任务建议全部走调度平台不要依赖手动点击。每个同步任务要配置失败重试次数。超时时间。行数波动告警。schema 变更通知。数据质量测试结果通知。这样即使凌晨任务失败也能在上班前收到告警而不是等用户发现报表数据不对。11.4 权限与数据安全ELT 把数据集中到一处后权限边界要重新梳理staging 表只允许数据工程师访问。mart 表按业务角色开放。敏感字段在同步前做脱敏或加密。目标平台的访问密钥不要写在明文配置里使用环境变量或密钥管理服务。日志里避免打印 SQL 参数和连接串。12. 总结ELT 20 年后的下一步ELT 走到今天已经不只是一个技术名词而是现代数据平台的基本设计思路。它最大的价值不是省掉一个转换步骤而是让数据在目标平台里保持“原始 可重算”的状态业务口径变化时重建模型就能完成不用重新从源端抽取。如果你刚开始接触 ELT先别急着上复杂工具。用 Docker 跑一个源库、一个目标数仓再用 Airbyte 或 Singer 完成抽取和加载最后用 dbt 写一个简单的 SQL 模型跑通整条链路。这个最小闭环跑通后再考虑增量同步、CDC、调度编排和告警。最容易踩的坑有三个第一把 ELT 当成 ETL 的另外一个名字转换还放在中间层第二增量同步没配主键跑几次数据就重复了第三staging 层没有保留原始数据导致后期无法回溯。把这三点避开ELT 的回报会非常明显。更远的方向是流批一体让 ELT 的“加载”阶段支持实时写入转换层仍然用 SQL 模型处理这样批处理和实时链路共用同一套口径。20 年过去ELT 正在从“先加载再转换”的简单理念长成一套完整的数据工程方法轮。这个方向值得持续关注。