大架构细数数据平台的组成与扩展.docxVIP

导读：One size does not fit all！ 数据处理平台已不集中于传统关系型数据库，各种其他平台层出不穷，也各有其适用范围。 从哪些角度去理解各种数据处理平台的设计思想及发展演进呢？下面我们从几个角度讨论一下： 一、单机存储引擎设计（数据的位置） 从某种意义上说，当我们处理数据的时候，实际上是在管理数据的位置，管理数据在CPU的位置，数据相对其他数据的位置。CPU特别适合处理顺序性操作数据指令，这样他可以进行数据预取。但是随机读取操作使得预取功能几乎失效，好多预取到缓存、前端总线的数据都是无效的。 传统意义上说，磁盘的存取性能要弱于内存，但是要分随机存取及顺序存取不同的场景下讨论。在流式顺序处理场景，磁盘及SSD的读取速度已经超过内存随机读取速度。 我们如何尽量实现数据的顺序存取呢？让我们设计一个很简单的数据库开始，存取一个文件。 1、数据存储和更新 追加写可以让我们尽量保持顺序存储文件。但是当数据要进行更新的时候，有两种选择，一种是在数据原地进行更新操作，这样我们就有了随机IO操作。另一种是把更新都放到文件末尾，然后需要读取更新数据的时候进行替换。 2、数据读取 一下子读取整个文件，也是很耗费时间的事情，例如数据库中的全表扫描。当我们读取文件中某一个字段时候，我们需要索引。索引的方式有多种，我们可以用一种简单的固定数值大小的有序数组来做索引，数组里存的是当前数据在文件中的存储偏移量。还有其他索引技术，如hash索引，位图索引等。 索引相当于在数据之上又加了一层树状结构，可以迅速的读取数据。但是打破了我们前面讲的数据的追加写，这些数据都是根据索引随机写入的。在数据库上建立索引的时候都会遇到这个问题，在传统的机械式磁盘上，这个问题会造成1000倍的性能差异。 有三种方法可以解决上述问题： 1）把索引放到内存中，可以随机存储和读取，把数据顺序存储到硬盘上。MongoDB，Cassandra都是采取这种方式。这种方式有一个弊端是存储的数据量受限于内存的大小，数据量一大，索引也增大，数据就饱和了。 2）第二种方式是把大的索引结构，拆成很多小的索引来存储。在内存中批量进来的数据，当积累到一个预定的量，就排序然后顺序写到磁盘上，本身就是一个小的索引，数据存储完，最后加一块小的全局索引数据即可。这样读取数据的时候，要遍历一些小的索引，会有随机读取。本质是用部分小的随机读换取了整体的数据顺序存储。我们通过在内存中保存一个元索引或者Bloom filter来实现处理那些小索引的低延迟。 日志结构的归并树（log structed merge tree, 简称LSM tree）是一种典型的实现，有三个特征： a)一组小的、不变的索引集。 ? b)只能追加写 ，合并重复的文件。 ? c)少量的内存索引消耗换来读取的性能提升。这是一种写优化索引结构。 HBase、Cassandra、Bigtable都是通过这种比较小的内存开销来实现读取和存储的平衡 3）列式存储或者面向列的存储（暴力方式）。 纯列式存储和谷歌bigtable那种列式存储还是有所不同的，大家最好分开来看，虽然占用了同一个名字。列式存储很好理解，就是把数据按照列顺序存储到文件中，读取的时候只读需要的列。列式存储需要保持每一列数据都有相同的顺序，即行N在每一列都有相同的偏移。这很重要，因为同一查询中可能要返回多个列的数据，同时可能我们要对多列直接进行连接。每一列保持同样的顺序我们可以用非常简单的循环实现上述操作，且都是高效的CPU和缓存操作。 列式存储的缺点是更新数据的时候需要更新每一个列文件中的相应数据，一个常用的方法就是类似LSM那种批量内存写的方式。 当查询只是返回某几列数据，列式存储可以大规模减少磁盘IO。除此之外，列式存储的数据往往属于同一类型，可以进行高效的压缩，一些低延迟，高压缩率的扫描宽度、位填充算法都试用。即使对于未压缩的数据流，同时可以进行针对其编码格式的预取。 列式存储尤其适用于大表扫描，求均值、最大最小值、分组等聚合查询场景。 列式存储天然的保持了一列中数据的顺序性，方便两列数据进行关联，而heap-file index结构关联时候，一份数据可以按顺序读取，则另一份数据就会有随机读取了。 典型优势总结： 列式压缩，低IO 列中每行数据保持顺序，可以按照行id进行关联合并 压缩后的数据依然可以进行预取 数据延迟序列化 上面讨论的数据顺序存取的几种方案，在很多数据处理平台的最优技术方案中大都有参考。 通过heap-file结构把索引存储在内存，是很多NoSQL数据库及一些关系型数据库的首选，例如Riak，CouchBase和MongoDB，模型简单并且运行良好。 要处理更大量的数据，LSM技术应用更为广泛，提供了同时满足高效存储和读取效率的基于磁盘的存取