前言：为什么传统数据库使用B树较多，而大数据存储使用LSM树较多？kudu为什么比hbase更适合支持OLAP查询？
上一篇场景和挑战 提到数据系统最基本的需求就是数据存取，多数情况下数据是一条条记录，每条记录包含key和value。为了提高存取记录的效率，我们知道传统数据库多使用B树作为索引结构。而在大数据场景下，hbase、kudu等存储引擎为什么选择LSM树呢？本文首先介绍什么是LSM树；然后与B树简单对比，分析其优势和缺点；最后再看一下hbase和kudu对LSM的实现和优化以及它们之间的对比。
LSM树
上图引用自BigTable论文，我们直接来看采用LSM树的存储引擎读写数据时的流程，就能比较直观的理解LSM树了。
插入/更新数据:
当有记录要插入时，按key在memtable中找到相应位置，如果已存在此key值，那就直接更新。memtable是内存中存数据的地方，这些数据按key值排序，为了快速查找，会有红黑树之类的数据结构作为索引。当memtable大小到一定阈值，就把它连同索引一起存到一个文件，这个文件就是一个SSTable。这样SSTable会越来越多。后台compaction线程会按一定策略被触发，去对SSTable文件进行合并。由于数据在每个SSTable中是排好序的，合并的过程就是归并排序。
在把记录按key排序写到memtable的同时，会写到一个log文件中。这个log文件不用排序，它是为了容错，当memtable数据丢失的时候可以由此重建。当memtable写入文件后，这个log文件的内容就不再需要了。而新的memtable会有新的log文件对应。
读数据：
首先在memtable中查找，没找到的话，再按时间顺序在SSTable文件中查找。当读数据的时候，如果某个记录不存在，需要读取所有的SSTable才能确定。所以一般每个SSTable文件生成的时候会带一个bloom filter，对这一点进行优化。
LSM VS B树
B树被广泛应用于各种传统数据库。采用了B树的存储系统，所有数据都是排序的，并将这些数据分成一个个page。而B树就是指向这些page的索引组成的m阶树。每次读写数据的过程就是顺着B树查找或更新各个page的过程。B树相对于AVL、红黑树等的优点在于可以减少文件读写次数。
对比LSM和B树之前，我们先来考虑一下它们为什么会设计成这样。要设计一个系统，我们可以从最简单的设计出发。对于存储系统，最简单的就是把记录直接写到记录文件的末尾，这样的做法写效率是最高的。然而要查询某一条记录，需要遍历整个文件，这是无法接受的。为了快速查询，一个办法是建立hash索引，但是hash索引有其自己的问题，比如数据量大的时候，索引在内存中就放不下了。另一个办法就是事先对数据进行排序。从排好序的文件中查找记录有一箱的数据结构可以用，平衡二叉树、堆、红黑树等等，还有今天的主角B树（啊，不，B树只是被来出来陪衬的，今天的主角是LSM）。
这里的关键是“事先”是什么时候。首先会想到的思路是在写入的时候。在计算机系统中真正foundmental的创新是很不容易的。大多数的优化其实都是tradeoff，也就是牺牲一点A，得到一点B。在这里，一共两种操作，写入或者读取，为了提高读取效率，我们就要在写入的时候多做一些事情。对于B树，这多做的事情首先是找到正确的位置，其次还会有page的分裂等。
大多数时候，B树的表现是很优秀的，他也一直很努力的提高自己，不断增加新技能，进化出了B+\B*树等进化体。然而当系统同时服务的客户越来越来多，对吞吐量的要求越来越高。B树表示在大并发写操作的时候，压力有点大，因为要做的事情有点多。那怎么办，为了读取数据的时候轻松一点，这些事情不得不做啊。
当B树不堪重负的时候，主角LSM树登场了。他说，想要有高的写吞吐，就给我减负，我可管不了那么多，我可是主角。作者也很无奈，想想也是，哪个主角没几个挂呢，给他开挂吧。本来都是写入的时候要做的事，就少做一点吧，给你几个后台线程，剩下的事情用它们做吧。有了这几个后台线程帮忙，LSM树处理大量写入的能力一下就上来了。LSM由此直接拿下Hbase、Cassandra、kudu等大量地盘。老大哥B树表示，他有挂，我很慌。
到这里就比较清楚了，B树把所有的压力都放到了写操作的时候，从根节点索引到数据存储的位置，可能需要多次读文件；真正插入的时候，又可能会引起page的分裂，多次写文件。而LSM树在插入的时候，直接写入内存，只要利用红黑树保持内存中的数据有序即可，所以可以提供更高的写吞吐。不过，把compaction交给后台线程来做，意味着有时间差，读取的时候，通常不止一个SSTable，要么逐个扫描，要么先merge，所以会影响到读效率。另外，当后台线程做compaction的时候，占用了IO带宽，这时也会影响到写吞吐。所以B树还不会被LSM取代。
Hbase VS kudu
Hbase 的存储实现是LSM的典型应用，适合大规模在线读写。然而，除了这种OLTP的访问模式，正如我在大数据场景与挑战中提到的，还有一种OLAP的数据访问模式，Hbase其实是不合适的。对此，最常见的做法是定期把数据导出到专门针对OLAP场景的存储系统。这个做法一点都不优雅，因为一份同样的数据同时存在两个不同的地方，而且还会有一个不一致的时间窗口。Kudu就是为了解决这个问题而诞生的。我最早看到kudu就很有兴趣，也很好奇，一个存储系统能同时满足OLTP和OLAP两种场景，那是厉害的。不过现在kudu由于运维成本等其他问题还没有被广泛采用，挺可惜的。
扯远了，我们来看为了更好的支持OLAP，kudu对LSM做了哪些优化。OLAP经常会做列选择，所有的OLAP存储引擎都是以列式存储的。kudu也想到了这一点。kudu的memtable(在kudu中叫MemRowSet)还是同之前一样，只是SSTable(在kudu中叫DiskRowSet)改成了列式存储。对于列式存储，读取一个记录需要分别读每个字段，因此kudu精心设计了RowSet中的索引(针对并发访问等改进过的B树)，加速这个过程。
除了列式存储，kudu保证一个key只可能出现在一个RowSet中，并记录了每个RowSet中key的最大值和最小值，加速数据的范围查找。这也意味着，对于数据更新，不能再像之前一样直接插入memtable即可。需要找到对应的RowSet去更新，为了保持写吞吐，kudu并不直接更新RowSet，而是又新建一个DeltaStore，专门记录数据的更新。所以，后台除了RowSet的compaction线程，还要对DeltaStore进行merge和apply。从权衡的角度考虑，kudu其实是牺牲了一点写效率，单记录查询效率，换取了批量查询效率。
这样看来，从B树到LSM，到kudu对LSM的优化，其实都是针对不同场景不同的访问需求做出的各种权衡而已。了解了这些，我们在选择这些技术的时候心里就有底了。另外，权衡并不是那么容易的事。怎么样牺牲A去补偿B，可能有不同的策略。研究现有系统的一些思想，有助于当我们自己面临问题的时候，有更多思路。
