ETL 加 ELT 混合方法：好主意与否？ [关闭]

Question

问题

这是一个好主意吗，在使用 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 移动到数据仓库物化视图是个好主意吗？

注意事项

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

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

附言

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

Answer 1

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

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

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

3. 不确定 dw 与现实中的数据仓库的确切差异。看起来像旧的 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 是不互补的。