大数据的初期大家都在拼什么?拼集群规模,节点数量，拼存储能力，拼调度能力。此时企业展示技术能力的时候一般都会强调什么集群规模过万，存储能力过百P,每天执行数十万的job。
在大数据初期，人们基本不太在意，数据的存储成本，执行性能和响应速度。更在意的的是构建初始的大数据环境，让数据更大，以及对大数据的掌控能力。
随着这方面的技术越来越成熟，人们会对数据的时效性，查询响应时间要求越来越高。在这个时期出现了许多预处理技术，比方说storm,hbase等，以及一些对性能优化的一些处理方法比如说基于嵌套列存储技术的google dremel,apache drill，impala等，但这些仅仅能在某一领域满足人们的时效性要求，通用性不强，只能说是预处理技术和列存储，并不能满足通用的低延迟的即席查询要求。
目前开源的mdrill技术以及腾讯自主研发的hermer目前的索引的索引量只能达到千亿规模，万亿规模以上的成功案例还没有，纠其原因有两点
其一是索引存储在本地硬盘，他对容灾，异常的恢复的处理逻辑，进程异常后的任务迁移成本制约了其索引规模的大小。
其二是受限其调度系统的实现，管理的事情太多，既要管理索引，又要管理心跳，也要维护容灾，导致调度系统的机器规模上不来。
索引管理，容灾心跳管理，计算资源管理三者将来必须分离。否则万亿以上的目标别想。
其三内嵌过多的来源代码，比如说jstorm,solr等等，他们的架构制约了拓展性。
随着yarn技术的趋于成熟以及在hdfs中的索引技术的成熟和性能的提升，低延迟的万亿规模的索引技术有了希望。
第一，yarn分配的资源不在像之前那样还要维护索引状态，存储位置，仅仅负责对索引的检索和写入，单独的索引管理将以服务的形式独立出来，yarn的资源不在固定的处理某个索引，而是听从索引管理服务的安排。这样的放权也给外部更多的灵活的空间
第二，索引与editlog直接存放在hdfs，容灾交给成熟的hdfs去管理，也不要再说索引在hdfs中性能差了，那是过去，现在性能还是不错的。
第三，独立的索引管理，让索引更灵活。
将索引从原有的进程中抽出，每个进程可以处理多个索引,提升进程的利用率。单独的索引管理，针对不同的业务，更容易灵活的变通。
第四，基于这个版本的大索引不在像之前单独对外提供服务，会更加的开放，对外提供了很多拓展功能，现有的hive以及spark可以很方便的通过类似 inputformat的方式直接使用大索引。同时可以方便的将hdfs,hbase,hive,实时的消息队列比如说kafka,metaq等系统方便的导入导出。
试想下，spark在利用上这个大索引后，一个几万亿的数据，几秒钟就返回结果，而且还支持了很多的复杂查询，是不是很值得期待呢。
同志们，我们尝试的已经够多，是时候开启新的大索引技术之路，求更多的战友组队。
“梦想还是要有的”，大索引未来我看好你哦。
