在过去几年里，有各种关于“NoSQL商务智能”的短评和出版物。然而，我一直没搞清楚它吸引人关注的到底是什么，我的疑问可以归结为“你想从中得到什么东西？”最近，我将这个话题抛向了一些主流NoSQL公司。得到结果让我感到更加困惑了。下面是我真正搞清楚的一些方面。

正如我不久前在一篇关于数据模型的文章中提到的，许多数据库都可以看作是一些<name, value>对的集合——特别是SQL和NoSQL数据库。

1.在关系数据库中，一条记录就是一组<name, value>对和一些特定且预定的名称序列（例如，来自表定义）。而且，一条记录通常有一个标识码（通常是前面的其中一个值）。

2.与之类似的可以称为结构化文档存储（如JSON或XML），它们的区别在于各个文档所包含的名称序列可能各不相同。而且，通常这些名称之间存在一种层次关系。

3.为此，像Cassandra或HBase这样的“宽列”NoSQL存储很大程度上可以视为一种结构化文档存储，尽管它们有不同的性能优化、特性及不同类型的DML（Data Manipulation Language）。

因此，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工具在操作得当的前提下也能很好地处理非扁平化数据。也就是说，我不确定现在最好的事件序列所使用的实际数据结构。

以上是我个人的一些见解，欢迎大家留言讨论。