Apache Hawq作为一款重量级的开源sql-on-hadoop产品，在性能方面做了很多优化工作。其中针对datalocality设计了单独的模块，使得查询中本地磁盘IO的比例最大化。那么什么是datalocality呢？举个日常生活中的例子，我们经常会在网上购物，那么自营仓库的电商的送货流程是这样的，如果你所在片区的网点有订单物品，那么快递小哥直接送货，如果没有，则会向临近的区级仓库申请调货，区级仓库还没有就市级仓库调货，市级仓库还没有就省级仓库，如果是跨境电商还可以从其他国家的仓库调货。网购的送货时间与订单物品所在仓库的级别息息相关。如果在网点或者区级仓库，我们往往当天就能收到货，如果需要从市级仓库调货，那么需要隔天才能收货，如果跨国，我们甚至需要等一到两周的时间。由此可见，如何最大化从网点或区级仓库直接发货的比例，决定了电商的送货速度。
在Hawq中，一条查询被分拆成多个stage,每个stage由多个计算进程以pipeline的形式执行。Hawq的datalocality与电商送货类似，执行计算的进程可以看作收货人，数据在hdfs中存储单位是block，因此每个block可以看作订单中的物品，无形的“快递员”将数据传递到计算进程空间中，datalocality模块的目标就是将数据传递到计算进程空间的速度最大化。Block可以存储在计算进程所在机器的内存中，本地磁盘中，也可能在同一hdfs集群的其他机器上，可以在同一个机架内，也可能跨机架，甚至跨数据中心，这就对应了商品是在本地网点还是在区级，市级，省级甚至跨国仓库。 当指定计算进程在哪些机器后，我们可以设计相应的datalocality算法，保证系统整体的本地磁盘IO最大化。
前面介绍了datalocality的基本概念，下面来点干货，介绍一下Hawq中hash表的datalocality算法。Hawq的hash表以某列为分布键，将数据打散到hdfs的不同文件中，打散的文件数等于hash表的bucket number。在针对该表执行查询时，hawq会在查询的每个stage中启动bucket number个计算进程处理数据，计算进程在机器间平均分布。最下面的scan stage中，每个进程恰好负责读取一个文件，由于hdfs插入的时候会在本地保留一个备份，Hawq的设计可以保证同一个文件至少在一台机器上有所有block的备份。因此只要调度scan进程读取本机插入的文件，就可以保证100%的本地读取。当然，这是理想情况，如果插入操作时hdfs某个结点过于忙碌，也会产生插入进程在本机没有block备份的情况。
对于Hawq random表，无法保证一个文件至少在一台机器上有该文件所有block的备份，因此针对random表的data locality算法也更为复杂，我们会在以后介绍。
最后，和大家分享一个电商对datalocality算法设计的启示。假设一个进程正在扫描一个由多个block组成的hdfs文件，这些block有的在进程所在机器上有备份，有的没有备份，传统的做法是依次扫描这些block，速度也因此会受到网络IO的限制，总时间＝磁盘IO＋网络IO。参考一下电商，如果我们订单中的物品一部分本地网点有，一部分在市级仓库，那么快递员会先配送本地网点的物品，同时市级仓库开始调货，等到第二天收到市级仓库的物品后，再由快递员配送。从市级仓库调货并没有阻塞快递员配送本地网点的物品，如果datalocality算法借鉴这个思路，可以优先读取本地block，同时在一个后台进程(线程)中不断收集在其他机器上的block，收集完毕后再交由计算进程处理。跨学科、跨领域会激发创新，无论您来自哪个领域，欢迎给Apache Hawq提出宝贵的意见和建议。
https://cwiki.apache.org/confluence/display/HAWQ/Apache+HAWQ+Home
