关闭。这个问题是基于意见的。它目前不接受答案。
**想改进这个问题吗？**更新这个问题，这样就可以通过编辑这篇文章用事实和引文来回答。
7个月前关门了。
改进这个问题
问题
在使用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上传逻辑和编排步骤。但我们应该做出决定，采取单一的方法。所以我害怕以下事情：
[少校]我想重用一些逻辑，并用单元测试覆盖所有逻辑。同时，我不想添加sql单元测试框架。
[中等]不太可能，但每小时聚合计算可能会与power bi竞争资源。不过，所有繁重的工作都将由spark完成。
[次要]聚合步骤不再是业务流程的一部分。我不能在视图执行失败时失败管道。次要的，因为对于sql和结构化数据，我认为这种情况将非常少见。
p、 s。
由于数据量巨大，powerbi直接查询是衡量数据仓库性能的关键之一。将大的聚合表拆分成多个小的是优化事情的方法之一。因此，将多个agregation的创建委托给powerbi开发人员将是一个很好的选择，可以节省一些开发时间（而不是每次都创建一张激发团队活力的罚单）。
1条答案
按热度按时间qvsjd97n1#
我的看法，虽然这不是一个真正的问题，但我没有问题。
英语教学和英语教学不是互补的，而是一种或另一种方法-你是否保留错误的数据并加载所有的数据-英语教学？或者清除和拒绝不正确的数据（传统上称为etl）？
但我接受你的观点，在“原始”数据湖中，你可以看到elt减去转换，所以它就是el。
不确定dw与数据仓库在现实中的确切区别。看起来像旧的dwh和datamarts，除了你暗示了大数据设置和非大数据设置-你的dwh是一个传统的rdbms？
物化视图不能太复杂-如果你是指oracle mv的话。否则，我的看法是事实级数据是最灵活的—ralph kimball—并且顶部的视图层具有优先权，除非不能在视图层中进行计算。数据集市预先假定了一些事情，意味着更多的工作最终会降低自助服务的效率。
过去有很多性能问题也会导致维度建模，但像microsoftsqlserverparallel和exadata这样的东西会消除这些问题。
在可能的情况下，应以事实级数据为准。我只是以编程的方式为bi做了一些不容易通过视图层逻辑报告的事情——例如，每个时间间隔商品交易的牛市、熊市价差。
您的前提是数据量和使用power bi、spotfire、tableau对抗spark、hive或kudu表。这似乎是一个问题，有时很难纠正。也就是说，在我之前的一个任务中，色调与kudu和parquet的结合非常快。如果内存正常，解决thrift服务器问题并不容易。由于澄清而被排除。
如果音量过大，则基本mv aggr。可以将数据推送到传统的dwh。也就是说，spark agg函数也非常简单，也可以推送到那里。我认为您可以选择任何一种方式，或者依赖hadoop中良好的分区（对于特定的查询）。在任何情况下，你的建议作为最终的aggr。在“我们的dwh”中，我仍然看到许多客户。在大数据赶上优化器并取代exadata等人之前，它可以很好地为他们服务。超快速，或Parquet地板。部分由于澄清而被排除。
所以，很多方面还可以，但我觉得elt和etl是不互补的。