基于《Web Intelligence and Big Data》的自我梳理 三、四

三、LOAD

LOAD可以理解为数据实际上的处理。首先看看数据库。传统关系型数据库主要是面向事务的。最早基于row-oriented存储，使用B+树索引。由于不同事务间的并发，为了满足ACID（原子性，一致性，隔离性，持久性），传统关系型数据库加入了锁以及其他维护数据库一致性的机制。随着，数据表的增大，一个表可能有很多个列。假使我只要查询记录中的某几个字段，基于行存储的数据库仍然要读取所有的字段，这样很低效。于是有了面向查询的colum-oriented数据库。不同的列单独存成一张表，而且可以有各自的排列方式。典型的例子有OLAP，其中一张索引表由多个维度组成。一个维度对应一张表。维度是层级结构的：比如日，月，年。所以查询的时候可以按不同的粒度进行上卷和下钻操作。

进一步，对于几乎要处理所有数据的查询来说，索引几乎排不上用场。而且处理大量数据时，对硬件的容错性要求提高了，尤其若是使用了分布式处理。Hadoop就是为此而生的。它是个可扩展性好，容错性强，易于使用的分布式处理框架。关于Hadoop，雅虎有个不错的教程。这里只指出要取得的高的scalability，Hadoop中n/wp的值要尽可能大（其中n是输入的数据量，p是处理器的数量，w衡量一个processor需处理任务的多少），即mapper阶段的输出不能随着处理器数量的增加而增加。

BigTable是google的nosql数据库，其开源实现为HBase。BigTable将数据表存在分布式文件系统GFS（HBase 对应的是HDFS）。它将表分成多个tablets（同时在行和列上切分）,每个tablets由colum families组成。表对应的column families 数是固定的，但每个family中的colum数是可以改变的。不同于传统数据库，由行、列确定的表项中可以有多条记录，用时间撮标记。BigTable主要支持分析，对（小范围查询）索引的支持比较弱。

BigTable，HBase设计上的要求是可扩的，并且适用于批处理大量数据。因此对索引的支持不够好。在这一方面，另一款NoSQL数据库Mongo DB要做得更好。同时它不像HBase等要求写入时等待所有replica都更新完全。因此，它写入的效率要高一些。

四、LEARN

LEARN就是机器学习的事了：学到有用的东西。Clutset的核心思想是：同一类data中的数据的密度，会比若数据是随机分布（独立）时来得高。Cluster的思想可以用在数据上，也可以用在feature上。用于对数据聚类时，最常用的算法有K-means。对feature“聚类”的算法有association rule mining。由与其实现要多次touch所有的data，因此十分适用于map-reduce框架。

今天去参加了由微软亚洲研究院主办的南京四校大数据论坛。嘉宾们讨论了大数据对我们的影响：大数据是否只是大量的数据而已？ 还是说它能改变我们做分析、研究的方法。这门课的讲者指出有了大量的数据，很多分析问题只变成了简单的counting。今天研究院院长也提到了这个问题：以图片搜索为例，若有大量的关于某一动物的图片，同时每个图片伴有相应的描述文字，那么我们能十分肯定其实某些关键字是描述这张图片的。也就说，有了大数据，我们可以使用brute force的方式去逼近AI。

但是counting的方法不一定都管用。正如本课程中所举的例子那样：我们要找出Amazon里，买了这本书的用户同时也购买了其他书：用counting的方法是找出哪两本书出现的概率高。但由于Amazon里有millions of books。所以任何这种组合概率趋近于零。因此，对于像这种高纬度，long tail的data,我们需要其他的方法（来做这里的推荐）：CF协同过滤或者是基于（隐语义）模型。具体方法这里就不细说了。

最后，是关于machine learning的趋势。鉴于feature和类是co-occurrence的，理论上我们可以在un-supervised的方式下同时学习到class和feature。不过这个仍是目前研究的热点。