当前位置: 首页 > 工具软件 > Apache HAWQ > 使用案例 >

Apache Hawq Data Locality简介 (1) [作者:张桓]

艾浩穰
2023-12-01

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


 类似资料: