时间戳

首页 > 解决方案 > ETL 加 ELT 混合方法：好主意与否？

apache-spark - ETL 加 ELT 混合方法：好主意与否？

问题描述

问题

这是一个好主意吗，在使用 ETL 方法时，将一些最后阶段的聚合作为 ELT（DW 内的物化视图）？

细节

目前我们有一个ETL流程（数据湖=>数据仓库）Nifi -> Storage [raw] -> Spark -> Storage [dl] -> Spark -> Storage [dw] -> Data Warehouse -> Power BI/Bus Users：.

Data Warehouse= Power BI/业务用户的微小预测，根本没有转换逻辑。
Storage [dl]层用于进一步的 ETL 处理、DS 和 ML，将来也可能用于数据探索。
Storage [dw]数据仅用于一个目的 - 加载到我们的数据仓库中。

现在假设有从Storage [dw]层派生的聚合，这些聚合仅在数据仓库内部需要。将聚合从 Spark 转移到 Data Warehouse 物化视图是个好主意吗？

注意事项

数据仓库物化视图似乎是这些聚合更自然的方法。它们更容易实现，无需添加 DW 上传逻辑和编排步骤。但是我们应该做出决定并采用单一方法。所以我害怕以下事情：

  1. [专业] 我想重用一些逻辑并用单元测试覆盖所有逻辑。同时我不想添加 SQL 单元测试框架。
  2. [中] 不太可能，但每小时聚合计算可能会与 Power BI 竞争资源。仍然所有繁重的工作都将由 Spark 完成。
  3. [次要] 聚合步骤不再是编排的一部分。我不能在视图执行失败时使管道失败。次要的，因为对于 SQL 和结构化数据，我认为这种情况将非常罕见。

附言

由于数据量巨大，Power BI 直接查询数据仓库性能是关键措施之一。将大聚合表拆分为多个较小的聚合表是优化事物的方法之一。因此，将多个聚合的创建委托给 Power BI 开发人员将是一个不错的选择，可以节省一些开发时间（而不是每次都为 Spark 团队创建票证）。

标签： apache-sparkdatabase-designarchitectureetldata-warehouse

解决方案

我的看法，虽然这不是一个真正的问题，但我对此没有任何问题。

  1. ELT 和 ELT 不是互补的，而是一种或另一种方法 - 您是否保留不正确的数据并加载所有数据 - ELT？还是传统上清理和拒绝不正确的数据（即 ETL）？

  2. 但我认为你的观点是，在“原始”数据湖中，你可以看到 ELT 减去转换，所以它就是 EL。

  3. 不确定您在现实中与数据仓库的确切差异。看起来像旧的 DWH 与 Datamarts，除了你暗​​示大数据设置和非大数据设置 - 你的 DWH 是传统的 RDBMS？

  4. 物化视图不能太复杂 - 如果您指的是 ORACLE MV。否则我的看法是事实级别的数据是最灵活的 - Ralph Kimball - 并且顶部的视图层具有偏好，除非无法在视图层中完成计算。数据集市以事物为先决条件，意味着更多的工作最终会降低自助服务范式。

  5. 过去有很多性能问题导致维度建模时，DM 就在那里，但是像 Microsoft SQL Server Parallel 和 EXADATA 这样的事情让这些担忧成为了现实。

  6. 尽可能以事实数据为准。我仅以编程方式为 BI 制作了无法通过视图层逻辑轻松报告的东西——例如，每个时间间隔的商品交易的牛市、熊市价差。

  7. 您的前提是数据量以及 Power BI、Spotfire、Tableau 对 Spark 或 Hive 或 KUDU 表的使用。这似乎是一个问题，有时很难解决。也就是说，在我之前的一项任务中，将 Hue 与 KUDU 和镶木地板一起使用非常快。如果内存服务正确，解决 Thrift Server 问题并不容易。由于澄清而被排除。

  8. 如果音量太大，则基本 MV aggr。对推送到传统 DWH 的数据很好。也就是说，Spark agg 函数也非常简单，也可以推送到那里。我认为您可以选择任何一种方式，或者依赖 Hadoop 中的良好分区（仍然用于特定查询）。无论如何，您建议作为最终 aggr。我仍然在许多客户中看到的“我们的 DWH”中的层。它很好地为他们服务，直到大数据赶上优化器并取代 EXADATA 等人。试试 KUDU。超级快，或镶木地板。部分由于澄清而被排除。

所以，很多点都很好，但我觉得 ELT 和 ETL 是不互补的。

推荐阅读