CN115237937A - 一种基于星际文件系统的分布式协同查询处理系统 - Google Patents

Abstract

本发明属于分布式数据处理技术领域，具体为一种基于星际文件系统的分布式协同查询处理系统。本发明系统包括版本与格式管理器、分布式查询引擎和后端存储IPFS；利用分布式查询引擎的灵活性和IPFS分散文件系统的可伸缩性特点；系统在每个用户端运行一个本地节点，多个节点形成一个对等网络；在本地存储中具有特定数据集的用户是该数据集的提供者，可以接受网络中其他用户对该数据集的查询；系统支持运用结构化查询语言，对数据分布式的读操作和写操作。本发明把数据集的服务、检索、更新和分发以分布式进行，存储成本低；拥有相同数据集的用户通过协作共享计算资源进行加速处理；内容寻址支持对数据集中用户感兴趣的特定分区进行细粒度访问。

Description

一种基于星际文件系统的分布式协同查询处理系统

技术领域

本发明属于分布式数据处理技术领域，具体涉及一种基于星际文件系统的分布式协同查询处理系统。

背景技术

大数据驱动的各种智能化应用已经显示出强大的能力：从个性化搜索和推荐，到精准广告投放、金融风险管控，利用各类算法从大数据中挖掘出的信息可以为决策提供有效和精准的依据。然而，能够利用繁多而复杂的数据挖掘算法的前提是首先要有足够的数据。但是，并非所有使用大数据的组织都在数量和种类上拥有足够多的数据，许多数据分散在各个政府、企业、组织中，未能充分发掘和利用。

区块链技术因为其去中心化、安全保障和公开透明的特点，近来受到重视和广泛研究和应用。目前区块链技术已经被应用于解决大数据共享问题。例如将区块链技术应用在物联网供应链的信息跟踪和溯源中，实现在多方之间共享物联网设备采集的信息；在医疗诊疗数据的共享中引入区块链技术，在保护隐私的前提下，实现在病患、医院和研究机构之间共享医疗数据。出于区块链的安全性考虑，块的大小不能无限制地增长，这导致基于区块链的系统无法直接存储和处理大量的数据，限制了区块链技术在大数据等领域的应用。

星际文件系统（InterPlanetary Filesystem，简称IPFS）是一个P2P、去中心化的文件系统，因为其去中心化的特点以及在安全性、隐私和可靠性方面的优点，许多区块链系统应用将其作为数据存储的解决方案。IPFS将数据存储在互相连结的数据对象中，每个数据对象都由自身的密码散列值唯一确定，称为对象的“内容标识符（ContentIdentifier，CID）”。数据对象间的联系形式丰富多样，可以形成文件、目录、超链接图等多种数据结构，以满足不同应用领域数据形式的多样性需求。然而现有的系统和产品仅限于数据存储与传输，缺乏在广域互联网上通过IPFS进行数据的协作查询与分析等高级的功能。

综上所述，数据共享与交易平台缺少对数据的协作查询与分析。现有解决方案虽然提供了多元化的数据利用方式，但都依赖特定中心服务提供者，存在对特定平台深度依赖的风险，缺少数据提供者之间的去中心化协作。

发明内容

本发明的目的在于提供一种存储成本低、处理速度快的基于星际文件系统的分布式协同查询处理系统，适用于IPFS存储系统和包括Hive、Impala、Spark SQL、Drill、Presto等分布式查询引擎之间的接口设计，支持标准SQL查询语句，支持结构化和非结构化的异构数据文件格式。

本发明提供的基于星际网络文件系统的分布式协同查询处理系统，记为Minerva，其架构如图1所示，Minerva由三个协作组件组成：版本与格式管理器（即数据管理工具）、分布式查询引擎（包括但不限于Hive、Impala、Spark SQL、Drill、Presto）和存储后端平台IPFS；利用分布式查询引擎的灵活性和IPFS分散文件系统的可伸缩性特点；系统的每个用户运行一个本地节点，多个节点形成一个对等网络。在本地存储中具有特定数据集的用户是该数据集的提供者，可以接受网络中其他用户对该数据集的查询。其中：

所述存储后端平台IPFS：是位于最底层的组件。IPFS提供去中心化的存储，在每个节点上具有本地的数据块存储，供上层的查询引擎读写数据；IPFS还提供连接IPFSP2P网络的接口，供查询引擎查询网络上的节点信息，以及连接到这些节点。

所述分布式查询引擎：包括但不限于Hive、Impala、Spark SQL、Drill、Presto；以ApacheDrill为例，Drill是一个分布式并行查询引擎，可以在多个节点间协调执行SQL数据查询。Drill的读写器、规划器等组件在处理SQL输入时与底层的IPFS交互，获得执行查询所必要的信息。

所述版本与格式管理器：管理存储在IPFS中的各个数据集的版本，使其指向最新版本，或者指向某个特定的历史版本；转换不同格式的原始数据为查询引擎可以读写的格式。

进一步地，本发明还设计了数据布局。为了使数据能够被查询引擎正确读取和处理，本系统基于IPFS中MerkleTree的数据结构提出了查询引擎数据存储结构，如图2所示。当数据所有者添加数据集时，数据文件首先经过分片，然后被组织进一个树状结构中，最后每一个数据块分布在IPFS网络的若干节点中。每个存储了数据块的IPFS节点成为这个数据块的提供者，可以被其他节点查找到，为其他节点提供该数据块。

进一步地，本发明还设计了分布式查询引擎的存储接口，使其可以运行在IPFS上，以IPFS上的文件为数据来源执行查询。从查询发起节点的角度，本系统的工作流程为：

（a）用户通过用户界面向分布式查询引擎提交SQL的查询请求；

（b）分布式查询引擎从SQL语句中解析得到IPFS文件的CID；

（c）查询引擎的规划器与IPFS通信，得到待查询的文件在IPFS网络中存放的位置，从而建立查询计划，即如何从SQL转换为实际的查询操作；

（d）查询计划被通过IPFS的P2P网络发送至数据提供者节点处；

（e）提供数据的提供者节点监听IPFS网络上的请求包，然后从本地存储中读取数据，执行请求中的查询计划，并向查询发起者返回查询的结果；

（f）读写器完成实际的数据读写操作后得到查询结果，最终发送回发起查询的用户。

进一步地，本发明还设计了读请求流程。读请求即仅包含SELECT语句（及各种子句）的SQL查询请求。图3展示了用户发起一次读请求时的系统工作流程，具体为：

（a）用户通过用户界面向查询引擎输入SQL查询语句，包含要查询的数据集的CID，以及相应的数据过滤、排序或聚合操作；

（b） 引擎解析SQL，得到IPFSCID，并查询IPFS得知数据集由多个块构成，得到每个块的CID。对于每个数据块，根据其CID查询IPFS的分布哈希表（DHT），得到IPFS网络中可以提供该数据分片的节点（提供者），以此建立查询计划；

（c） 查询计划被发送至提供者节点处，经过验证数据操作没有安全和隐私等风险后，各个节点按照查询计划从本地的IPFS存储中读取数据，得到该节点处的部分结果；如果查询计划应用了谓词下推（predicatepushdown）等优化手段，则在这个阶段即会应用这些优化；

（d） 各个节点处部分结果集被发送回请求者的节点，并应用剩余的过滤、排序或聚合操作，形成最终的结果集，通过用户界面返回给用户。

进一步地，本发明还设计了写请求流程。写请求在分布式查询引擎的语境下包含数据定义语言（DataDefinitionLanguage，DDL）中的部分SQL语句，主要是CTAS（CreateTableAsSelect）语句和CTTAS（CreateTemporaryTableAsSelect）语句两种。这两种语句嵌套了一个SELECT查询，从这个查询的结果集创建新的表。因此，分布式查询引擎中的写请求总是包含一个读请求。图4展示了用户发起一次写请求时的系统工作流程。写请求流程中解析SQL、生成查询计划和查询DHT获得提供者节点等过程与读请求完全一致。与读请求不同的部分是：

（a） 在查询计划被发送至提供者节点处后，各个节点读取存放在本地的数据块，应用数据变换操作后，会得到本地的部分结果集。不同于读请求直接返回结果集，写请求的情况下引擎会将结果集物化（Materialize）得到新的数据块，然后将其写入存储，并获得相应的新的CID；

（b） 各个节点处的新的CID被发送回请求者的节点后，不同于读请求向用户展示汇总后的结果集，写请求时引擎会将多个CID聚合和重新封装后形成一个完整的CID返回给用户，这个CID也就是新的表对应的CID，可以用于此后的查询操作；

（c） 根据上述的的读写流程，由于所有数据操作均是在数据所有者的节点处执行的，数据使用者没有直接获得原始数据，因此实现了在保护数据所有者的权益的情况下，查询和利用数据集的目的。而且，得益于IPFS的数据分块机制，庞大的数据集可以分拆为许多小片，由多个节点分别存储这些数据块，并行执行数据变换的操作，提高查询的效率。

综上，现有基于区块链技术的数据共享方案，往往将文件作为承载数据的载体，存在抽象层次过于底层的不足，而现有的分布式SQL查询引擎不支持在去中心化的环境中使用。本发明着眼于现有大数据分享平台的不足，基于IPFS去中心化的存储网络，和分布式的查询引擎，设计了去中心化的大数据存储和查询系统。本发明可以在去中心化数据分享与分析场景下运行，根据查询的需要动态地寻找存储数据的节点，并生成查询计划，在这些节点上并行地执行查询。引擎支持标准的SQL语句作为查询输入，支持读写操作和多种数据格式，不需要预先定义数据的数据结构，为分布在广域互联网上的大数据共享与协作计算开辟了新的道路。

本发明系统中，数据集的服务、检索、更新和分发以分布式进行，存储成本低；拥有相同数据集的用户通过协作共享计算资源来加速处理；内容寻址支持对数据集中用户感兴趣的特定分区进行细粒度访问。

附图说明

图1为本发明分布式协同查询处理系统（Minerva）结构图示。

图2为数据集存储过程图示。其中，（a）为数据记录被分割多个分片；（b）为分片被组织为一树形结构；（c）为所有分片储存在不同的IPFS节点上。

图3为读请求的查询流程示意图。

图4为写请求的查询流程示意图。

图5为不同的并行宽度下的查询完成时间实验图。

图6为不同区块大小下的查询完成时间实验图。

具体实施方式

本发明利用分布式查询引擎的灵活性和IPFS分布式文件系统的可伸缩性，允许每个用户运行一个本地节点，多个节点形成一个对等网络。在本地存储中具有特定数据集的用户是该数据集的提供者，可以接受网络中其他用户对该数据集的查询。本发明支持自定义SQL函数，这些函数在运行时从.jar文件加载；用户可以以数据集自定义函数的形式实现其转换规则和分析算法，并将其与数据集一起分发。

分布式查询引擎为存储后端提供了一套抽象的操作接口，使得分布式查询的上层结构（包括SQL解析器、查询优化器等）可以不依赖于具体的存储后端。从而较为简单地支持从本地文件系统到HadoopFileSystem（HDFS），AmazonS3等多种远程的文件系统，以及接入其他数据仓库和数据库系统，如Hive、ElasticSearch、MongoDB等。IPFS作为一个文件系统，与这些数据存储系统类似，可以通过这套接口，实现与Drill的连接和互通。利用分布式查询引擎提供的接口，构建了以下类型的组件，完成查询系统的入口，模块配置和生成查询计划的功能核心：

（a）存储模块IPFSStoragePlugin；

（b）模块配置IPFSStoragePluginConfig；

（c）生成与表示查询计划IPFSScan；

（d）定义数据SchemaIPFSSchemaFactory；

（e）实现读操作IPFSReader；

（f）实现写操作IPFSWriter；

分布式查询引擎根据用户的配置文件，以模块化的方式动态加载用户所需的存储后端。通过定义名为StoragePlugin的接口，规范存储模块与查询引擎其他模块之间的交互，每个存储模块以实现该接口的方式，向分布式查询引擎框架注册自身。

IPFSStoragePluginConfig，是IPFS存储后端在运行时的配置及性能优化的参数。

IPFSScan，是实现存储后端主要功能的核心类，在分布式查询引擎定义的一个逻辑操作符，表示对一整个数据集的读取。经过这个操作符处理后，存储在各个存储后端中的数据被读取到内存中，可以为其他数据操作符所处理。

IPFSSchemaFactory，是用于处理动态Schema的类。查询引擎在执行查询时不需要预先有数据集的Schema信息，是因为可以通过SchemaFactory动态生成一个数据集的Schema。

IPFSReader，对于相应格式的文件，创建IPFSReader模块。IPFSReader是负责实际读取相应数据格式数据的类。由IPFSScanCreator产生后，根据提供的IPFS数据块的CID，调用IPFSAPI，从IPFS网络中读取数据，并按相应格式解析，得到分布式查询引擎可以用于后续数据操作的内部表达形式。

IPFSWriter，处理写入操作，代表了“一批”数据的写入，通常是处理写入时发生Schema变化的情形。对外提供类似迭代器的接口，由查询引擎框架负责调用，当Schema发生变化，或者写入完成时，生成对应的IPFSWriter，实际写入数据。

下面通过实施例进一步介绍本发明。

实施例：

设实施例的参数：

系统环境： java；

网络拓扑：6个节点，每个节点运行一个Minerva实例；

区块大小：1MB；

数据集1:67MB；

数据集2:190MB。

本发明在6节点集群中对原型系统进行了初步性能评估，每个节点运行一个Minerva实例，IPFS在专用网络模式下工作。所有统计数据均为10次运行的平均值。图5显示了并行化宽度如何影响查询性能。块大小固定为1MB。对于这两个数据集，当在更多节点上并行执行查询时，计划时间略有增加，而执行时间先减少后增加。规划者需要更多的时间来收集足够的有关更多能够处理查询的提供程序的信息。执行时间的情况可以解释为两个因素的混合效应：当查询分布较少时，总体执行时间主要取决于最慢的节点；当它们在更多节点上执行时，开销（例如，增加网络通信成本，从而增加系统负载）变得显著。

本发明比较了不同区块大小对性能的影响，结果如图6所示。在本实验中，最大并行宽度设为3。块大小在很大程度上对计划时间有重大影响，计划时间是查找哪个节点最适合执行查询的特定片段所花费的时间。这是因为区块越小，区块数量越多，数据集就必须被划分，因此调度器必须考虑更多的数据单元。

参考文献

[1] Juan Benet. 2014. IPFS - Content Addressed, Versioned, P2P FileSystem. CoRR (2014).Arxiv:1407.3561.

[2] Anant Bhardwaj, Amol Deshpande, Aaron J. Elmore, David Karger,Sam Madden, AdityaParameswaran, Harihar Subramanyam, Eugene Wu, and RebeccaZhang. 2015. Collaborative Data Analytics with DataHub. Proc. VLDB Endow. 8,12(Aug.2015), 1916-1919.

[3] Cisco. 2019. Cisco Global Cloud Index: Forecast and Methodology,2016-2021 White Paper. https://www.cisco.com/c/en/us/solutions/collateral/service-provider/global-cloud-index-gci/ white-paper-c11-738085.html. (2019).[Online; accessed 20-May-2019].

[4] Michael Hausenblas and Jacques Nadeau. 2013. Apache Drill:Interactive Ad-Hoc Analysis at Scale. Big Data 1, 2(2013), 100-104. PMID:27442064.

[5] qri.io. 2019. qri. https://github.com/qri-io/qri. (2019).[Online; accessed 20-May-2019].

[6] Kazunori Sato. 2012. An Inside Look at Google BigQuery. https://cloud.google.com/files/

BigQueryTechnicalWP.pdf. (2012). [Online; accessed 20-May-2019]。

Claims (5)

1.一种基于星际网络文件系统的分布式协同查询处理系统，其特征在于，由三个协作组件组成：版本与格式管理器、分布式查询引擎和存储后端平台IPFS；利用分布式查询引擎的灵活性和IPFS分散文件系统的可伸缩性特点；每个用户运行一个本地节点，多个节点形成一个对等网络；在本地存储中具有特定数据集的用户是该数据集的提供者，可以接受网络中其他用户对该数据集的查询；其中：

所述存储后端平台IPFS，位于最底层，提供去中心化的存储；在每个节点上具有本地的数据块存储，供上层的查询引擎读写数据；IPFS还提供连接IPFSP2P网络的接口，供查询引擎查询网络上的节点信息，以及连接到这些节点；

所述分布式查询引擎，选自Hive、Impala、Spark SQL、Drill或Presto；其中，Drill是一个分布式并行查询引擎，可以在多个节点间协调执行SQL数据查询；Drill的读写器、规划器组件在处理SQL输入时与底层的IPFS交互，获得执行查询所必要的信息；

所述版本与格式管理器，管理存储在IPFS中的各个数据集的版本，使其指向最新版本，或者指向某个特定的历史版本；转换不同格式的原始数据为查询引擎可以读写的格式。

2.根据权利要求1所述的基于星际网络文件系统的分布式协同查询处理系统，其特征在于，为了使数据能够被查询引擎正确读取和处理，基于IPFS中MerkleTree的数据结构设计查询引擎数据存储结构；当数据所有者添加数据集时，数据文件首先对数据块通过分割进行分片，然后将各分片组织进一个树状结构中；最后，每一个数据块分布在IPFS网络的若干节点中；每个存储了数据块的IPFS节点成为这个数据块的提供者，可以被其他节点查找到，为其他节点提供该数据块。

3.根据权利要求2所述的基于星际网络文件系统的分布式协同查询处理系统，其特征在于，通过设计分布式查询引擎的存储接口，使其可以运行在IPFS上，以IPFS上的文件为数据来源执行查询；从查询发起节点的角度，系统的工作流程为：

（a）用户通过用户界面向分布式查询引擎提交SQL的查询请求；

（b）分布式查询引擎从SQL语句中解析得到IPFS文件的CID；

（c）查询引擎的规划器与IPFS通信，得到待查询的文件在IPFS网络中存放的位置，从而建立查询计划，即如何从SQL转换为实际的查询操作；

（d）查询计划被通过IPFS的P2P网络发送至数据提供者节点处；

（e）提供数据的提供者节点监听IPFS网络上的请求包，然后从本地存储中读取数据，执行请求中的查询计划，并向查询发起者返回查询的结果；

（f）读写器完成实际的数据读写操作后得到查询结果，最终发送回发起查询的用户。

4.根据权利要求3所述的基于星际网络文件系统的分布式协同查询处理系统，其特征在于，用户发起一次读请求，系统工作流程为：

（a）用户通过用户界面向查询引擎输入SQL查询语句，包含要查询的数据集的CID，以及相应的数据过滤、排序或聚合操作；

（b）引擎解析SQL，得到IPFSCID，并查询IPFS得知数据集由多个块构成，得到每个块的CID；对于每个数据块，根据其CID查询IPFS的分布哈希表，得到IPFS网络中可以提供该数据分片的节点，以此建立查询计划；

（c） 查询计划被发送至提供者节点处，经过验证数据操作没有安全和隐私等风险后，各个节点按照查询计划从本地的IPFS存储中读取数据，得到该节点处的部分结果；

（d） 各个节点处部分结果集被发送回请求者的节点，并应用剩余的过滤、排序或聚合操作，形成最终的结果集，通过用户界面返回给用户。

5.根据权利要求3所述的基于星际网络文件系统的分布式协同查询处理系统，其特征在于，写请求在分布式查询引擎的语境下包含数据定义语言中的部分SQL语句和CTTAS语句两种；这两种语句嵌套一个SELECT查询，从这个查询的结果集创建新的表；于是分布式查询引擎中的写请求总是包含一个读请求；用户发起一次写请求时的系统工作流程中，写请求流程中解析SQL、生成查询计划和查询DHT获得提供者节点等过程与读请求完全一致；与读请求不同的部分是：

（a） 在查询计划被发送至提供者节点处后，各个节点读取存放在本地的数据块，应用数据变换操作后，得到本地的部分结果集；不同于读请求直接返回结果集，写请求的情况下引擎将结果集物化得到新的数据块，然后将其写入存储，并获得相应的新的CID；

（b） 各个节点处的新的CID被发送回请求者的节点后，不同于读请求向用户展示汇总后的结果集，写请求时引擎将多个CID聚合和重新封装后形成一个完整的CID返回给用户，这个CID也就是新的表对应的CID，可以用于此后的查询操作；

（c） 根据上述的读写流程，由于所有数据操作均在数据所有者的节点处执行的，数据使用者没有直接获得原始数据，因此实现了在保护数据所有者的权益的情况下，实现查询和利用数据集的目的。

Images