ETL 与 ELT: 差异解释
如果您的公司有数据仓库, 您可能会使用 ETL (extract、 Transf … Read More
Socrates
如果您的公司有数据仓库, 您可能会使用 ETL (extract、 Transform、 load) 或 ELT ( extract、 load、 Transform) 将您的数据从不同的来源获取到数据仓库中。这些是移动数据卷和集成数据的常用方法, 以便您可以关联来自不同来源的信息, 将数据安全地存储在一个位置, 并使公司的成员能够从不同部门查看数据。
这两个术语的区别与这些过程的发生顺序有关。这些方法都适合于不同的情况。让我们看近一点。
什么是 ETL?
ETL 是一个过程, 涉及从不同的源 (有时使用临时表) 中提取数据并进行转换, 执行诸如更改数据类型或应用计算等操作。然后, 在数据转换后, 将其加载到目标数据库中, 通常是数据仓库。当您执行 etl 时, etl 软件会进行大量的提升–转换。
ETL 通常用于以下情况:
- 源和目标数据库不同, 并使用不同的数据类型。
- 数据量适中或较小。
- 转换是计算密集型的。
- 数据是结构化的。
什么是英语?
ELT 是一个过程, 涉及提取数据, 将其加载到目标仓库中, 然后在加载后进行转换。在这种情况下, 转换数据的工作由目标数据库完成。ELT 通常发生在 NoSQL 数据库 (如 Hadoop 群集或云安装) 中。
在下列情况下通常使用 ELT:
- 源和目标数据库的类型相同 (即 Oracle 源和目标)。
- 数据量很大。
- 目标数据库引擎适合处理大量数据。
- 数据是非结构化的。
哪一个更好?
这些描述可能会让您怀疑哪种方法更好。事实上, 在不同的情况下, 这些方法中的每一种都有优势, 最好的解决方案取决于你的情况。
下表对比了一些关键区别。
| ETL | ELT | |
|---|---|---|
| 成熟 | ETL 已经存在了20年, 它专门设计用于处理关系数据库、结构化和非结构化数据以及非常大的数据卷。有许多专家和最佳做法可以指导您使用 ETL。还有许多 ETL 工具可供选择。 | 英语与 ETL 没有很好的适应, 因为它不是专门用于处理过去20年市场占据主导地位的关系数据库的。 |
| 灵活性 | 较旧的 ETL 工具非常适合关系数据库, 但通常较少适合于非结构化数据。此外, 使用 ETL 工具, 您必须映射将要移动到目标数据库的数据, 并且对该计划所做的任何更改都需要重新构造映射, 并且再次加载所有数据。 | ELT 工具通常可以处理结构化和非结构化数据的组合。此外, ELT 工具通常将所有数据移动到目标中, 从而使结果数据集更加灵活。 |
| 硬件要求 | 许多传统的 ETL 工具都需要特定的硬件, 并且有自己的引擎来对数据进行转换。虽然现代 ETL 平台在云中运行。 | ELT 工具利用现有硬件的计算能力对数据执行转换。 |
| 更好的..。 | ·结构化数据 ·更小的数据量和复杂的计算 ·内部关系数据库 |
·非结构化数据 ·大量数据和较不复杂的计算 ·云环境 ·数据湖 |
ETLT 方法
看着这个利弊的列表, 你可能会看到两个阵营的特点, 吸引你和相关的问题, 你想解决
例如, 您可能希望使用管线中的时间戳或 geolocations 来丰富数据, 但是在加载之后, 可以启用目标数据库执行可能需要数据库繁重的任务 (如联接) 的复杂转换, 而这是有效的。
考虑要将源数据与数据仓库中现有目标数据联接的方案。使用 ETLT (提取、转换、加载、转换) 方法, 您不需要将数据从现有的目标数据库中拉出, 这样您就可以将其加入到将要加载的数据中。产生的管道是一个很有意义的方法: 允许你的每个工具做他们最适合一个高效、灵活的解决方案的事情。
相关文章
如何在实际地图上构建灾难模拟场景:利用 Mapbox GL JS 和 Three.js 技术实现动画效果的画布层以及可坍塌的 3D 建筑模型
在某些情况下,地图项目所需要的不仅仅是标记和多边形。你希望地图上能够出现一些动态效果:水沿着街道流动、烟雾随风飘散,或者冲击波从某个点扩散开来。 我第一次尝试实现这些效果时,做了我觉得理所当然的事情——我在地图上方添加了一个 元素,然后在上面绘制动画效果。 但结果看起来很不对劲,无论我怎么调整也无法改善这个问题。那些动画效果边缘分明,而且似乎“漂浮”在地面之上;每当我想倾斜或旋转地图时,这些动画就会与下方的地图内容对不上位。 我在开发 HazardSim 这个浏览器模拟器时遇到了这个问题。在这个模拟器中,自然灾害会在真实的地图上发生。海啸场景经历了大约十几次的修改,才终于不再看起来像是一张被贴
阅读全文
“从设计层面确保安全性”:在编写任何代码之前,如何将安全机制纳入系统架构之中
在大多数工程团队中,都会进行这样的对话——不过往往为时已晚。 想象一下:某个功能被部署到生产环境中之后,才会进行安全审查;或者在进行渗透测试时发现了问题;更糟糕的是,还会收到事故报告。 这些漏洞确实是存在的,修复它们也需要投入大量成本。而在这些讨论中,总会有人说:“我们需要为这个功能添加安全措施。” 但这个问题就出在这里:安全并不是事后才添加到软件中的东西,而应该从项目一开始就被纳入设计之中。一旦开始考虑为已经存在的东西添加安全功能,那就意味着你已经进入了“事故应对模式”。 “安全驱动设计”是一种完全不同的思维方式——在制定架构决策之前,就应该明确安全要求;在编写任何代码之前,就必须了解潜在的
阅读全文