共计 5873 个字符，预计需要花费 15 分钟才能阅读完成。
提到数据处理，常常有人把它简称为“ETL”。但认真说来，数据处理经验了 ETL、ELT、XX ETL（例如，Reverse ETL、Zero-ETL）到当初风行的 EtLT 架构几次更迭。目前大家应用大数据 Hadoop 时代，次要都是 ELT 形式，也就是加载到 Hadoop 里进行解决，然而实时数据仓库、数据湖的风行，这个 ELT 曾经过期了，EtLT 才是实时数据加载到数据湖和实时数据仓库的规范架构。
本文次要解说下几个架构呈现的起因和善于的场景及优缺点，以及为什么 EtLT 逐渐取代了 ETL、ELT 这些常见架构，成为寰球支流数据处理架构，并给出开源实际办法。
ETL 时代（1990-2015）
在数据仓库晚期时代，数据仓库提出者 Bill Inmmon 把数据仓库定义为分主题的存储和查问的数据存储架构，数据在存储时就是按主题分门别类荡涤好的数据。而理论状况也如此，大部分数据源是架构化数据源（例如，mysql、Oracle、SQLServer、ERP、CRM 等等），而作为数据集中处理的数据仓库大部分还是以 OLTP 时代查问和历史存储为主的数据库（DB2、Oracle），因而数据仓库在面对简单 ETL 解决时并不得心应手。而且这些数据库购买老本都比拟高，解决性能较弱，同时，各种各样的软件数据源越来越多。为了更不便地整合简单的数据源、分担数据计算引擎累赘、大量的 ETL 软件呈现，大家耳熟能详的 Informatica、Talend、Kettle 都是那个年代的典型软件产品，很多软件至今还在很多企业的传统架构当中配合数据仓库应用。
长处：技术架构清晰、简单数据源整合顺畅、ETL 软件分担靠近 50% 的数据仓库工作
毛病：所有解决都由数据工程师实现，业务需要满足工夫较长；硬件老本简直投入双份，数据量大时硬件老本过高
在数据仓库晚期和中期，数据源复杂性比拟高的时候，ETL 架构简直成为行业标准风行了 20 多年。
ELT 时代（2005-2020）
随着数据量越来越大，数据仓库的硬件老本与 ETL 硬件老本双向增长，而新的 MPP 技术、分布式技术呈现导致在数据仓库中后期和大数据衰亡时代，ETL 的架构逐渐走向 ELT 架构。例如，当年数据仓库最大厂商 Teradata、至今风行的 Hadoop Hive 架构，都是 ELT 架构。它们的特点就是，将数据通过各种工具，简直不做 join,group 等简单转化，只做标准化（Normolization）间接抽取到数据仓库里数据筹备层（Staging Layer），再在数据仓库中通过 SQL、H-SQL，从数据筹备层到数据原子层（DWD Layer or SOR Layer）；前期再将原子层数据进入汇总层（DWS Layey or SMA Layer），最终到指标层（ADS Layer or IDX Layer）。尽管 Teradata 面向的结构化数据，Hadoop 面向非结构化数据，但寰球大数据和数据仓库简直用的同一套架构和方法论来实现 3 - 4 层数据存储架构。
长处：利用数据仓库高性能计算解决大数据量解决，硬件 ROI 更高；同时，简单业务逻辑能够通过 SQL 来用数据分析师和懂业务逻辑的技术人员来解决，而无需懂 ETL(如 Spark, MapReduce)升高数据处理人员总成本。
毛病：只实用于数据源比较简单、量比拟大的状况，面对简单的数据源显著解决形式有余；同时间接加载，数据筹备层到数据原子层简单度过高，无奈通过 SQL 解决，往往利用 Spark、MapReduce 解决，而数据反复存储率较高；无奈反对实时数据仓库等需要。
面对 ELT 的数据仓库无奈加载简单数据源，实时性比拟差的问题，已经有一个过渡性解决方案被各种公司办法采纳，叫做 ODS（Operational Data Store）计划。将简单的数据源通过实时 CDC 或者实时 API 或者短时间批量（Micro-Batch）的形式 ETL 解决到 ODS 存储当中，而后再从 ODS ELT 到企业数据仓库当中，目前，还有很多企业采纳此种形式解决。也有局部企业，把 ODS 搁置在数据仓库当中，通过 Spark、MapReduce 实现后期的 ETL 工作，再在数据仓库（Hive、Teredata、Oracle、DB2）当中实现前期的业务数据加工工作。
其实此时，EtLT 初期的人群曾经造成，它的特点是人群划分开，简单的数据抽取、CDC、数据结构化、规整化的过程，往往由数据工程师实现，咱们叫做小“t”，它的指标是从源零碎到数据仓库底层数据筹备层或者数据原子层；而简单的带有业务属性的数据原子层到数据汇总层到数据指标层的解决（带有 Group by、Join 等简单操作）往往是善于应用 SQL 的业务数据工程师或者数据分析师来解决。
而 ODS 架构的独立我的项目也随着数据量级变大和 EtLT 架构的呈现逐渐淡出历史舞台。
EtLT（2020- 将来）
EtLT 的架构是由 James Densmore 在《Data Pipelines Pocket Reference 2021》中总结提到的一个古代寰球风行的数据处理架构。EtLT 也是随着古代数据架构（Modern Data Infrastructure）变动而产生的。
EtLT 架构产生的背景
古代数据架构架构有如下特点，导致 EtLT 架构呈现：
- 云、SaaS、本地混合简单数据源
- 数据湖与实时数据仓库
- 新一代大数据联邦(Big Data Federation)
- AI 利用大暴发
- 企业数据社群（Data Community）决裂
简单数据源呈现
当初寰球企业运行当中，除了传统的软件、数据库之外，云和 SaaS 的呈现将本曾经很简单的数据源状况更加简单，于是面对 SaaS 的解决，北美企业提出了新的数据集成（Data Ingestion）的概念，例如 Fivetran，Airbyte，以解决 SaaS 数据进入数据仓库（例如 Snowflake）当中的 ELT 问题，它是传统 ELT 架构在 SaaS 环境下的降级。而云端数据存储（例如，AWS Aruroa，AWS RDS，MongoDB Service 等）和传统线下数据库与软件（SAP、Oracle、DB2 等）在混合云架构（Hybrid Cloud）也在迅速减少数据源复杂性。传统的 ETL 和 ELT 架构就无奈满足如此简单环境的数据源解决。
数据湖与实时数据仓库
在古代数据架构环境下，数据湖的呈现交融了传统的 ODS 和数据仓库的特点，它能够做到贴源的数据变更和实时数据处理（例如 Apache Hudi, Apache Iceberg，Databricks Delta Lake），针对传统的 CDC（Change Data Capture）和实时数据流计算都做了数据存储构造变动（Schema Evolution）和计算层面的反对。同时，实时数据仓库理念呈现，很多新型计算引擎（Apache Pinnot、ClickHouse、Apache Doris）都将反对实时 ETL 提上日程。而传统的 CDC ETL 软件或者实时计算流计算（Datastream Computing）对于数据湖和实时数据仓库的反对，要么是在新型存储引擎反对要么是在新型数据源连贯方面存在很大问题，不足很好的架构和工具反对。
新一代大数据联邦
在古代数据架构当中还有一种新型架构呈现，它们以尽可能减少数据在不同数据存储间流动，间接通过连接器或者疾速数据加载后间接提供简单数据查问而见长，例如 Starburst 的 TrinoDB（前 PrestDB）和基于 Apache Hudi 的 OneHouse。这些工具都以数据缓存以及即席跨数据源查问为指标，各种 ETL、ELT 工具亦无奈撑持新型的 Big Data Federation 架构。
大模型大暴发
随着 2022 年 ChatGPT 的呈现，AI 模型曾经具备在企业应用中遍及的算法根底，妨碍 AI 利用模型落地的更多的是数据的供应，数据湖和 Big Data Federation 呈现解决了数据存储和查问问题。而数据供应侧，传统的 ETL 和 ELT 和流计算都造成了瓶颈，亦或无奈疾速买通各种简单传统、新兴数据源、亦或无奈用一套代码同时反对 AI 训练和 AI 线上的数据差异化需要。
企业数据社群决裂
随着数据驱动和应用的深刻，企业外部的数据使用者也疾速减少，从传统的数据工程师到数据分析师、AI 人员甚至销售分析师、财务分析师都有从企业数据仓库当中提取数据的需要。因而，经验了 No-SQL，New-SQL 各种变动之后，SQL 还是成为企业最初面对简单业务剖析的唯一标准。大量分析师、业务部门工程师应用 SQL 来解决企业数据最初一公里的问题，而简单的非结构化数据处理，留给了业余数据工程师应用 Spark、MapReduce、Flink 解决。因而，两批人群的需要产生了比拟大的差别，传统 ETL，ELT 架构无奈满足新型企业使用者的需要。
EtLT 架构应运而生！
在上述背景下，数据处理逐渐演变成为 EtLT 架构：
它拆分了原有 ETL 和 ELT 的构造，并力求实时和批量对立在一起解决以满足实时数据仓库和 AI 利用的需要：
- E(xtract)抽取：从数据源角度来看，反对传统的线下数据库、传统文件、传统软件同时，还要反对新兴云上数据库、SaaS 软件 API 以及 Serverless 数据源的抽取；从数据抽取形式来看，须要反对实时 CDC（Change Data Capture）对数据库 Binlog 日志的解析，也要反对实时计算（例如 Kafka Streaming），同时也须要反对大批量数据读取（多线程分区读取、限流读取等）。
- t(ransform)规范化：绝对于 ETL 和 ELT，EtLT 多出了一个小 t，它的指标是数据规范化（Data Normalization）将简单、异构的抽取进去数据源，疾速地变为指标端可加载的结构化数据，同时，针对 CDC 实时加载 Binlog 进行拆分、过滤、字段格局变更，并反对批量和实时形式疾速散发到最终 Load 阶段。
- L(oad)加载：精确的说，加载阶段曾经不是简略的数据加载，而是配合 Et 阶段，将数据源的数据结构的变更、数据内容的变更以适宜数据指标端（Data Target）的模式疾速、精确的加载到数据指标当中，其中，对于数据结构的变动要反对同源数据结构变更（Schema Evolution），数据加载也应该反对大批量加载（Bulk Load）、SaaS 加载（Reverse ETL）、JDBC 加载等。确保既反对实时数据和数据结构的变动，还要反对大批量数据疾速加载。
- (T)ransform 转化：在云数据仓库、线下数据仓库或新数据联邦的环境下，实现业务逻辑的加工，通常应用 SQL 形式，实时或批量地将简单业务逻辑精确、疾速变为业务端或者 AI 端应用的数据。
在 EtLT 架构下，使用者人群也有了明确的分工：
- EtL 阶段：以数据工程师为主，他们将简单异构的混合数据源，变为数据仓库或者数据联邦可加载的数据，放到数据存储当中，他们无需对企业指标计算规定有深刻了解，但须要对各种源数据和非结构化数据变为结构化数据转化有深刻了解。他们须要确保的是数据的及时性、数据源到结构化数据的准确性。
-
T 阶段：以数据分析师、各业务部门数据 SQL 开发者、AI 工程师为主，他们深刻理解企业业务规定，能够将业务规定变为底层结构化数据上的 SQL 语句进行剖析统计，最终实现企业外部的数据分析和 AI 利用的实现，他们须要确保的是数据逻辑关系、数据品质以及最终数据后果满足业务需要。
EtLT 架构开源实际
在新兴的 EtLT 架构下，其实寰球有不少开源实际，例如在大 T 局部，DBT 帮忙企业分析师和业务开发者疾速基于 Snowflake 开发相干数据利用。而以大数据工作可视化调度协同 (Workflow Orchestration) 见长的 Apache DolphinScheduler 也在布局 Task IDE，让企业数据分析师能够在 DolphinScheduler 上间接调试 Hudi、Hive、Presto、ClickHouse 等的 SQL 工作并间接拖拽生成 Workflow 工作。
作为 EtLT 架构当中代表 Apache SeaTunnel 则是从云、本地数据源多种反对开始起步，逐渐反对 SaaS 和 Reverse ETL，大模型数据供应等方面，逐步完善 EtLT 的幅员，能够看到 SeaTunnel 最新的 Zeta 计算引擎把简单的 Join，Groupby 等简单操作交给最终的数据仓库端来实现，本人只实现归一化、标准化的动作以达到实时数据和批量数据一套代码和高效引擎解决的指标，而大模型反对也放入反对列表当中:
目前 Apache SeaTunnel 从 2022 年底退出 Apache 孵化器的 20 个连接器倒退到当初 1 年增长了 5 倍，目前反对的数据源超过 100（https://seatunnel.apache.org/docs/Connector-v2-release-state/），从传统数据库到云上数据库最终到 SaaS 的反对都在逐步完善。
（参见 https://seatunnel.apache.org/docs/2.3.2/category/source-v2 浏览最新反对组件）
而 Apache SeaTunnel 2.3.0 公布的 SeaTunnel Zeta 引擎也反对数据分布式 CDC，指标源数据表变更（SchemaEvolution）和整库和多表同步诸多 Feature 和针对大数据量优异的性能博得寰球大量用户（例如，印度第二大运营商 Bharti Airtel，新加坡电商 Shopee.com，唯品会 Vip.com 等）。置信随着 Connector 数据量增多，SeaTunnel 会博得更多的企业用户的青眼。
大模型的反对
更有意思的是当初 SeaTunnel 曾经反对了对大模型训练和向量数据库的撑持，让大模型能够间接和 SeaTunnel 撑持的 100 多种数据源交互（参见《图书搜寻畛域重大突破！用 Apache SeaTunnel、Milvus 和 OpenAI 进步书名类似度搜寻精准度和效率》），而当初 SeaTunnel 更能够利用 ChatGPT 间接生成 SaaS Connector 让你的大模型和数据仓库疾速获取互联网上多种信息。
随着 AI、云、SaaS 的复杂性减少，企业对于实时 CDC、SaaS 和数据湖、实时数据仓库装载的需要，简略的 ETL 架构曾经很难满足现有企业的需要，而具备面向企业不同阶段的 EtLT 架构会在古代数据架构当中大放异彩。
而 Apache SeaTunnel 的指标就是是“连贯万源，同步如飞”。
SeaTunnel 社区十分沉闷，以后版本也在疾速迭代，退出 Apache SeaTunnel 社区，以后 2.3.x 版本还有不少中央在疾速变动，也欢送大家一起来奉献！
本文由 白鲸开源科技 提供公布反对！