探索中国CIO人才现状 | 第四季调研报告
NoSQL+商务智能将是一种怎样的体验?
2015-06-05  来源:techtarget

在过去几年里,有各种关于“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工具在操作得当的前提下也能很好地处理非扁平化数据。也就是说,我不确定现在最好的事件序列所使用的实际数据结构。

以上是我(作者)个人的一些见解,欢迎大家留言讨论。