数据平台的设计和实现以及大赛中的应用*

王永坤，金耀辉,2+

1.上海交通大学 网络信息中心，上海 200240

2.上海交通大学 光纤通信国家重点实验室，上海 200240

1 引言

大数据研究及应用在最近几年得到了快速发展。大数据对各个行业的运行方式都产生了重大影响。在行政方面，大数据利用民生数据等帮助提高治理水平；在产业方面，大数据在需求、物流、营销等各个环节提供优化建议；在科学研究方面，大数据加速科学数据分析，帮助发现新领域。国家也对大数据技术高度重视。“十三五”规划中提出了“国家大数据战略”。国务院印发了《促进大数据发展行动纲要》，推动形成公共信息资源共享共用和大数据产业健康发展的良好格局。以往尘封的数据都在国家政策指导下逐步开放，特别是城市数据，关系民生，价值巨大，推动了智慧城市的发展。

经过近几年的研究和实践，大数据的很多理论和系统架构都逐渐成熟。但是在实际应用中，仍然有很多挑战。例如城市的数据主管部门可能缺乏大数据的存储和计算的设施；数据分析平台无法最大限度地共享数据的同时又隔离有害代码，保证数据和计算平台的安全等。

已有很多研究和系统在解决这些问题。开源社区提供了很多开源大数据解决方案，例如Apache Hadoop、Apache Hive[1]、Apache Spark[2]，来解决数据的存储、查询和计算，并且有专门公司提供企业级服务。在数据平台之上，提供了HUE、Jupyter、Zepplin等交互计算接口，并提供基本的访问控制。在学术界，DataHub[3]是MIT开发的一个试验性的平台，提供了数据的存储、共享和协作服务；用户可以发布自己的数据，也可以使用别人的数据。数据集有版本。用户可以通过Thrift使用不同的语言来操作数据。俄勒冈健康与科学大学（Oregon Health and Science University）与英特尔公司（Intel）合作建立了一个精准医疗分析平台，用于共享分析各机构的医疗数据，同时保护患者的隐私1）http://www.ohsu.edu/blogs/96kmiles/2015/08/20/intel-ohsu-announce-collaborative-cancer-cloud-at-intel-developer-forum/。。工业界有很多建立在云上的大数据平台方案，包括国外的亚马逊云AWS（Amazon Web services）、谷歌云平台大数据产品、微软云（Azure）上的Hadoop，国内有阿里云大数据服务ODPS（open data processing service）、天池及数加，腾讯大数据，百度大数据+。

上面提到的方案中，学术界的新想法需要更多实践来验证；工业界的方案规模大，技术水平高，相对而言成本也比学校等非盈利机构的平台要高，而且涉及的知识产权问题等较严格，数据开放共享的难度较大。

因此，本文的目的是完全独立地使用开源社区的解决方案来搭建一个一站式的共享数据、计算和代码的数据平台。本文的平台完全使用开源软件，自己选取设计组件，自己搭建和运维。开源软件代码公开并且由开源社区维护，非常适合高校这种IT经费相对较少但是智力资源较多的环境。本文的平台用于校内及部分公开服务，也定期提供给数据大赛这种大规模、高强度、集中式、密集计算的场景使用。根据了解，这在国内外高校中也是一种大胆的尝试，希望该经验可以给其他院校和机构一些参考。

本文的贡献概括如下：

（1）设计了一种数据和计算共享的数据平台架构，包含了数据平台和代码仓库，代码可以自动调度到平台上运行；

（2）选取硬件并配置了生产环境，给出基本的评测结果验证了这种设计的可行性；

（3）使用这个数据平台服务了大规模的上海开放数据创新应用大赛，介绍了其中的经验和见解。

本文内容组织如下：第2章介绍问题背景及需求；第3章介绍系统架构设计；第4章介绍系统的基本评估；第5章介绍数据平台在上海开放数据创新应用大赛中的应用；第6章总结全文。

2 背景及需求

2.1 异构数据实时采集和存储

得益于各行各业信息化的普及和物联网的发展，数据量正以惊人的速度增长。同时因为数据源不同，所以数据格式也多种多样，呈现异构特征。如何采集、传输和存储大量异构的数据是一个非常大的挑战。

采集程序通常分为实时采集和批量采集。实时采集的程序直接和生产环境的数据源对接，将最新生成的数据直接传回。一般采集程序是非常轻量级的，不能影响生产环境的运行，并且可以断点续传。批量采集程序一般是针对离线库或者备份定期进行大量数据回传，对生产环境的影响较小。

数据的可靠传输可以保证数据不丢包，最后的运算结果不出现偏差。一般的做法是针对每个或者多个数据包，接收端采取回复确认包（ACK）的方式来确保数据正确收到。没有收到的数据会要求重传。ACK的管理可以是集中式或者分布式。集中式的回传确认方式是发送方将已发数据包编号发给全局控制节点，接收方收到包后也将确认包发给同一个控制节点，控制节点来控制是否重发。优点是实现非常简单；缺点是控制节点可能成为性能瓶颈，并且有可能成为单点故障点（single point of failure，SPOF）。比较鲁棒的做法是让每个节点维护已发送包列表和确认包列表，将确认包一直回传至源发送节点。这种分布式的实现方式吞吐量大，整个系统可靠性高，但是实现复杂。第三种方式是使用集中的分布式存储来缓存数据，发送方和订阅方可以在一跳内得到数据。这种方式需要分布式存储，并且发送方和订阅方一般需要在同一子网内。本文采用第三种方式，利用Kafka来实现数据的传输和短期分享。

不同的数据源会生成不同的数据，形成多维数据，数据字段和格式不相同。对有些数据如交换机流量甚至需要自己定义如何从数据流中分割出数据包。由于数据生成速度快而且数据量较大，不适合使用传统的文件系统和关系型数据库，需利用分布式的文件系统来进行实时存储，并且选取的分布式文件系统需要很好地支持后续的计算。例如谷歌设计了GFS（Google file system）[4]来进行分布式存储。开源社区也开发了HDFS（Hadoop distributed file system），广泛用于各个大数据存储处理场景。目前流行的企业内部的数据湖（data lake）的做法也一般使用HDFS来进行存储。

2.2 异构数据的计算

对于多源异构数据，如果使用传统的关系型数据库来处理，需要事先定义好数据结构，然后导入数据，使用昂贵的硬件来支撑，并且扩展性不好，这不适合大量数据的场景。因此，谷歌设计了名为Big-Table[5]的数据模型，变schema-on-write为schema-onread，数据可以非常灵活地以动态的标签或者列名来存储。谷歌同时提出了MapReduce[6]的分布式计算模型，通过使用Map和Reduce操作，可以非常方便地将计算扩展到大量机器上。

很多传统的数据分析人员仍然偏好使用结构化查询语言（structured query language，SQL）来进行数据分析。因此，对于一个数据平台也需要考虑将SQL转换成分布式的查询和计算，降低传统分析人员的学习曲线。目前SQL-on-XXX技术也比较成熟，比如Apache Hive和Spark SQL等。

2.3 数据共享、计算隔离

大规模数据平台一般由不同组织、部门的分析人员来共享。即使同一部门的人员，也可能由于业务原因，需要对不同业务数据进行访问控制。因此，数据平台需要细粒度地支持不同的共享访问方案；需要支持对数据的分层抽象而不需要额外的存储空间；可以对接和集成常规的认证机制来保证用户身份的真实性；需要支持经典的角色访问控制机制（role-based access control，RBAC），来给不同业务、部门、组织的人员进行权限控制；对于更精细粒度和更加灵活的访问控制需求，需要平台能够支持属性访问控制机制（attribute-based access control，ABAC）。

对于计算，需要平台支持不同的调度，可以按照各种属性或者优先级来分配资源给不同的任务。同时对同等优先级的任务，需要保证公平。

Fig.1 Architecture of data platform图1 数据平台架构及组件

如果数据平台开放给公众使用，则可能需要对提交的任务代码进行审核。一般数据平台运算的代码基本都是编译好的代码，即使一些脚本语言写的代码，在运行时进行检查也比较困难。因此，需要在数据平台集成代码仓库的功能，以便按需审核任务代码。

3 数据平台架构设计

本文根据已有成熟的开源软件框架，搭建了数据平台。所有组件基本都是开源免费的，因为开源软件代码公开，并且由开源社区维护，非常适合高校这种IT经费相对较少但是智力资源较多的环境。本文设计的基本架构如图1所示。具体组件及设计方法会在下面几节展开介绍。

3.1 高可用存储系统

本文使用Hadoop分布式文件系统（HDFS）来储存数据。HDFS的控制节点NameNode存储了文件系统的元数据。如果NameNode崩溃，整个分布式文件系统会停止工作。因此NameNode非常重要，需要提供高可用的热备功能来保证NameNode常时在线。Hadoop文件系统早期版本并没有内置热备（failover）功能，待机的Secondary NameNode并不能接替崩溃的主NameNode。很多机构或者公司开发了自己的高可用（high availability，HA）版本。也有一些设计依赖外部HA机制，如DRBD（distributed replicated block device）。直到Hadoop 2.0发布，内置了HA的实现。默认使用的是ZKFC（Zookeeper failover controller），使用Apache Zookeeper集群来进行同步锁。

本文的数据平台也采用默认的HA方案。使用两台物理节点（并且部署在不同机架上）来启动两个NameNode，配置3个节点为日志节点（JournalNode）来在两个NameNode之间同步数据。使用ZKFC和Zookeeper集群来保证只有一个活跃NameNode节点，当活跃NameNode无响应的时候主动切换到备用的NameNode。

3.2 高可用作业调度系统

本文使用Hadoop YARN作为调度器，自动调度和部署用户的任务到不同机器上运行。资源管理器（resource manager）是YARN的一个重要组件，负责为所有的任务调度资源。因此资源管理器也需要HA配置。本文在两个节点分别配置两个一样的资源管理器，使用内置的利用Zookeeper集群的热备系统来自动检测失败的资源管理器，并切换到活跃的资源管理器上。

3.3 安全控制

本文使用Kerberos[7]来验证用户的身份。Kerberos是一个“客户端-服务器”模式的验证模型。用户先向认证服务器请求认证，获准后方可向服务器请求服务。

对于权限控制，使用了RBAC机制。对文件系统，根据文件的用户和分组来进行访问控制；对于Hive查询，也使用Sentry来实现访问控制。

3.4 查询和计算

本文的数据平台支持大部分的计算框架，包括将SQL转换为MapReduce任务的Apache Hive，使用RDD（resilient distributed datasets）[8]的 Spark 计算框架，以及原生的MapReduce和Streaming任务。

Apache Hive仍然是传统商业智能（business intelligence，BI）分析人员偏好的工具。可以使用SQL来操作数据，易于上手。Spark SQL[9]也类似，使用SQL在Spark计算框架上方便地进行数据操作。对于不习惯命令行的用户，也提供了HUE（Hadoop user experience）很方便地通过网页来提交查询，查看任务进展和查看结果或出错信息。

对于习惯于使用IPython[10]Notebook风格来进行数据分析的用户，也搭建了Jupyter Hub和Zepplin给用户使用Python Notebook或者Spark Notebook来进行交互式的数据分析。

另外也开放了数据仓库和商业智能系统的接口，可以使传统的数据分析工具如Qlik方便地接入。

3.5 数据质量分析

用户上传到数据平台的多源异构数据通常非常杂乱。即使用户以为整理好的结构化的数据，历经多次数据导入、系统升级等操作，实际也可能存在字段值缺失、不规范、类型不统一等问题。因此需要工具来帮助用户方便地查看数据质量，直观地给出数据质量报告，并且帮助矫正不正确的数据。

本文使用OpenRefine来帮助用户快速理解数据字段各种数据的分布情况，同时帮助用户改正、增强相关数据。对于数据量比较大的情况，将数据统计分析做成MapReduce任务，在集群上调度执行。

3.6 数据集成

对于如何将数据导入到数据平台中，本文使用以下3种方式：

（1）对于流式数据，使用Apache Kafka来实时进行数据的分享和交换，同时将数据导入到数据平台的Hadoop中来做离线计算；

（2）对于结构化数据，使用Apache Sqoop来选取相关的数据表，并且尽量按照原来的表结构存储到数据平台的Hadoop中；

（3）对于其他的各种以文件形式存在的数据，在进行格式转换后上传至数据平台中。

3.7 其他组件

本文在数据平台中集成了如下组件：

搜索引擎及查询可视化系统（Elastic&Kibana）。用户数据被转成JSON（JavaScript object notation）格式，然后存入Elastic集群中并被索引。用户可以使用Kibana界面来方便地查询并且实时地可视化结果。

为了满足一部分用户的近似实时的数据存取需求，提供了NoSQL数据库，如Apache Cassandra。Cassandra上层使用的是BigTable的数据模型，数据存取非常灵活；底层使用的是亚马逊Dynamo[11]的P2P架构，可用性和可靠性非常高。

针对监控，部署了Zabbix、Grafana以及Netdata，可以非常方便地查看整个系统资源的实时和历史利用状况。

所有的部署和运维都是由集群自动化工具Ansible来完成的，重复部署及扩展都很方便。部署和运维脚本开发完成后，可以比较容易地将配置从数十台机器扩展到数百台甚至更多。

3.8 代码仓库、审核和调度

对于用户来讲，也希望能有一站式的代码存储和数据查询的服务。传统做法是将代码提交至Github或者Bitbucket等公有的代码仓库，或者企业、私人的存储空间中，并将代码移到数据提供方来进行查询，这种方式比较繁琐。对于数据平台维护方来说，希望能将有限的资源尽可能有效利用起来，同时也希望数据平台能免于恶意代码的攻击。

针对上述用户的需求，本文在数据平台中集成了带版本控制的代码仓库的功能，使用GitLab来搭建代码存储和版本控制系统。通过GitLab搭建的代码管理系统，和Github功能类似，可以使用git来管理代码版本，可以浏览代码，管理缺陷及注释，并支持团队协作开发。这样可以帮助平台运维方来掌控用户的代码，避免恶意代码损害平台和其他用户的资源。

本文针对用户的代码进行初步的检查，帮助用户提前发现代码中遗漏的问题，并且阻止恶意代码。代码的自动检查是个非常大的挑战，已有的技术主要是针对代码的静态分析。Facebook Infer可以检查Java、C和Objective-C代码；对于Java，也可以使用经典的FindBugs结合Jenkins，在代码集成测试的时候进行分析；对于Python代码可以使用Pylint；对于C和C++代码，可以使用经典的Valgrind来进行分析。Cloudera还使用了商业软件来对代码进行安全扫描2）Quality Assurance at Cloudera:Static Source-Code Analysis,https://blog.cloudera.com/blog/2016/03/quality-assurance-at-clouderastatic-source-code-analysis/。。

除了扫描用户的源代码外，还对数据进行了细粒度的访问控制。给数据和帐号仔细设置了访问权限，最大限度限制了每个帐号对系统的无关访问。并且调整Hadoop/Spark的资源分配算法，保证在公平的前提下资源尽量得到充分利用。

本文并没有对用户的代码性能进行分析和改进，但会推荐用户自己选用合适的数据结构和存储方式来加速计算，也推荐用户使用平台内置的工具来帮助提高执行速度，比如使用Apache Hive的EXPLAIN命令来查看执行计划。

本文设定一些限制条件来选取代码仓库的代码到数据平台运行。开设“发布（release）”代码分支仓库让用户将准备好的代码提交进来。只有源代码分析通过的任务才会被调度到数据平台上执行。

3.9 系统备份和恢复

备份和恢复是每个系统必须考虑的问题。本文的数据平台的存储系统存储了大量数据，对此在应用程序层（HDFS）默认设置了3个数据副本，这样既实现了高可用和高访问吞吐量，也在一定程度上实现了数据的备份。3个数据副本分别在不同机架的不同机器中，避免了机器或者机架不可用时丢失数据的情况。元数据也同样重要，本文的数据平台主要有文件系统元数据、查询系统Hive元数据。文件系统的元数据存储在控制节点中，3.1节介绍了高可用的控制节点设计，两个控制节点互为备份。因为元数据总量较小，所以也在考虑使用离线备份工具备份并保存最近的数据。查询系统Hive元数据保存在关系型数据库MySQL中。本文设计了MySQL集群来保证高可用性，同时也做定期的备份。

代码仓库GitLab也使用文件系统存储数据，使用关系型数据库来存储元数据。本文参考了官方文档中的高可用设计3）GitLab Documentation HighAvailability,http://docs.gitlab.com/ce/administration/high_availability/README.html。：使用负载均衡、网络文件系统（network file system，NFS）等来保证高可用性。对于元数据，也使用了数据库集群，并且做定期备份。

3.10 系统扩展

本文分析了未来的潜在需求，数据平台的系统扩展主要在存储和计算上。归功于Hadoop等软件的高可扩展性设计，数据平台的线性扩展非常容易。新添加的服务器可以快速安装Hadoop的计算和存储模块，加入集群参与存储和计算。本文使用的Hadoop版本也实现了HDFS Federation的功能，因此文件系统元数据也可以通过给控制节点添加服务器来进行线性扩展。

4 应用评估

下面介绍如何根据需求选取服务器来搭建生产环境，并进行基本的评估。

4.1 平台部署

本文简单地将服务器按功能分为两大类：一类是控制节点；另一类是计算和存储节点。控制节点需要存取元数据，对内存和存储性能要求较高。因此使用大内存节点（256 GB），存储介质使用了多块高性能、大容量的闪存固态盘（solid state drives，SSD），这些固态盘配置成磁盘阵列RAID10模式（磁盘组内是RAID1，磁盘组间是RAID0），容错能力比较好。计算和存储节点的存储容量要求较高，因此给每个节点选用了12块6 TB的磁盘，并且配置成JBOD（just a bunch of disks）模式，是为了更好地利用磁盘空间。对于数据安全和负载平衡，则通过数据平台软件在多机间实现。另外对所有节点都额外配置了2块10K热插拔硬盘做成RAID1给操作系统使用。节点间使用了双路万兆网卡互联。在操作系统内使用动态链路聚合模式将两路链接聚合起来，带宽加倍可达到20 Gb/s。集群节点间的通信带宽的提高对Hadoop/Spark等的Shuffle操作非常有利，因为Shuffle操作是Reducer从Mapper那里拷贝中间结果，涉及大量的网络数据传输。两种服务器配置如表1所示。第一期购置了16台服务器，包括4台控制节点，12台计算和存储节点，总存储容量接近900 TB。后期计划扩容至目前规模的30倍左右。

Table 1 Specifications of servers表1 数据平台硬件配置

4.2 测试及分析

本节的目的是验证平台可以按照预期来提供服务。数据平台基本组件都是基于开源软件和推荐配置，因此本文的目的不是和其他平台进行性能比较，而是对系统进行压力测试，并且提供结果给用户来估计任务耗时。有关数据平台的性能测试，学术界、产业界和开源社区已经有大量很好的工作。有关测试工具，用户可以参考中科院计算所的BigDataBench[12]以及英特尔公司的HiBench[13]。

本文测试的主要软件部件的版本如表2所示。

Table 2 Software configuration表2 软件版本

本文使用了Hadoop安装包内置的TeraSort排序任务来进行基本的测试。图2（a）显示了本文平台使用TeraSort对不同大小的数据集排序所耗费的时间。图2（b）显示了使用不同数目的Reducer对1 TB数据集排序所耗费的时间。可以看到在保证结果正确的前提下，增加Reducer的数目可以显著缩短任务的执行时间。

Fig.2 TeraSort benchmark图2 TeraSort测试

由于机器学习算法的用户使用率较高，本文选取了3种典型的算法，分别是用于分类的Bayes、用于聚类的K-Means以及用于排名的PageRank。在Hi-Bench 5.0的默认设置下，对每种算法，分别用Hadoop的Map/Reduce框架和Spark来运行测试，结果如表3所示。可以看到基于内存计算的Spark框架有较大的优势。本测试并非饱和压力测试，结果仅供用户提交任务时参考。

本文仍然有很多优化的空间，例如使用特别的压缩文件格式可以显著提高磁盘输入输出（I/O）性能，能够减少CPU的iowait等待时间（TeraSort测试中观察到CPU的一些iowait时间）。也可以结合一些特定的易于压缩的存储格式（比如Parquet列存储格式，Parquet部分算法来自Dremel[14]）来研究性能提升。也可以深入分析BigDataBench以及HiBench的压力测试结果。

Table 3 HiBench report表3 HiBench测试结果①

5 开放数据大赛SODA应用

上海市拥有2 415.27万4）2015年上海市国民经济和社会发展统计公报，上海市统计局，国家统计局上海调查总队，2016-02-29。常住居民以及庞大的公共设施系统，如公共交通系统，政府手中积累了大量的与城市生活息息相关的数据。为了提升数据的价值，上海市政府组织了上海开放数据创新应用大赛（Shanghai Open Data Apps，SODA），利用大众的智慧来一起挖掘城市数据的价值。大赛总计有来自国内外的2 914人报名参赛，组队817个。参赛选手的背景非常多样化，有专业的数据分析师、工程师、设计师和产品经理等，也有高校教师、公务员、学生等。选手来自的机构也包括了国内外知名高校（如MIT、清华、交大、复旦等）和知名企业（如阿里巴巴）等。大赛征集了有效创意方案总计505个5）2015上海开放数据创新应用大赛决赛鸣锣，http://sh.qq.com/a/20151116/038896.htm。。数量众多的参赛选手和大量的创意方案产生，体现了数据的密集使用，离不开对数据高强度的计算。

关于数据，除了上海市政府数据服务网（http://www.datashanghai.gov.cn）开放的约1 000个数据集外，上海市政府又特别开放了10个大容量高质量的数据集，如表4所示。其中一卡通刷卡的数据量达到了4亿多条，而出租车行车数据更是超过了34亿条。本文的设计虽然着眼于大规模的数据平台集群，但是限于硬件资源，搭建的生产环境仍是一个小规模的集群，用于先导试验。这些数据对本文设计的计算平台来讲，是一个极大的挑战。

Table 4 SODAdataset表4 SODA数据集

限于篇幅和大赛组织方对选手代码和使用行为的保密协议，本文仅描述一些有趣的规律，希望能为其他平台设计和优化提供参考。

发现大多数计算仍然是用于数据统计的聚集（aggregation）操作。例如，某一个方案计算了出租车的平均速度。由于出租车在不同时间段、不同路段和不同方向上的平均速度是不一样的，一般通过计算某一较短时间段内的、某路段上同方向的所有车的平均车速，来设计相关预测。其中路段是由经纬度来按用户的需求划分的。下面给出了一个典型的工作日平均速度计算的脚本（Apache Hive Query），简单起见，按小时来计算平均值，实际的时间间隔要求更短。

上面的代码非常简单，但是多人并发访问的数据量较大。对34亿条记录计算后结果会保存到内存数据库或者Key-Value Store中，用于近似实时的查询。某些选手只对特别的路段（road_segment）感兴趣，会对路段的经纬度进行过滤。因此路段经纬度的索引设置比较重要，索引方案也要根据数据类型进行选取。对路段使用了Hive中简单稳定的Compact-IndexHandler，而对行车方向direction（上行、下行）使用了位图索引（BitmapIndexHandler）[15]。

Fig.3 Running Pyspark and regression prediction on YARN by Jupyter图3 使用Jupyter调用Pyspark在YARN集群上运行回归预测

发现大量的聚集操作主要是数据预处理，给后面的分类或预测算法提供足够的特征。经过预处理后的数据集已经变得非常小，因此很多用户将处理好的数据集下载到本地，然后使用算法进行分析预测。例如公交卡刷卡数据有4亿多条，但是经过处理识别后，得到的一些特别的事件记录只有数十条。因此将来会考虑对数据做更进一步的预处理来减少用户重复进行预处理的时间。

对于使用机器学习的运行任务，本文平台也给用户提供了Jupyter接口来使用Python Notebook。图3显示了使用Jupyter调用Spark的Python接口（Pyspark），在YARN集群上运行不同的回归（regression）分析进行预测的例子（代码只是示例，从用户代码提取而来）。

对用户代码仓库中的代码，仅调度选手的代码仓库的发布（release）分支中的代码。这样做的好处是有效减少了作业的总数量，降低了单个作业的响应时间。选手的大量调试代码先要在线下对样本数据进行调试，通过后才会调度，这也促使选手在提交代码之前认真思考代码的目的，因此线上的代码质量比较高（完整性好，bug较少）。

6 结束语

本文尝试完全使用开源软件设计并配置了一个存储、计算及代码并存的数据平台。用户不仅可以共享数据和计算，还可以追踪自己的代码的改变。平台可以自动审核用户代码，并且自动调度到数据平台进行计算。选取硬件搭建了一个生产环境，并且给出了基本的测试。使用这个平台服务于上海开放数据创新应用大赛（SODA），给出了大赛使用中的经验、分析和见解。将来会考虑对平台进行深度优化，并且探索如何在各平台间进行数据和计算的共享。

致谢感谢上海市经信委和SODA组委会的大力支持。

[1]Thusoo A,Sarma J S,Jain N,et al.Hive—a warehousing solution over a Map-Reduce framework[J].Proceedings of the VLDB Endowment,2009,2(2):1626-1629.

[2]Zaharia M,Chowdhury M,Franklin M J,et al.Spark:cluster computing with working sets[C]//Proceedings of the 2nd USENIX Workshop on Hot Topics in Cloud Computing,Boston,Jun 22,2010.Berkeley:USENIXAssociation,2010:10.

[3]Bhardwaj A P,Deshpande A,Elmore A J,et al.Collaborative data analytics with DataHub[J].Proceedings of the VLDB Endowment,2015,8(12):1916-1919.

[4]Ghemawat S,Gobioff H,Leung S T.The Google file system[C]//Proceedings of the 19th ACM Symposium on Operating Systems Principles,Bolton Landing,Oct 19-22,2003.New York:ACM,2003:29-43.

[5]Chang F,Dean J,Ghemawat S,et al.Bigtable:a distributed storage system for structured data[C]//Proceedings of the 7th Symposium on Operating Systems Design and Implementation,Seattle,Nov 6-8,2006.Berkeley:USENIX Association,2006:205-218.

[6]Dean J,Ghemawat S.MapReduce:simplified data processing on large clusters[C]//Proceedings of the 6th Symposium on Operating System Design and Implementation,San Francisco,Dec 6-8,2004.Berkeley:USENIX Association,2004:137-150.

[7]Neuman B C,Ts′o T.Kerberos:an authentication service for computer networks[J].IEEE Communications Magazine,1994,32(9):33-38.

[8]Zaharia M,Chowdhury M,Das T,et al.Resilient distributed datasets:a fault-tolerant abstraction for in-memory cluster computing[C]//Proceedings of the 9th USENIX Symposium on Networked Systems Design and Implementation,San Jose,Apr 25-27,2012.Berkeley:USENIX Association,2012:15-28.

[9]Armbrust M,Xin R S,Lian Cheng,et al.Spark SQL:relational data processing in Spark[C]//Proceedings of the 2015 International Conference on Management of Data,Melbourne,May 31-Jun 4,2015.New York:ACM,2015:1383-1394.

[10]Bernard J.Running scientific code using IPython and SciPy[J].Linux Journal,2013(228):3.

[11]DeCandia G,Hastorun D,Jampani M,et al.Dynamo:Amazon's highly available key-value store[C]//Proceedings of the 21st Symposium on Operating Systems Principles,Stevenson,Oct 14-17,2007.New York:ACM,2007:205-220.

[12]Wang Lei,Zhan Jianfeng,Luo Chunjie,et al.BigDataBench:a big data benchmark suite from Internet services[C]//Proceedings of the 20th International Symposium on High Performance Computer Architecture,Orlando,Feb 15-19,2014.Washington:IEEE Computer Society,2014:488-499.

[13]Huang Shengsheng,Huang Jie,Dai Jinquan,et al.The Hi-Bench benchmark suite:characterization of the MapReducebased data analysis[C]//Proceedings of the 29th International Conference on Data Engineering Workshops,Long Beach,Mar 1-6,2010.Washington:IEEE Computer Society,2010:41-51.

[14]Melnik S,Gubarev A,Long Jingjing,et al.Dremel:interactive analysis of Web-scale datasets[J].Communications of theACM,2011,54(6):114-123.

[15]Johnson T.Performance measurements of compressed bitmap indices[C]//Proceedings of the 25th International Conference on Very Large Data Bases,Edinburgh Sep 7-10,1999.San Francisco:Morgan Kaufmann Publishers Inc,1999:278-289.