ETL的发展历程是什么，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。

• Extract（提取）：从不同类型的数据源（包括数据库）读取数据。

• Transform（转换）：将提取的数据转换成特定的格式。转换还包括使用系统中其他数据来丰富数据内容。

• Load（加载）：将数据写入到目标数据库、数据仓库或者另一个系统中。

根据基础设施的不同，ETL可以划分为两大类。

传统ETL的工作流

• 数据库、文件和数据仓库之间的处理以批次进行。

• 目前，大多数公司都需要分析并操作实时数据。但是，传统的工具不适合分析日志、传感器数据、测量数据等。

• 非常大的领域数据模型需要全局的结构。

• 传统ETL处理非常慢、非常耗时，而且需要大量资源。

• 传统架构仅关注已有的技术。因此，每次引入新的技术，应用程序和工具都要重新编写。

随着时间一天天过去，大数据改变了处理的顺序。数据先提取并加载到一个仓库中，并以原始格式保存。每当数据分析师或其他系统需要数据时再进行转换。这个过程叫做ELT。不过这个过程最适合在数据仓库中进行处理。如Oracle Data Integration Platform Cloud等系统提供了该功能。

• 现代数据处理通常包括实时数据的处理，而且组织也需要对处理过程的实时洞察。

• 系统需要在数据流上执行ETL，不能使用批处理，而且应该能够自动伸缩以处理更高的数据流量。

• 一些单服务器的数据库已经被分布式数据平台（如Cassandra、MongoDB、Elasticsearch、SAAS应用程序等）、消息传递机制（Kafka、ActiveMQ等）和几种其他类型的端点代替。

• 系统应该能够以可管理的方式加入额外的数据源或目的地。

• 应当避免由于“现写现用”的架构导致的重复数据处理。

• 改变数据捕获技术的方式，从要求传统ETL与之集成，变成支持传统操作。

• 数据源多样化，而且需要考虑新需求的可维护性。

• 源和目标端点应该与业务逻辑解耦合。使用数据映射层，将新的源和端点无缝地衔接，而且不影响数据转换过程。

数据映射层

• 接收到的数据应当在转换（或执行业务规则）之前进行标准化。

• 数据应该在转换之后、发布到端点之前转换成特定的格式。

• 数据清理并不是现代世界中唯一的数据转换过程。数据转换还需要满足组织的许多业务需求。

• 目前的数据处理通常包含过滤、连接、聚合、序列、模式和丰富化，以执行复杂的业务逻辑。

数据处理过程

• 将所有生产数据放到文件系统和数据库中，数据的格式各异。

• 每小时或每天对数据进行处理。

• 处理来自CDC的事件。

• 处理新系统通过HTTP收到的以事件为中心的数据。

• 将处理过的事件发送到多个目的地。

• 监视当前的库存，在需要新库存的时候发送通知。

• 使用库存数量查看分析结果。

传统的ETL工具：

• 下述处理的ETL逻辑是重复的：

• 对于每个结构不同的文件和数据库。

• 当目标或源端点的数量增加时。

• 重复的业务逻辑很难管理和伸缩。

• 分析和监视所需的数据计算是重复的。

流式平台架构如何解决现代ETL问题：

现代流式平台的工作流

• 源（例如文件、CDC、HTTP）和目标端点（如Kafka、Elasticsearch、Email）从处理过程中解耦合：

• 目标、源和存储API连接到多个数据源。

• 即使源和目标中的数据结构不同，数据映射（如data mapper）层和流SQL（如Query1）也会把从多个源接收到的事件转换成通用的源定义（如Stream1），以便以后进行处理。

• 流平台架构可以连接传统类型的数据源（如文件和CDC），和广泛应用的现代数据源（如HTTP）。

• 传统系统和现代系统生成的事件都用同一个工作流进行接收和分析。

• 聚合（如Aggregation1）按照每分钟、每小时等频率针对需要的属性进行计算。

• 数据随时按需进行汇总，不需要对整个数据集进行处理和汇总。应用程序和可视化、监视工具可以通过提供的API访问汇总后的数据。

• 可以无缝地添加并改变一个或多个业务逻辑（如BusinessRule1）。

• 可以添加任何逻辑，而无需改变已有组件。如上例中，根据BusinessRule1，当紧急程度升高时，就会触发一条Email消息。

通过上述架构，我们可以看到为了ETL数据处理，流式平台与传统系统集成，如文件、CDC与使用Kafka和HTTP的现代系统的结合。

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注天达云行业资讯频道，感谢您对天达云的支持。