ETL 加 ELT 混合方法：好主意还是坏主意？
ETL plus ELT hybrid approach: good idea or not?
问题
这是个好主意吗，在使用 ETL 方法的同时，做一些最后阶段的聚合作为 ELT（DW 内的物化视图）？
详情
目前我们有一个 ETL 过程（数据湖 => 数据仓库）：Nifi -> Storage [raw] -> Spark -> Storage [dl] -> Spark -> Storage [dw] -> Data Warehouse -> Power BI/Bus Users。
Data Warehouse = Power BI/business 用户的微小投影，根本没有转换逻辑。
Storage [dl] 层用于进一步的 ETL 处理、DS 和 ML，将来也可能用于数据探索。
Storage [dw] 数据仅用于一个目的 - 加载到我们的数据仓库中。
现在假设有从 Storage [dw] 层派生的聚合，这些聚合仅在数据仓库内部需要。 将聚合从 Spark 移动到数据仓库物化视图是个好主意吗？
注意事项
对于这些聚合，数据仓库物化视图似乎是更自然的方法。它们更易于实现，无需添加 DW 上传逻辑和编排步骤。但我们应该做出决定并采用单一方法。所以我害怕以下事情：
- [主要]我想重用一些逻辑并用单元测试覆盖所有逻辑。同时我不想添加 SQL 单元测试框架。
- [中]不太可能，但每小时聚合计算可能会与 Power BI 竞争资源。所有繁重的工作仍将由 Spark 完成。
- [次要] 聚合步骤不再是编排的一部分。我不能在视图执行失败时使管道失败。次要，因为对于 SQL 和结构化数据，我认为这种情况将非常罕见。
P.S.
由于数据量巨大，Power BI直接查询Data Warehouse的性能是关键衡量指标之一。将大聚合表拆分为多个较小的聚合表是优化事物的方法之一。因此，将多个聚合的创建委托给 Power BI 开发人员将是一个不错的选择，可以节省一些开发时间（而不是每次都向 Spark 团队创建票证）。
我的看法，虽然这不是真正的 SO 问题，但我对此没有意见。
ELT 和 ELT 不是互补的，而是一种或另一种方法 - 您是否保留不正确的数据并加载所有数据 - ELT？还是传统上清理并拒绝不正确的数据（即 ETL）？
但我同意你的观点，在 "raw" 数据湖中你可以看到 ELT 减去转换，所以它会是 EL。
不确定 dw 与现实中数据仓库的确切区别。看起来像旧的 DWH 与数据集市，除了你暗示大数据设置和非大数据设置 - 你的 DWH 是传统的 RDBMS？
物化视图不能太复杂 - 如果您指的是 ORACLE MV。否则我的看法是事实级数据是最灵活的 - Ralph Kimball - 并且顶部的视图层有偏好，除非计算不能在视图层中完成。数据集市以事物为前提，意味着更多的工作最终会降低自助服务范式。
当过去存在很多性能问题时，DM 就在那里，这些问题也会导致维度建模，但是像 Microsoft SQL Server Parallel 和 EXADATA 这样的东西消除了这些担忧。
尽可能以事实级别的数据为准。我只是以编程方式为 BI 制作了一些东西，这些东西无法通过视图层逻辑轻松报告 - 例如例如，每个时间间隔的商品交易的牛市、熊市价差。
你的前提是数据量和 Power BI、Spotfire、Tableau 对 Spark 或 Hive 或 KUDU 表的使用。这似乎是一个问题，有时很难解决。也就是说，在我之前的一项任务中，将 Hue 与 KUDU 和 parquet 结合使用非常快。如果内存服务正常，解决 Thrift 服务器问题并不容易。由于澄清而被取消。
如果音量太大，基本MV aggr。对推送到传统 DWH 的数据没问题。也就是说，Spark 聚合函数也非常简单，也可以推送到那里。我认为您可以采用任何一种方式，或者依靠 Hadoop 中的良好分区（仍然用于特定查询）。无论如何，您建议作为最终 aggr。 "our DWH" 层我仍然在许多客户处看到。它很好地为他们服务，直到大数据赶上优化器并取代 EXADATA 等。试试库杜。超快，或镶木地板。部分由于澄清而被省略。
所以，很多点都很好，但我觉得 ELT 和 ETL 是非互补的。
问题
这是个好主意吗，在使用 ETL 方法的同时，做一些最后阶段的聚合作为 ELT（DW 内的物化视图）？
详情
目前我们有一个 ETL 过程（数据湖 => 数据仓库）：Nifi -> Storage [raw] -> Spark -> Storage [dl] -> Spark -> Storage [dw] -> Data Warehouse -> Power BI/Bus Users。
Data Warehouse = Power BI/business 用户的微小投影，根本没有转换逻辑。
Storage [dl] 层用于进一步的 ETL 处理、DS 和 ML，将来也可能用于数据探索。
Storage [dw] 数据仅用于一个目的 - 加载到我们的数据仓库中。
现在假设有从 Storage [dw] 层派生的聚合，这些聚合仅在数据仓库内部需要。 将聚合从 Spark 移动到数据仓库物化视图是个好主意吗？
注意事项
对于这些聚合，数据仓库物化视图似乎是更自然的方法。它们更易于实现，无需添加 DW 上传逻辑和编排步骤。但我们应该做出决定并采用单一方法。所以我害怕以下事情：
- [主要]我想重用一些逻辑并用单元测试覆盖所有逻辑。同时我不想添加 SQL 单元测试框架。
- [中]不太可能，但每小时聚合计算可能会与 Power BI 竞争资源。所有繁重的工作仍将由 Spark 完成。
- [次要] 聚合步骤不再是编排的一部分。我不能在视图执行失败时使管道失败。次要，因为对于 SQL 和结构化数据，我认为这种情况将非常罕见。
P.S.
由于数据量巨大，Power BI直接查询Data Warehouse的性能是关键衡量指标之一。将大聚合表拆分为多个较小的聚合表是优化事物的方法之一。因此，将多个聚合的创建委托给 Power BI 开发人员将是一个不错的选择，可以节省一些开发时间（而不是每次都向 Spark 团队创建票证）。
我的看法，虽然这不是真正的 SO 问题，但我对此没有意见。
ELT 和 ELT 不是互补的，而是一种或另一种方法 - 您是否保留不正确的数据并加载所有数据 - ELT？还是传统上清理并拒绝不正确的数据（即 ETL）？
但我同意你的观点，在 "raw" 数据湖中你可以看到 ELT 减去转换，所以它会是 EL。
不确定 dw 与现实中数据仓库的确切区别。看起来像旧的 DWH 与数据集市，除了你暗示大数据设置和非大数据设置 - 你的 DWH 是传统的 RDBMS？
物化视图不能太复杂 - 如果您指的是 ORACLE MV。否则我的看法是事实级数据是最灵活的 - Ralph Kimball - 并且顶部的视图层有偏好，除非计算不能在视图层中完成。数据集市以事物为前提，意味着更多的工作最终会降低自助服务范式。
当过去存在很多性能问题时，DM 就在那里，这些问题也会导致维度建模，但是像 Microsoft SQL Server Parallel 和 EXADATA 这样的东西消除了这些担忧。
尽可能以事实级别的数据为准。我只是以编程方式为 BI 制作了一些东西，这些东西无法通过视图层逻辑轻松报告 - 例如例如，每个时间间隔的商品交易的牛市、熊市价差。
你的前提是数据量和 Power BI、Spotfire、Tableau 对 Spark 或 Hive 或 KUDU 表的使用。这似乎是一个问题，有时很难解决。也就是说，在我之前的一项任务中，将 Hue 与 KUDU 和 parquet 结合使用非常快。如果内存服务正常，解决 Thrift 服务器问题并不容易。由于澄清而被取消。
如果音量太大，基本MV aggr。对推送到传统 DWH 的数据没问题。也就是说，Spark 聚合函数也非常简单，也可以推送到那里。我认为您可以采用任何一种方式，或者依靠 Hadoop 中的良好分区（仍然用于特定查询）。无论如何，您建议作为最终 aggr。 "our DWH" 层我仍然在许多客户处看到。它很好地为他们服务，直到大数据赶上优化器并取代 EXADATA 等。试试库杜。超快，或镶木地板。部分由于澄清而被省略。
所以，很多点都很好，但我觉得 ELT 和 ETL 是非互补的。