【问题标题】:Microsoft cubes usage boundaries and best practiciesMicrosoft 多维数据集使用边界和最佳实践
【发布时间】:2020-03-13 03:58:41
【问题描述】:

所以我们正在考虑在我们的组织中使用多维数据集。

现状:

  • DWH (Azure MS SQL) 查询语言 - SQL
  • Microsoft 列存储(不是真正的多维数据集)查询语言 DAX(有 MDX 支持,但看起来实现得很差 - 效率低下)
  • Tableau(BI 系统、报表)可以使用 SQL 和 MDX

已知问题:

  • 当我们使用 MDX 时,存在按日期聚合的问题(我们应该在查询中显示年、月、日期层次结构),而 DAX 则没有这样的问题。
  • Microsoft Column Storage 运行总计计算效率低。

我们现在想如何解决问题:

  • 使用 Microsoft Column Storage,具体化运行总计,但不会在所有报告中使用这种“多维数据集”,仅用于少数真正需要它的人
  • 在 DWH 中实现运行总计。所有使用它的 Tableau 报表
  • 在 DWH 中,我们有每日粒度的数据(例如:我们有一条记录在 11 月 1 日、11 月 5 日、11 月 15 日发生变化,之前我们在 DWH 中有 3 条记录,现在我们将有 15 条)。我们需要这样才能真正快速地获得最新的数据(基本上我们正在实现我们自己的立方体线)

优点:

  • 没有人需要深入了解 DAX 和 MDX 语言
  • 我们不应该重构任何东西

因:

  • DWH 上传(更新)将变得比现在更长
  • DWH 将变得更大(用于记录的日常数据)
  • 我们需要手动维护运行总字段

已知的替代品:

  • Microsoft Power BI - 可以非常高效地使用 DAX 和 MDX
  • Microsoft 分析服务多维数据集(真实多维数据集) - 只要我们关注,MDX 在这方面的效率就很高,不像在 Microsoft 列存储中

问题:

  • 首先:如果可能的话,我真的很想了解您在开发和维护解决方案时所使用的技术,以了解导致痛苦的原因和原因。
  • 第二:如果您对我们当前的方法有任何批评,我们将不胜感激 - 为什么这样不好?
  • 第三:方块死了吗?我的意思是 google 不展示自己的立方体,也许它本身的技术是一条死胡同?
  • 最后:如果您对我们需要使用什么有任何建议,那就太好了。

【问题讨论】:

  • 这对于 Stack Overflow 来说太宽泛了;提出了多个开放式问题。它似乎也没有提出编程问题,并且会产生更多固执己见的答案。如果您可以将您的问题更改为具体的和关于编程的问题,我们可以为您提供帮助;否则这不是正确的地方,您最好在基于讨论的社区中提问。

标签: sql-server database-design architecture data-warehouse cube


【解决方案1】:

我正在尝试根据我的经验逐步回答,问题对于单个技术或个人来说太大了。

首先:如果可能的话,我真的很想得到你的印象 您用来了解导致疼痛的原因和原因的技术 当您开发和维护解决方案时。

仓储、多维数据集、报告、查询在不同的分布式技术上发展迅速,这些分布式技术可以在相对便宜的硬件上水平扩展,按需扩展/缩减,也可以快速扩展。随着互联网带宽、全球化、社交网络和各种原因的增加,数据的大小也在不断增加。 Hadoop,云最初填补了分布式技术的空白,它可以在分布式水平上发展并可以轻松扩展/缩减。

拥有一个具有高计算量和高 RAM 的 sql server 用于内存中的高数据、mdx、cube 通常是垂直扩展的,成本高昂且即使我们有 SQL server 也不能像水平分布那样容易地缩减云。

现在带来优势的是开发大数据解决方案、学习曲线和维护的复杂性,这对于迄今为止还不熟悉它的新采用者来说又是一个巨大的挑战。

第二:如果您有任何批评,我们将不胜感激 我们目前的方法 - 为什么那么糟糕

没有金子弹或一线希望的架构可以解决您面临的每一个问题,而无需面对它自己的一些问题。您的方法再次可行,并且根据您当前的组织结构,它的优点和缺点。我假设您的团队熟悉 SQL 服务器、mdx、多维数据集和列存储,并且还进行了可行性分析。我看到的唯一问题是当数据大小增加时,SQL 需要更多的计算能力和 RAM,这主要可以通过升级 VM/机器来完成。垂直扩展成本高昂,并且在某些时候总是有限制。此外,此类基础设施上的故障转移/DR 成本也更高。

第三:方块死了吗?我的意思是谷歌没有展示自己的立方体, 也许技术本身就是死胡同?

如果你能找到对它的支持,任何技术都不会死,即使是汇编、C、C++、Cobol 对于旧项目以及它比其他项目更适合的情况仍然很强大。

最后:如果您对我们需要使用什么有任何建议 - 那将是 很棒。

为至少 3-4 种类型的解决方案/架构做 POC(概念验证),成本/技能/时间框架最适合您,您将成为最佳评判者。

如果您对基于云的解决方案持开放态度,我可以建议您尝试探索其他一些解决方案,例如带有 azure 数据工厂的数据湖,以进行概念验证(如果它可以满足您的要求)。

此外,我最近从 Microsoft 获得了一个值得一看的开箱即用解决方案:Azure Synapse Analytics(https://azure.microsoft.com/en-in/services/synapse-analytics/)。它内置了对数据件外壳、查询、对 AI/BI 的支持、流式传输、数据湖探索、安全性、规模、对 Spark 和 PowerBI 的各种其他来源的支持、洞察力/视觉显示。

【讨论】:

  • 感谢您的回答。我只需要有人对立方体的意见。你用过突触吗?使用它是否轻松舒适?
  • Synapse 很容易上手,得到了微软的良好支持。如果您直接联系 MS,他们甚至可以帮助您测试产品。只是作为新技术进行了探索,但在某些项目中没有奏效。但我曾在一个使用 Azure 的无服务器架构(逻辑应用程序、函数、API、Blob 存储、流式传输、火花、DataLake、监视器)的项目中工作,这是一次很好的体验。 Synapse 提供了许多我们需要开箱即用的适配器/管道,因此值得探索。
猜你喜欢
  • 1970-01-01
  • 2016-09-18
  • 1970-01-01
  • 2015-09-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2010-11-06
  • 2020-09-04
相关资源
最近更新 更多