在过去几年里，有各种关于“NoSQL商务智能”的短评和出版物。然而，我一直没搞清楚它吸引人关注的到底是什么，我的疑问可以归结为“你想从中得到什么东西?”最近，我将这个话题抛向了一些主流NoSQL公司。得到结果让我感到更加困惑了。下面是我真正搞清楚的一些方面。
正如我不久前在一篇关于数据模型的文章中提到的，许多数据库都可以看作是一些对的集合——特别是SQL和NoSQL数据库。
1.在关系数据库中，一条记录就是一组对和一些特定且预定的名称序列(例如，来自表定义)。而且，一条记录通常有一个标识码(通常是前面的其中一个值)。
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工具在操作得当的前提下也能很好地处理非扁平化数据。也就是说，我不确定现在***的事件序列所使用的实际数据结构。
以上是我个人的一些见解，欢迎大家留言讨论。
