资源控制运行时资源调整 对于一个MR Job，reduce task的数量一直是需要人为估算的一个麻烦事，基于MR的Hive也只是根据数据源大小粗略的做估计，不考虑具体的Job逻辑。但是在之后的框架中考虑到了这个情况，增加了运行时调整资源分配的功能。Tez中引入了vertex manager，可以根据运行时收集到的数据智能的判断reduce动作需要的task。类似的功能在TAJO中也有提到，叫progressive query optimization，而且TAJO不仅能做到调整task数量，还能调整join顺序。
资源集成 在Hadoop已经进入2.x的时代，所有想要得到广泛应用的SQL on Hadoop系统势必要能与YARN进行集成。虽然这是一个有利于资源合理利用的好事，但是由于加入了YARN这一层，却给系统的性能带来了一定的障碍，因为启动AppMaster和申请container也会占用不少时间，尤其是前者，而且container的供应如果时断时续，那么会极大的影响时效性。在Tez和Impala中对这些问题给出了相应的解决办法： - AppMaster启动延迟的问题，采取long lived app master，AppMaster启动后长期驻守，而非像是MR那样one AM per Job。具体实现时，可以给fair scheduler或capacity scheduler配置的每个队列配上一个AM池，有一定量的AM为提交给这个队列的任务服务。
- container供应的问题，在Tez中采取了container复用的方式，有点像jvm复用，即container用完以后不马上释放，等一段时间，实在是没合适的task来接班了再释放，这样不仅减少container断供的可能，而且可以把上一个task留下的结果cache住给下一个task复用，比如做map join；Impala则采取比较激进的方式，一次性等所有的container分配到位了才开始执行查询，这种方式也能让它的流水线式的计算不至于阻塞。
其他 到这里为止，已经从上到下顺了一遍各个层面用到的技术，当然SQL on Hadoop本身就相当复杂，涉及到方方面面，时间精力有限不可能一一去琢磨。比如其他一些具有技术复杂度的功能有： - 多数据源查询：Presto支持从MySQL，Cassandra，甚至Kafka中去读取数据，这就大大减少了数据整合时间，不需要放到HDFS里才能查询。Impala和Hive也支持查询HBase。国内也有类似的工作，如秒针改造Impala使之能查询postgres。
- 近似查询：count distinct（基数估计）一直是SQL性能杀手之一，如果能接受一定误差的话可以采用近似算法。Impala中已经实现了近似算法（ndv），Presto则是请BlinkDB合作完成。两者都是采用了HyperLogLog Counting。当然，不仅仅是count distinct可以使用近似算法，其他的如取中位数之类的也可以用。
结束语 尽管现在相关系统已经很多，也经过了几年的发展，但是目前各家系统仍然在不断的进行完善，比如： - 增加分析函数，复杂数据类型，SQL语法集的扩展。
- 对于已经成形的技术也在不断的改进，如列存储还可以增加更多的encoding方式。
- 甚至对于像CBO这样的领域，开源界拿出来的东西还算是刚刚起步，相比HAWQ中的ORCA这种商业系统提供的优化器还差的很多。
毕竟相比已经比较成熟的关系数据库，分布式环境下需要解决的问题更多，未来一定还会出现很多精彩的技术实践，让我们在海量数据中更快更方便的查到想要的数据。
原文链接：盘点SQL on Hadoop中用到的主要技术 | 
