大数据的分布式数据库技术的对比

大数据技术的实现离不开很多其他的技术，我们提到最多的就是Hadoop技术，其实就目前而言，Hadoop技术看似是自成一套体系，其实并不是这样的，Hadoop和Spark以及分布式数据库其实也是存在差异的，我们就在这篇文章中给大家介绍一下这些内容。

首先我们说一说大数据分析，现在的大数据分析体系以Hadoop生态为主，而近年来逐渐火热的Spark技术也是主要的生态之一。可以这么说，Hadoop技术只能算是以HDFS+YARN作为基础的分布式文件系统，而不是数据库。我们提到的Hadoop的历史可以向前追溯10年，当年谷歌为了在几万台PC服务器上构建超大数据集合并提供极高性能的并发访问能力，从而发明了一种新的技术，而这个技术，也是Hadoop诞生的理论基础。如果我们从Hadoop的诞生背景可以看出，其主要解决的问题是超大规模集群下如何对非结构化数据进行批处理计算。实际上，在Hadoop架构中，一个分布式任务可以是类似传统结构化数据的关联、排序、聚集 *** 作，也可以是针对非结构化数据的用户自定义程序逻辑。

那么Hadoop的发展道路是什么样的呢。最开始的Hadoop以Big、Hive和MapReduce三种开发接口为代表，分别适用于脚本批处理、SQL批处理以及用户自定义逻辑类型的应用。而Spark的发展更是如此，最开始的SparkRDD几乎完全没有SQL能力，还是套用了Hive发展出的Shark才能对SQL有了一部分的支持。但是，随着企业用户对Hadoop的使用越发广泛，SQL已经渐渐成为大数据平台在传统行业的主要访问方式之一。

下面我们就说一说分布式数据库，分布式数据库有着悠久的历史，从以Oracle RAC为代表的联机交易型分布式数据库，到IBM DB2 DPF统计分析性分布式数据库，分布式数据库覆盖了OLTP与OLAP几乎全部的数据应用场景。而大部分分布式数据库功能集中在结构化计算与在线增删改查上。但是，这些传统的分布式数据库以数仓及分析类OLAP系统为主，其局限性在于，其底层的关系型数据库存储结构在效率上并不能满足大量高并发的数据查询以及大数据数据加工和分析的效率要求。因此，分布式数据库在近几年也有着极大的转型，从单一的数据模型向多模的数据模型转移，将OLTP、联机高并发查询以及支持大数据加工和分析结合起来，不再单独以OLAP作为设计目标。同时，分布式数据库在访问模式上也出现了K/V、文档、宽表、图等分支，支持除了SQL查询语言之外的其他访问模式，大大丰富了传统分布式数据库单一的用途。一般来说，多模数据库的主要目的是为了满足具有高性能要求的 *** 作型需求以及目标明确的数据仓库功能，而不是类似大数据深度学习等数据挖掘场景。这就是分布式数据库的实际情况。

我们在这篇文章中给大家介绍了大数据分析以及分布式数据库的相关知识，通过这些内容相信大家已经理解了其中的具体区别了吧，如果这篇文章能够帮助到大家这就是我们最大的心愿。

之前做过一年的spark研发，之前在阿里与腾讯也做了很久的hive，所以对这方面比较了解。

第一：其实快多少除了跟spark与hive本身的技术实现外，也跟机器性能，底层 *** 作系统的参数优化息息相关，不能一概而论。

第二：hive 目前应该还是业界的主流，毕竟快与慢很多时候并非是至关重要的，对于一个生产系统来说，更重要的应该是稳定性，spark毕竟还算是比较新兴的事务，快确实快，但是稳定性上距离hive相差甚远。关于spark我们也修复了很多关于内存泄露的BUG，因为您问的是性能，所以不过多介绍（可以跟我要YDB编程指南，里面有我对这些BUG的修正）

第三：关于性能，我测试的可能不够全面，只能在排序与检索过滤上提供我之前的基于YDB的BLOCK sort测试报告供您参考（百度上贴word太费劲，您可以跟我要 word文档）。

排序可以说是很多日志系统的硬指标（如按照时间逆序排序），如果一个大数据系统不能进行排序，基本上是这个系统属于不可用状态，排序算得上是大数据系统的一个“刚需”,无论大数据采用的是hadoop,还是spark，还是impala,hive，总之排序是必不可少的，排序的性能测试也是必不可少的。

有着计算奥运会之称的Sort Benchmark全球排序每年都会举行一次，每年巨头都会在排序上进行巨大的投入，可见排序速度的高低有多么重要！但是对于大多数企业来说，动辄上亿的硬件投入，实在划不来、甚至远远超出了企业的项目预算。相比大数据领域的暴力排序有没有一种更廉价的实现方式？

在这里，我们为大家介绍一种新的廉价排序方法，我们称为blockSort。

500G的数据300亿条数据，只使用4台 16核，32G内存，千兆网卡的虚拟机即可实现 2~15秒的 排序 （可以全表排序，也可以与任意筛选条件筛选后排序）。

一、基本的思想是这样的，如下图所示：

1将数据按照大小预先划分好，如划分成 大、中、小三个块(block)。

2如果想找最大的数据，那么只需要在最大的那个块里去找就可以了。

3这个快还是有层级结构的，如果每个块内的数据量很多，可以到下面的子快内进行继续查找，可以分多个层进行排序。

4采用这种方法，一个亿万亿级别的数据（如long类型），最坏最坏的极端情况也就进行2048次文件seek就可以筛选到结果。

怎么样，原理是不是非常简单，这样数据量即使特别多，那么排序与查找的次数是固定的。

二、这个是我们之前基于spark做的性能测试，供大家参考

在排序上，YDB具有绝对优势，无论是全表，还是基于任意条件组合过滤，基本秒杀Spark任何格式。

测试结果(时间单位为秒)

三、当然除了排序上，我们的其他性能也是远远高于spark，这块大家也可以了解一下

1、与Spark txt在检索上的性能对比测试。

注释：备忘。下图的这块，其实没什么特别的，只不过由于YDB本身索引的特性，不想spark那样暴力，才会导致在扫描上的性能远高于spark，性能高百倍不足为奇。

下图为ydb相对于spark txt提升的倍数

2、这些是与 Parquet 格式对比（单位为秒）

3、与ORACLE性能对比

跟传统数据库的对比，已经没啥意义，Oracle不适合大数据，任意一个大数据工具都远超oracle 性能。

4稽查布控场景性能测试

四、YDB是怎么样让spark加速的？

基于Hadoop分布式架构下的实时的、多维的、交互式的查询、统计、分析引擎，具有万亿数据规模下的秒级性能表现，并具备企业级的稳定可靠表现。

YDB是一个细粒度的索引，精确粒度的索引。数据即时导入，索引即时生成，通过索引高效定位到相关数据。YDB与Spark深度集成，Spark对YDB检索结果集直接分析计算，同样场景让Spark性能加快百倍。

五、哪些用户适合使用YDB？

1传统关系型数据，已经无法容纳更多的数据，查询效率严重受到影响的用户。

2目前在使用SOLR、ES做全文检索，觉得solr与ES提供的分析功能太少，无法完成复杂的业务逻辑，或者数据量变多后SOLR与ES变得不稳定，在掉片与均衡中不断恶性循环，不能自动恢复服务，运维人员需经常半夜起来重启集群的情况。

3基于对海量数据的分析，但是苦于现有的离线计算平台的速度和响应时间无满足业务要求的用户。

4需要对用户画像行为类数据做多维定向分析的用户。

5需要对大量的UGC（User Generate Content）数据进行检索的用户。

6当你需要在大数据集上面进行快速的，交互式的查询时。

7当你需要进行数据分析，而不只是简单的键值对存储时。

8当你想要分析实时产生的数据时。

ps: 说了一大堆，说白了最适合的还是踪迹分析因为数据量大，数据还要求实时，查询还要求快。这才是关键。

Spark对硬件的要求

估计所有的spark开发者都很关心spark的硬件要求。恰当的硬件配置需要具体情况具体分析，在这里给出以下建议。主要译自官网

一，存储系统

因为大多数Spark工作可能需要从外部存储系统（例如Hadoop文件系统或HBase）中读取输入数据，所以将spark尽可能部署到靠近存储系统很重要。所以，有如下建议：

1，如果可能，在与HDFS相同的节点上运行Spark。最简单的方式是将spark的Standalone集群和hadoop集群安装在相同的节点，同时配置好Spark和hadoop的内存使用，避免相互干扰(对于hadoop，每个task的内存配置参数是mapredchildjavaopts；mapreducetasktrackermaptasksmaximum 和mapreducetasktrackerreducetasksmaximum决定了task的数目)。也可以将hadoop和spark运行在共同的集群管理器上，如mesos和 yarn。

2，如果不可能，请在与HDFS相同的局域网中的不同节点上运行Spark。

3，对于低延迟数据存储（如HBase），可能优先在与存储系统不同的节点上运行计算任务以避免干扰。

二，本地磁盘

虽然Spark可以在内存中执行大量的计算，但它仍然使用本地磁盘来存储不适合RAM的数据，以及在stage之间，也即shuffle的中间结果。建议每个节点至少有4-8块磁盘，并且不需要RAID，仅仅是独立的磁盘挂在节点。在Linux中，使用noatime选项安装磁盘，以减少不必要的写入。在spark任务中，sparklocaldir配置可以十多个磁盘目录，以逗号分开。如果运行在hdfs上，与hdfs保持一致就很好。

使用noatime选项安装磁盘，要求当挂载文件系统时，可以指定标准Linux安装选项（noatime），这将禁用该文件系统上的atime更新。磁盘挂在命令：

mount -t gfs BlockDevice MountPoint -onoatime

BlockDevice 指定GFS文件系统驻留的块设备。

MountPoint 指定GFS文件系统应安装的目录。

例子：

mount -t gfs /dev/vg01/lvol0 /gfs1 -onoatime

三，内存

单台机器内存从8GB到数百GB，spark都能运行良好。在所有情况下，建议仅为Spark分配最多75％的内存;留下其余的 *** 作系统和缓冲区缓存。

需要多少内存取决于你的应用程序。要确定你的应用的特定数据集需要多大内存，请加载部分数据集到内存，然后在Spark UI的Storage界面去看它的内存占用量。

请注意，内存使用受到存储级别和序列化格式的极大影响 - 有关如何减少内存使用的技巧，请参阅另一篇调优的文章。

最后，请注意，对于超过200GB的内存的机器JAVA VM运行状态并不一直表现良好。如果买的机器内存超过了200GB，那么可以在一个节点上运行多个worker。Spark Standalone模式下，可以在配置文件 conf/spark-envsh中设置SPARK_WORKER_INSTANCES的值来设置单节点worker的数目。也可以设置SPARK_WORKER_CORES参数来设置每个Worker的cpu数目。

四，网络

根据以往的经验，假如数据是在内存中，那么spark的应用的瓶颈往往就在网络。用10 Gigabit或者更高的网络，是使spark应用跑的最更快的最佳方式。特别是针对“distributed reduce”应用，如group-bys,reduce-bys和sql joins，就表现的更加明显。在任何给定的应用程序中，可以通过spark ui查看spark shuffle过程夸网络传输了多少数据。

五， cpu

对于每台机器几十个cpu的机器，spark也可以很好的扩展，因为他在线程之间执行最小的共享cpu。应该每台机器至少配置8-16个内核。根据cpu负载，可能需要更多的cpu：一旦数据在内存中，大多数应用程序的瓶颈就在CPU和网络。

推荐阅读：

面试必备|spark 高层通用调优

Spark Adaptive Execution调研

Spark 的硬件配置

从MapReduce的兴起，就带来一种思路，就是希望通过大量廉价的机器来处理以前需要耗费昂贵资源的海量数据。这种方式事实上是一种架构的水平伸缩模式——真正的以量取胜。毕竟，以现在的硬件发展来看，CPU的核数、内存的容量以及海量存储硬盘，都慢慢变得低廉而高效。然而，对于商业应用的海量数据挖掘或分析来看，硬件成本依旧是开发商非常关注的。当然最好的结果是：既要马儿跑得快，还要马儿少吃草。

\\

Spark相对于Hadoop的MapReduce而言，确乎要跑得迅捷许多。然而，Spark这种In-Memory的计算模式，是否在硬件资源尤其是内存资源的消耗上，要求更高呢？我既找不到这么多机器，也无法租用多台虚拟instance，再没法测评的情况下，只要寻求Spark的官方网站，又或者通过Google搜索。从Spark官方网站，Databricks公司Patrick Wendell的演讲以及Matei Zaharia的Spark论文，找到了一些关于Spark硬件配置的支撑数据。

\\

Spark 与存储系统

\\

如果Spark使用HDFS作为存储系统，则可以有效地运用Spark的standalone mode cluster，让Spark与HDFS部署在同一台机器上。这种模式的部署非常简单，且读取文件的性能更高。当然，Spark对内存的使用是有要求的，需要合理分配它与HDFS的资源。因此，需要配置Spark和HDFS的环境变量，为各自的任务分配内存和CPU资源，避免相互之间的资源争用。

\\

若HDFS的机器足够好，这种部署可以优先考虑。若数据处理的执行效率要求非常高，那么还是需要采用分离的部署模式，例如部署在Hadoop YARN集群上。

\\

Spark 对磁盘的要求

\\

Spark是in memory的迭代式运算平台，因此它对磁盘的要求不高。Spark官方推荐为每个节点配置4-8块磁盘，且并不需要配置为RAID（即将磁盘作为单独的mount point）。然后，通过配置sparklocaldir来指定磁盘列表。

\\

Spark 对内存的要求

\\

Spark虽然是in memory的运算平台，但从官方资料看，似乎本身对内存的要求并不是特别苛刻。官方网站只是要求内存在8GB之上即可（Impala要求机器配置在128GB）。当然，真正要高效处理，仍然是内存越大越好。若内存超过200GB，则需要当心，因为JVM对超过200GB的内存管理存在问题，需要特别的配置。

\\

内存容量足够大，还得真正分给了Spark才行。Spark建议需要提供至少75%的内存空间分配给Spark，至于其余的内存空间，则分配给 *** 作系统与buffer cache。这就需要部署Spark的机器足够干净。

\\

考虑内存消耗问题，倘若我们要处理的数据仅仅是进行一次处理，用完即丢弃，就应该避免使用cache或persist，从而降低对内存的损耗。若确实需要将数据加载到内存中，而内存又不足以加载，则可以设置Storage Level。09版本的Spark提供了三种Storage Level：MEMORY_ONLY（这是默认值），MEMORY_AND_DISK，以及DISK_ONLY。

\\

关于数据的持久化，Spark默认是持久化到内存中。但它也提供了三种持久化RDD的存储方式：

\\

•       \\t

in-memory storage as deserialized Javaobjects

\\t\\t

•       \\t

in-memory storage as serialised data

\\t\\t

•       \\t

on-disk storage

\\t\

第一种存储方式性能最优，第二种方式则对RDD的展现方式（Representing）提供了扩展，第三种方式则用于内存不足时。

\\

然而，在最新版（V102）的Spark中，提供了更多的Storage Level选择。一个值得注意的选项是OFF_HEAP，它能够将RDD以序列化格式存储到Tachyon中。相比MEMORY_ONLY_SER，这一选项能够减少执行垃圾回收，使Spark的执行器（executor）更小，并能共享内存池。Tachyon是一个基于内存的分布式文件系统，性能远超HDFS。Tachyon与Spark同源同宗，都烙有伯克利AMPLab的印记。目前，Tachyon的版本为050，还处于实验阶段。

\\

注意，RDDs是Lazy的，在执行Transformation *** 作如map、filter时，并不会提交Job，只有在执行Action *** 作如count、first时，才会执行Job，此时才会进行数据的加载。当然，对于一些shuffle *** 作，例如reduceByKey，虽然仅是Transformation *** 作，但它在执行时会将一些中间数据进行持久化，而无需显式调用persist()函数。这是为了应对当节点出现故障时，能够避免针对大量数据进行重计算。要计算Spark加载的Dataset大小，可以通过Spark提供的Web UI Monitoring工具来帮助分析与判断。

\\

Spark的RDD是具有分区（partition）的，Spark并非是将整个RDD一次性加载到内存中。Spark针对partition提供了eviction

policy，这一Policy采用了LRU（Least Recently Used）机制。当一个新的RDD分区需要计算时，如果没有合适的空间存储，就会根据LRU策略，将最少访问的RDD分区d出，除非这个新分区与最少访问的分区属于同一个RDD。这也在一定程度上缓和了对内存的消耗。

\\

Spark对内存的消耗主要分为三部分：

\\

1     \\t

数据集中对象的大小；

\\t\\t

2     \\t

访问这些对象的内存消耗；

\\t\\t

3     \\t

垃圾回收GC的消耗。

\\t\

一个通常的内存消耗计算方法是：内存消耗大小= 对象字段中原生数据 (2~5)。这是因为Spark运行在JVM之上， *** 作的Java对象都有定义的“object header”，而数据结构（如Map，LinkedList）对象自身也需要占用内存空间。此外，对于存储在数据结构中的基本类型，还需要装箱（Boxing）。Spark也提供了一些内存调优机制，例如执行对象的序列化，可以释放一部分内存空间。还可以通过为JVM设置flag来标记存放的字节数（选择4个字节而非8个字节）。在JDK 7下，还可以做更多优化，例如对字符编码的设置。这些配置都可以在spark-envsh中设置。

\\

Spark 对网络的要求

\\

Spark属于网络绑定型系统，因而建议使用10G及以上的网络带宽。

\\

Spark 对 CPU 的要求

\\

Spark可以支持一台机器扩展至数十个CPU

core，它实现的是线程之间最小共享。若内存足够大，则制约运算性能的就是网络带宽与CPU数。

\\

Spark官方利用Amazon EC2的环境对Spark进行了基准测评。例如，在交互方式下进行数据挖掘（Interative Data Mining），租用Amazon EC2的100个实例，配置为8核、68GB的内存。对1TB的维基百科页面查阅日志（维基百科两年的数据）进行数据挖掘。在查询时，针对整个输入数据进行全扫描，只需要耗费5-7秒的时间。如下图所示：

在Matei Zaharia的Spark论文中还给出了一些使用Spark的真实案例。视频处理公司Conviva，使用Spark将数据子集加载到RDD中。报道说明，对于200GB压缩过的数据进行查询和聚合 *** 作，并运行在两台Spark机器上，占用内存为96GB，执行完全部 *** 作需要耗费30分钟左右的时间。同比情况下，Hadoop需要耗费20小时。注意：之所以200GB的压缩数据只占用96GB内存，是因为RDD的处理方式，使得我们可以只加载匹配客户过滤的行和列，而非所有压缩数据。`

Spark集群硬件配置推荐

计算与存储：

大多数Spark作业可能需要从外部存储系统（例如 ：Cassandra、Hadoop文件系统或HBase）读取输入数据，所以要让Spark计算引擎尽可能靠近数据持久层。如果使用HDFS作为数据存储集群，可以在相同的集群上部署Spark集群，并配置Spark和Hadoop的内存和CPU使用率以避免干扰。我们的生产存储使用的是Cassandra集群，spark

master 服务单独部署，其它节点同时部署：Cassandra

+ spark worker，保证spark

worker 节点可以快速从本地读取数据进行计算汇总。

磁盘：

虽然Spark可以在内存中执行大量的计算，但它仍然可能会使用本地磁盘来存储不适用于RAM的数据，建议每个节点配置4-8个磁盘，不需要配置RAID（磁盘阵列），磁盘成本越来越低，可以考虑配置ssd硬盘，可以大幅提升性能。另外；在Linux中，使用noatime选项挂载磁盘，以减少不必要的写入 *** 作。 在Spark中，可以将sparklocaldir变量配置为多个本地磁盘的地址，多个地址之间以逗号分隔。

内存

建议为Spark分配的内存容量不大于机器总内存容量的75％；确保为 *** 作系统和缓冲区留下足够的内存。根据业务特点评估需要多少内存。请注意，当内存容量超过200GB时Java 虚拟机的性能表现会不稳定。如果您购买的RAM大于200G，则可以为每个节点运行多个worker

JVM。在Spark的standalone模式下，您可以通过conf/spark-envsh中的SPARK_WORKER_INSTANCES变量设置每个节点运行的worker进程数，以及通过SPARK_WORKER_CORES变量设置每个worker可用的cpu核心数。

网络

当数据已经存储在内存中时，很多Spark应用程序的性能瓶颈在于网络的传输速率。推荐最低使用10G的网络。

CPU

Spark运行汇总计算任务比较多，推荐配置更多的cpu核数，性能提升还是比较明显，推荐：每台机器至少配置8-16个核。可以根据Spark作业的CPU负载情况，进行配置调整。一旦数据已经在内存中，大多数应用程序的性能瓶颈在于CPU和网络。

参考文档

>

以上就是关于大数据的分布式数据库技术的对比全部的内容，包括:大数据的分布式数据库技术的对比、基于spark SQL之上的检索与排序对比性能测试、Spark对硬件的要求等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！