大索引技术，大数据的未来

不管你信也好，不信也好，大数据时代真的来临了，随着Hadoop技术的普及，其生态圈发展的越来越壮大，Hive、Hbase、Spark、Storm等的一系列新名词不断的涌现在我们的眼里。似乎NoSQL一夜间，攻陷了全部的大数据阵地。

那么传统的关系型数据库的一些思路，真的没有用武之地了么？真的就一去不复返了么？当大数据技术大旗在每个山头摇摆的时候，我们躲在角落里还能做些什么？“索引”，没错，数据库时代的必杀，大数据的利器。

当大数据使用上大索引后有什么好处？

1. 索引技术大幅度的加快数据的检索速度。

2. 索引技术可以显著减少查询中分组、统计和排序的时间。

3. 索引技术大幅度的提高系统的性能和响应时间，从而节约资源。

这个大索引系统应该什么样？

1.数据规模：超过万亿甚至十万亿。

2.数据时效性高：数据从产生到能够查询到结果这个间隔不会超过30秒。

3.查询响应要快：从几万亿规模的数据里，查询到相关数据，响应时间为毫秒或者几秒。

4.支持容灾：要能够支撑可靠的容灾，并且保证良好的数据的准确性。

5. 能够与现有的大数据系统进行较好的融合，方便之间的交互（数据导入导出）。

存在哪些问题？

传统的关系型数据库的索引目前存在如下几个问题，是我们需要改进的。

1. 索引存储在本地硬盘

首先是分散在机器的每个硬盘上，索引不容易管理，容灾与高可用的实现代价较高。

其次是索引的迁移成本以及单机硬盘的大小制约了其索引规模和大小。

最后是如果是通过冗余（"master/slave"或者"双写"）等方式实现数据容灾，数据一致性的设计难度较大。

2. 表的管理，索引，调度曾混杂在一起，集群规模上不去。

索引数据、计算资源掺杂在一起，调度系统管理的事情太多，既要管理索引，又要管理心跳，也要维护容灾，导致调度系统的机器规模上不来。同一个计算资源只分配给固定的索引数据导致计算资源太多的浪费。

3. 对硬件要求太高

数据必须长期持久的滞留在内存中，否则无法快速的加载和查询数据，对硬件要求较高一般都是需要大内存（48G以上）以及SSD硬盘，百亿规模的数据甚至需要数百台机器来支撑快速的查询，对于万亿规模的数据来说成本太高。

应该如何改进?

随着基于Docker on Gaia (腾讯版的Yarn)技术的趋于成熟以及在HDFS中的索引技术的成熟和性能的提升，低延迟的万亿规模的索引技术有了希望。

1.Gaia本身是一套完美的任务调度系统，他解决了Hadoop1.0版本Jobtracker调度的不足，调度延迟时间大大缩小，并且适合实时的即席任务调度，启动的任务是可以长久的持久化的运行的，并且有很好的容灾机制。

2.Docker解决了复杂的环境的依赖的问题，简化了Hermes繁杂的部署步骤。

3.索引可以直接存放在HDFS中，通过HFDS来解决数据的容灾问题，让业务能更专注索引的实现。目前也不要说HDFS性能很差了，那是过去，现在来看，HDFS结合Hermes的BlockBuffer后性能还是很不错的。

Hermes大数据大索引的一个实现

我们实现Hermes on Docker的版本，该版本的设计有如下几个特点。

1.易于使用与部署，几个Jar包几个Submit命令，服务直接在Docker上启动，不再需要部署复杂的环境。

2.将索引数据与计算资源的分开，不再交叉的放在一起，分别管理，划清界限，减少程序设计复杂度。计算资源的管理直接交给Gaia来处理，从而提升集群的规模。

3.一个计算资源不再固定的负责一个索引，而是根据实际的计算需要，处理不同的索引，这比之前一个资源(CPU+内存)固定的分配给一个索引利用率会高很多，因为并不是每次检索和查询都需要扫描全部的数据，有些数据根本就不需要或者很少去查，就没必要让他们长期的占用一个资源。

4.索引会直接存储在HDFS上，通过HDFS来实现数据的高可用，这样程序的设计复杂性就会减少很多，不再担心本地硬盘的问题（是否损坏，是否已满，硬盘损坏时迁移时间过长），也不用担心各种网络的问题，理论上HDFS上有多大的空间，我们就可以存储多少索引，不再受限于本地磁盘大小的限制，数据规模可以很容易的水平拓展。

5.索引的管理将会充分的放权，采用HDFS的目录形式的层次结构，便于管理，外部可以自由的配置索引的存储目录，根据不同业务的需要，索引可以按照时间进行打散，按照时间进行目录分区，也可以按照某些用户ID进行hash，也可以按照某些业务来管理配置不同的生命周期。

6.这个版本的Hermes除了可以单独对外提供服务，也会更加的开放，对外提供索引服务，提供了很多拓展功能，现有的Hive以及Spark可以很方便的通过类似InputFormat或RDD的方式直接使用大索引。同时可以方便的与HDFS，Hbase，Hive，进行交互，也可以通过自定义实时的消费Kafka，MetaQ等消息队列的数据。

试想下，Spark在利用上这个大索引后，一个几万亿的数据，几秒钟就返回结果，而且还支持很多的复杂查询，是不是很值得期待呢 。