分布式Ad-hoc查询系统

背景和意义

在如今数据大爆炸的时代，每天都有大量的数据被产生，其中有些数据被收集保存和分析，但也有很多数据产生后没有被保存直接流失掉了，目前越来越多的公司开始意识到数据的重要性，并将数据作为公司的核心资产。对于那些已经产生但白白流失掉的数据，其数据量非常大，虽然其中很多目前无法确定是否能产生价值，但是不能确保以后不产生价值，最好的策略是将所有产生的数据都尽量收集和保存起来，以备未来所需，而未来衡量企业竞争力的核心将会是你是否持有大量的用户数据。因此，最近几年关于大数据的相关研究非常火爆，美国更是将大数据作为国家战略进行发展。在保存了大量的数据之后，如何使用数据就变成了问题，如果只是持有数据，无法进行使用和分析，数据的价值也会大打折扣。因此，在大量的数据中如何获取有价值的信息，是当今大数据的主要研究方向。

我们先来看一个场景：XX电信运营商已经拥有了收集和分析所有经过交换机的原始网元数据的系统，Scott是公司的一个的数据分析人员，他刚刚通过系统监控到M小区的用户开机的时间相比以前少了一些，从他的经验判断这个小区很有可能会出现用户流失，于是他打开系统的交互式的分析界面，输入了一些分析查询语句来验证他的想法，通过多次探索性的查询和分析后，他找到了一些用户流失的规律，并提炼形成相关的算法，并交给开发人员进行开发，后续就可以通过程序的方式自动发现这种可能潜在的用户流失场景并制定策略挽留客户。

这是一个典型Ad-hoc交互式分析的应用场景，从发现用户状态异常到分析得出用户可能流失的时间长短，将很大程度上决定是否能够挽留住客户，这对于精细化运营的运行商意义重大。而数据分析的数据量大小和范围，分析的深度和响应时间，是数据分析的关键。如今的数据分析已经朝着全量化，实时化的方向发展，相比以往的采样分析和离线分析已经有了很大的不同，而目前典型的电信领域分析场景的数据量已经达到PB级，因此分析和研究在PB数据规模下的实时Ad-hoc查询技术非常重要。

国内外研究动态

Ad-hoc又称为即席查询，和通常OLTP系统数据库不同的是，Ad-hoc查询允许最终用户建立自定义的查询，查询的维度和方式都不是事先准备好的，因此无法像OLTP场景下，通过精心设计数据模型，创建索引或物化视图来提升查询的性能。因此，在Ad-hoc查询的场景下，主要依赖的是数据的顺序扫描。

顺序扫描的性能依赖于存储结构的组织形式，通常分为NSM和DSM两种数据组织形式，NSM（N-ary storage model）即行式存储，比较适合增删操作，而在查询的场景下会读取大量无关的字段，而DSM（Decomposition storage model）即列式存储，在顺序扫描时仅读取参与查询的字段，结构更为紧凑，因此查询效率更高，DSM更详细的介绍可以参考Copeland G P [1]；而在AilamakiA [2] 的论文中，提出PAX（Partition attributesacross）数据模型的概念，结合了NSM和DSM的优点，即多条数据组织在一个页面内，在页面内使用DSM模型，从而克服了DSM在执行阶段涉及到多字段的缓存不友好问题。更多关于数据模型权衡的信息可参考ZukowskiM [3]的论文。

由于列式存储在查询场景的优势，目前很多分析型数据库都已经支持列式存储，并且基于列式存储做了很多优化。在Abadi D J[6]中概括了目前列存储的主要技术，包括：列式存储的存储布局，块索引技术，压缩技术，执行引擎等。其中Abadi D J[4]详细描述了如何在列式存储执行SQL查询的方法，而在AbadiD J[5]详细描述了在列式存储的数据压缩方法以及在压缩数据上执行查询的相关技术，包括：字典压缩（DICT），行程编码（RLE），DELTA压缩，差值压缩，位图压缩，哈弗曼编码等。

开源的数据仓库InfoBright支持Ad-hoc查询的方式比较特殊，其中的存储引擎Brighthouse[15] 提出了知识网格（knowledge grid）的概念，Brighthouse将数据分成若干个数据包（Data Pack），每个数据包网格都对应有一个知识网格，知识网格中存储数据网格的常用统计信息，当查询时先根据知识网格的统计信息过滤掉无需扫描的数据，从而达到减少扫描数据的范围，提高查询的效率。

在Boncz P[9]，Ailarnaki A[10]的论文中描述了传统执行引擎的效率问题，传统的执行引擎每次执行都是以单个元素作为处理单位的，处理流程非常长，因此对现代CPU的指令预取，以及缓存体系不友好，在MonetDB/X100[11][12]中，提出了向量执行引擎，将处理单元从一次只处理单个元素改为一次同时处理一个向量（同类型的多个单元），从而提升了指令预取的效率，并且当向量的尺寸缓存大小范围内时，也可以尽可能的减少缓存失效带来的影响，从而提升查询的效率。

在Vectorwise [13]中更进一步提出了xchg的执行节点的概念，Vectorwise将各个执行节点的传递数据的元素，抽象为执行节点的数据流，而xchg节点则是各个执行节点的数据流的中转节点，xchg被多线程框架管理，能够将执行节点产生的数据流，按照所需的方式交换到指定的执行节点，xchg节点本身支持三种传输模式：N:M(Xchg)；N:1(XchgUnion); 1:M(XchgBroadcast)，而, Vectorwise [14]中在xchg节点的基础上增加了dxchg节点，dxchg节点和xchg类似，xchg节点只能在单主机多线程间进行数据交换，而dxchg节点则解决了数据流在多个主机间交换的问题。

InfoBright，MonetDB，Vectorwise, C-Store/Vertica[7][8]都是以磁盘为主存的数据仓库产品，而HANA[20][21] 则是以内存为主存，并针对INTEL X64 CPU做优化的内存型分析平台。相比前面几个产品，HANA针对INTEL CPU的SIMD[28]指令集（SSE和AVX）做了优化，以最大程度利用INTEL CPU资源。

PowerDrill [24]是 Google公开的最新的交互式数据分析平台，实现了基于内存的列式存储模型以及基于字典的压缩编码，分布式执行框架，论文中的实验数据非常值得参考。

Dremel[25] 也是Google的交互式Ad-hoc分析平台，和PowerDrill不同的是， Dremel的存储主要是文件系统，其存储方式是列式的文件存储，但存储的编码方式是采用的Google的Protocol Buffer格式，而每个元素都包含重复级和定义级，通过自动状态机（FSM）来实现数据的扫描。

其他还有EMC greenplum[19]， Google Tensing[23]，Hadoop/HIVE[18], HadoopDB[17]等实现了基于MapReduce[26]的SQL执行框架。

在Russakovsky A[27]的论文中提出了grasshopper的算法，通过维表的键值的组合编码，来最大化匹配键值，从而减少数据扫描范围，加速Ad-hoc查询的性能，但该算法仅适合与点查询或者小的范围查询。

研究内容和方法

Ad-hoc查询使用的是典型的数据仓库技术，目前主流的分为是MOLAP和ROLAP，MOLAP的多维数据库的查询速度快，但维度通常不能建很多，灵活性也相对比较弱；而ROLAP以关系型数据库为基础，性能通常相比多维数据库要差一些，但目前随着列式存储技术的完善，发展非常迅速，因此本次研究的主要内容是ROLAP和列式数据库所对应的技术，而MOLAP的技术主要作为参考，主要的研究内容如下：

列式存储

传统的数据仓库采用行式存储，而列式存储是按照列的方式进行数据布局的。相比行式存储，列式存储的压缩比更高，对于表定义修改更简单，并且在查询时需要读取的数据量更小。因此，目前主流的数据仓库都已经支持列式存储。而列式存储目前主要有DSM和PAX两种存储模型，需要研究这两者之间的优缺点并进行选择，同时需要研究在数据压缩状态的列存储上直接进行数据的扫描过滤操作和对应的压缩方法，目前已知的可以在压缩状态执行的压缩方法主要是：字典编码，行程编码以及DELTA压缩。

基于内存的计算的条件已经成熟，单机TB级容量的内存已经成为现实，并且根据摩尔定理，内存的容量还会持续上升，单位成本则会持续下降，并且数据本身还可以进行压缩，因此，Ad-hoc查询可以使用内存作为主存储，数据按需加载，不活动的数据则根据LRU算法淘汰到磁盘或者SSD；

并行执行

并行化执行分为几个部分：ILP(指令级并行)， DLP(数据级并行)，TLP(线程级并行)

ILP主要是提高指令运行效率，传统的执行引擎主要是针对单个数据元素进行操作，每计算一个元素都会执行很多步骤的函数调用，并且在执行过程中存在大量的分支判断处理，这种执行的效率非常低。而通过向量操作，相当于将循环的操作移到了最内层，一次可以处理一千甚至上万个元素（元素的个数根据CPU的缓存大小决定），提高了系统缓存的命中率和指令预取的效率。向量操作在提升系统性能的同时，也大幅度增加了系统的复杂度，因此需要研究合理复杂度的向量执行的框架。

 DLP主要的方法是使用SIMD指令，最新的INTEL CPU支持SSE, AVX的SIMD指令，可以实现一个指令周期可以完成4个INT 32位的整数运算，未来可以支持8个INT32的整数运算。SIMD指令可以大幅度提升数据处理的性能，但是使用SIMD指令要求数据必须连续存放。

 TLP主要的方法是使用多线程，现在INTELCPU支持多核多线程，同时服务器一般支持多个CPU插槽，并且未来CPU的核数会持续的增加，因此在单个查询中充分利用多线程执行的资源也是执行效率提升的重要手段。

 

而执行引擎基本上遵循关系代数的操作，常见的包括：Project, Select, Aggregation, Join, Sort, Union等。如何使用SIMD指令和多线程实现并行化的执行引擎，将细分到执行引擎的关系代数操作上，另外两个比较重要的算法：排序和散列，基本上很多操作都会用到，也是并行化执行引擎的重点。

 分布式

前面几点都是基于单个节点的，但单节点的存储容量和处理能力都是有效的，因此PB级的Ad-hoc查询系统必须考虑分布式处理。在单节点的情况下，数据可以直接通过指针的方式在多个上下文中读写和操作，并发访问控制主要依赖于并发锁操作，而分布式情况解决数据共享的方式只能通过网络通信，而网络通信的带宽，时延和可靠性相比直接内存访问要复杂的多。

首先，需要研究在分布式情况下的数据分布，以尽量减少在查询过程中的网络数据交互。其次需要研究关系代数在分布式情况下的执行计划和数据交互流程，特别是分析场景中使用非常频繁的aggregation，join,  sort的操作，其中join操作在分布式情况的执行过程最为复杂，需要重点研究。

而分布式环境下的可靠性，数据一致性等问题，则不在我们的主要研究范围内。分布式相关的内容可以参考Greenplum，Tenzing，Hive，HadoopDB等相关论文。

参考文献

[1]    Copeland G P, Khoshafian S N. Adecomposition storage model[C]//ACM SIGMOD Record. ACM, 1985, 14(4): 268-279.

[2]    Ailamaki A, DeWitt D J, Hill MD, et al. Weaving Relations for Cache Performance[C]//VLDB. 2001, 1: 169-180.

[3]    Zukowski M, Nes N, Boncz P. DSMvs. NSM: CPU performance tradeoffs in block-oriented queryprocessing[C]//Proceedings of the 4th international workshop on Data managementon new hardware. ACM, 2008: 47-54.

[4]    Abadi D J. Query execution incolumn-oriented database systems[D]. Massachusetts Institute of Technology,2008.

[5]    Abadi D, Madden S, Ferreira M.Integrating compression and execution in column-oriented databasesystems[C]//Proceedings of the 2006 ACM SIGMOD international conference onManagement of data. ACM, 2006: 671-682.

[6]    Abadi D J, Boncz P A,Harizopoulos S. Column-oriented database systems[J]. Proceedings of the VLDBEndowment, 2009, 2(2): 1664-1665.

[7]    Stonebraker M, Abadi D J,Batkin A, et al. C-store: a column-oriented DBMS[C]//Proceedings of the 31stinternational conference on Very large data bases. VLDB Endowment, 2005:553-564.

[8]    Lamb A, Fuller M, VaradarajanR, et al. The vertica analytic database: C-store 7 years later[J]. Proceedingsof the VLDB Endowment, 2012, 5(12): 1790-1801.

[9]    Boncz P, Manegold S, Kersten M.Database architecture optimized for the new bottleneck: Memoryaccess[C]//PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON VERY LARGE DATABASES. 1999: 54-65.

[10] Ailarnaki A, DeWitt D, Hill M,et al. DBMSs on modern processors: Where does time go?[C]. VLDB, 1999.

[11] Boncz P A, Zukowski M, Nes N.MonetDB/X100: Hyper-pipelining query execution[C]//Proceedings of the BiennialConference on Innovative Data Systems Research (CIDR), Asilomar, CA, USA. 2005:225-237.

[12] Żukowski M. Balancingvectorized query execution with bandwidth-optimized storage[M]. 2009.

[13] Bal H, Boncz P, Żukowski M.Multi-core parallelization of vectorized query execution[J]. 2010.

[14] Boncz P, Urbani J. QueryOptimization and Execution in Vectorwise MPP[J].

[15] Ślȩzak D, Wróblewski J,Eastwood V, et al. Brighthouse: an analytic data warehouse for ad-hocqueries[J]. Proceedings of the VLDB Endowment, 2008, 1(2): 1337-1345.

[16] Zukowski M, Boncz P A, Nes N,et al. MonetDB/X100—A DBMS in the CPU cache[J]. IEEE Data Eng. Bull, 2005,28(2): 17-22.

[17] Abouzeid A, Bajda-PawlikowskiK, Abadi D, et al. HadoopDB: an architectural hybrid of MapReduce and DBMStechnologies for analytical workloads[J]. Proceedings of the VLDB Endowment,2009, 2(1): 922-933.

[18] Thusoo A, Sarma J S, Jain N, etal. Hive-a petabyte scale data warehouse using hadoop[C]//Data Engineering(ICDE), 2010 IEEE 26th International Conference on. IEEE, 2010: 996-1005.

[19] Waas F M. Beyond conventionaldata warehousing—massively parallel data processing with Greenplumdatabase[M]//Business Intelligence for the Real-Time Enterprise. SpringerBerlin Heidelberg, 2009: 89-96.

[20] Färber F, May N, Lehner W, etal. The SAP HANA Database--An Architecture Overview[J]. IEEE Data Eng. Bull.,2012, 35(1): 28-33.

[21] Färber F, Cha S K, Primsch J,et al. SAP HANA database: data management for modern business applications[J].ACM Sigmod Record, 2012, 40(4): 45-51.

[22] Bar-Yossef Z, Jayram T S, KumarR, et al. Counting distinct elements in a data stream[M]//Randomization andApproximation Techniques in Computer Science. Springer Berlin Heidelberg, 2002:1-10.

[23] Lin L, Lychagina V, Liu W, etal. Tenzing a sql implementation on the mapreduce framework[J]. 2011.

[24] Hall A, Bachmann O, Büssow R,et al. Processing a trillion cells per mouse click[J]. Proceedings of the VLDBEndowment, 2012, 5(11): 1436-1446.

[25] Melnik S, Gubarev A, Long J J,et al. Dremel: interactive analysis of web-scale datasets[J]. Proceedings ofthe VLDB Endowment, 2010, 3(1-2): 330-339.

[26] Dean J, Ghemawat S. MapReduce:simplified data processing on large clusters[J]. Communications of the ACM,2008, 51(1): 107-113.

[27] Russakovsky A. Hopping over BigData: Accelerating Ad-hoc OLAP Queries with Grasshopper Algorithms[J].

[28] Willhalm T, Popovici N, BoshmafY, et al. SIMD-scan: ultra fast in-memory table scan using on-chip vectorprocessing units[J]. Proceedings of the VLDB Endowment, 2009, 2(1): 385-394.

[29] Zhou J, Ross K A. Implementingdatabase operations using SIMD instructions[C]//Proceedings of the 2002 ACMSIGMOD international conference on Management of data. ACM, 2002: 145-156.