在过去的几年里，出现了各种关于“NoSQL商业智能”的小插曲和出版物。然而，我一直无法弄清楚吸引注意力的是什么，我的问题归结为“你想从中得到什么？”最近，我向一些主要的NoSQL公司抛出了这个话题。得到结果让我更加困惑。以下是我真正想到的一些事情。正如我之前在一篇关于数据模型的文章中提到的，许多数据库可以被认为是成对的集合——尤其是SQL和NoSQL数据库。1.在关系数据库中，记录是一组对和一些特定且预先确定的名称序列（例如，来自表定义）。此外，记录通常有一个标识号（通常是前面的值之一）。2、类似的可以称为结构化文档存储（如JSON或XML），它们的区别在于每个文档包含的名称序列可能不同。此外，这些名称之间通常存在等级关系。3.为此，像Cassandra或HBase这样的“宽列”NoSQL存储，虽然它们有不同的性能优化、特点和不同类型的DML（DataManipulationLanguage），但在很大程度上可以看作是一种结构化文档存储。因此，NoSQL数据一般可以看作是一个表或一组表，但是：1.NoSQL数据库很可能有更多的空值。2.如果简单的转换为关系结构，NoSQL数据库中可能会出现重复值。因此，完整的转换可能需要额外的数据表。如果可以编写脚本提取NoSQL数据库，然后根据需要进行转换或汇总，也可以直接进行数据处理。但是，如果需要使用一些交互界面来实现，则有一定的难度。对了，前面的情况只适用于BI和ETL（Extract/Transform/Load）。事实上，我已经和很多人讨论过合并BI和ETL，他们可能有这样做的理由。其他问题出现在性能方面。许多NoSQL系统使用索引，因此也具有一些过滤功能。其中一些（如MongoDB）也有汇总框架。那么，如果您有数据并且有BI工具、ETL工具或ODBC/JDBC驱动程序，您是否可以开箱即用地利用这些功能？或者您只是选择做最简单和最慢的事情，即提取数据然后在别处处理该数据？这些问题的答案是没有定论的，充其量是在被寻找的过程中。既然已经清楚了NoSQL数据结构会给BI带来的问题，那么让我们看看有哪些解决方案。有什么方法可以让它们真正发挥作用吗？我要说的是“NoSQL数据通常是分层结构的，层次结构非常适合向上总结/向下分析。”然而，描述NoSQL数据的层次结构并不一定与BI相关。相同的层次结构用于聚合，我非常怀疑这两个分类没有太多重叠。除了层次结构，我认为还有一些完全非平面BI的用例。例如，考虑以下场景，现在通常使用NoSQL实现：1.您有太多数据要存储（可能是机器生成的数据）。2.所以你总是按时间片聚合。3、你也会有选择地保存详细信息，即出现时被认为具有某种特殊用途的数据。传统的面向表格的BI工具很难正确地可视化这些数据。因此，最终，您可能需要求助于在NoSQL数据存储上运行的面向NoSQL的BI工具。如果处理得当，事件序列BI工具也可以很好地处理非平面数据。也就是说，我不确定当前事件序列使用的实际数据结构。以上是我个人的一些看法，欢迎大家留言讨论。
