Ⅰ sparksql 内存不释放
1.1． Spark SQL的前世今生
Shark是一个为Spark设计的大规模数据仓库系统，它与Hive兼容。Shark建立在Hive的代码基础上，并通过将Hive的部分物理执行计划交换出来。这个方法使得Shark的用户可以加速Hive的查询，但是Shark继承了Hive的大且复杂的代码使得Shark很难优化和维护，同时Shark依赖于Spark的版本。随着我们遇到了性能优化的上限，以及集成SQL的一些复杂的分析功能，我们发现Hive的MapRece设计的框架限制了Shark的发展。在2014年7月1日的Spark Summit上，Databricks宣布终止对Shark的开发，将重点放到Spark SQL上。
1.2． 什么是Spark SQL
Spark SQL是Spark用来处理结构化数据的一个模块，它提供了一个编程抽象叫做DataFrame并且作为分布式SQL查询引擎的作用。
相比于Spark RDD API，Spark SQL包含了对结构化数据和在其上运算的更多信息，Spark SQL使用这些信息进行了额外的优化，使对结构化数据的操作更加高效和方便。
有多种方式去使用Spark SQL，包括SQL、DataFrames API和Datasets API。但无论是哪种API或者是编程语言，它们都是基于同样的执行引擎，因此你可以在不同的API之间随意切换，它们各有各的特点，看你喜欢那种风格。
1.3． 为什么要学习Spark SQL
我们已经学习了Hive，它是将Hive SQL转换成MapRece然后提交到集群中去执行，大大简化了编写MapRece程序的复杂性，由于MapRece这种计算模型执行效率比较慢，所以Spark SQL应运而生，它是将Spark SQL转换成RDD，然后提交到集群中去运行，执行效率非常快！
1.易整合
Ⅱ Kylin 与 Spark SQL相比，有哪些差异和优势
SparkSQL本质上是基于DAG模型的MPP。而Kylin核心是Cube(多维立方体)。关于MPP和Cube预处理的差异，重复如下：
>
MPP [1]
的基本思路是增加机器来并行计算，从而提高查询速度。比如扫描8亿记录一台机器要处理1小时，但如果用100台机器来并行处理，就只要一分钟不到。再配合
列式存储和一些索引，查询可以更快返回。要注意这里在线运算量并没有减小，8亿条记录还是要扫描一次，只是参与的机器多了，所以快了。
>
MOLAP Cube [2][3]
是一种预计算技术，基本思路是预先对数据作多维索引，查询时只扫描索引而不访问原始数据从而提速。8亿记录的一个3维索引可能只有几万条记录，规模大大缩
小，所以在线计算量大大减小，查询可以很快。索引表也可以采用列存储，并行扫描等MPP常用的技术。但多维索引要对多维度的各种组合作预计算，离线建索引
需要较大计算量和时间，最终索引也会占用较多磁盘空间。
除
了有无预处理的差异外，SparkSQL与Kylin对数据集大小的偏好也不一样。如果数据可以基本放入内存，Spark的内存缓存会让SparkSQL
有好的表现。但对于超大规模的数据集，Spark也不能避免频繁的磁盘读写，性能会大幅下降。反过来Kylin的Cube预处理会大幅减小在线数据规模，
对于超大规模数据更有优势。
Ⅲ Spark SQL 和 Shark 在架构上有哪些区别将来会合并吗
Shark为了实现Hive兼容，在HQL方面重用了Hive中HQL的解析、逻辑执行计划翻译、执行计划优化等逻辑，可以近似认为仅将物理执行计划从MR作业替换成了Spark作业（辅以内存列式存储等各种和Hive关系不大的优化）；同时还依赖Hive Metastore和Hive SerDe（用于兼容现有的各种Hive存储格式）。这一策略导致了两个问题，第一是执行计划优化完全依赖于Hive，不方便添加新的优化策略；二是因为MR是进程级并行，写代码的时候不是很注意线程安全问题，导致Shark不得不使用另外一套独立维护的打了补丁的Hive源码分支。
Spark SQL解决了这两个问题。第一，Spark SQL在Hive兼容层面仅依赖HQL parser、Hive Metastore和Hive SerDe。也就是说，从HQL被解析成抽象语法树（AST）起，就全部由Spark SQL接管了。执行计划生成和优化都由Catalyst负责。借助Scala的模式匹配等函数式语言特性，利用Catalyst开发执行计划优化策略比Hive要简洁得多。去年Spark summit上Catalyst的作者Michael Armbrust对Catalyst做了一个简要介绍：2013 | Spark Summit（知乎竟然不能自定义链接的文字？）。第二，相对于Shark，由于进一步削减了对Hive的依赖，Spark SQL不再需要自行维护打了patch的Hive分支。Shark后续将全面采用Spark SQL作为引擎，不仅仅是查询优化方面。
此外，除了兼容HQL、加速现有Hive数据的查询分析以外，Spark SQL还支持直接对原生RDD对象进行关系查询。同时，除了HQL以外，Spark SQL还内建了一个精简的SQL parser，以及一套Scala DSL。也就是说，如果只是使用Spark SQL内建的SQL方言或Scala DSL对原生RDD对象进行关系查询，用户在开发Spark应用时完全不需要依赖Hive的任何东西。
能够对原生RDD对象进行关系查询，个人认为大大降低了用户门槛。一方面当然是因为熟悉SQL的人比熟悉Spark API的人多，另一方面是因为Spark SQL之下有Catalyst驱动的查询计划优化引擎。虽然在很多方面Spark的性能完爆Hadoop MapRece好几条街，但Spark的运行时模型也比MapRece复杂不少，使得Spark应用的性能调优比较tricky。虽然从代码量上来看，Spark应用往往是对等的MR应用的好几分之一，但裸用Spark API开发高效Spark应用还是需要花些心思的。这就体现出Spark SQL的优势了：即便用户写出的查询不那么高效，Catalyst也可以自动应用一系列常见优化策略。
。。
Ⅳ 为什么说Spark SQL远远超越了MPP SQL
这里说的并不是性能，因为我没尝试对比过（下文会有简单的说明），而是尝试从某种更高一层次的的角度去看，为什么Spark SQL 是远远超越MPP SQL的。
Spark SQL 和 MPP SQL 其实不在一个维度上。简而言之，
MPP SQL 是 Spark SQL 的一个子集
Spark SQL 成为了一种跨越领域的交互形态
MPP SQL 是 Spark SQL 的一个子集
MPP SQL 要解决的技术问题是海量数据的查询问题。这里根据实际场景，你还可以加上一些修饰词汇，譬如秒级，Ad-hoc 之类。
在实际业务中
探索类业务，比如KPI多维分析，用户画像查询，数据科学家摸底数据等
运营类业务，比如报表（现在很多BI系统基本上完全基于SQL来构建），各种运营临时统计需求
分析类业务，不过这个会比较浅显。显然，真实的的分析应该主要依托一些统计类，机器学习等技术的支持
运维类业务，比如实时查询查看海量的系统日志等
MPP SQL 是有一定的性能优势的，从HAWQ,Impala 等都是基于MPP架构的。然而仅限于此。这些功能Spark SQL 目前都已经涵盖了，MPP SQL能做的事情，Spark SQL都完成的很漂亮。
依托于Spark 自身的全平台性(漂亮的DataSource API以及各个厂商的努力适配),Spark SQL 基本上可以对接任意多个异构数据源进行分析和查询。大家可参考我的一个简略实现 利用StreamingPro实现SQL-交互式查询。
关于性能可以再多说两句：
得益于一些具有复杂存储格式的文件的诞生，譬如CarbonData, Spark SQL 已经实现海量数据的秒级查询
Spark 自身通过Tungsten等项目的优化(尤其是代码自动生成)，速度越来越生猛，而JVM譬如GC带来的问题则可以进一步通过off-heap的方式减少。
所以 Spark SQL 和 MPP SQL在性能上的差距也会越来越小。
Spark SQL 成为了一种跨越领域的交互形态
Spark 通过使用DS（2.0统一了DF 和 DS，使用一套SQL引擎）极大的增强了交互语意，意味着你可以用SQL（DS）作为统一的交互语言完成流式，批处理，交互式查询，机器学习等大数据领域常见场景。这在任何一个系统都是不多见的，也可见Spark团队的抽象能力。
引言中的那篇文章其实是作者吐槽Spark 团队对Spark core（RDD）那层关注太少了，所以开始发牢骚。
现在我们再回过头来看我们常见的一些业务：
实时分析类业务
探索类业务
分析预测类业务
运营报表类业务
首先这些业务都可以使用Spark 来实现。其次统一的交互接口都是DS(DF/SQL),并且DS/SQL 是一套极度易用并且广泛普及和接受的。
当然Spark 也不是一步就做到这点的，原来流式计算和批量计算就是两套API, DF 和 DS 也是两套API,后面经过发展，Databricks 团队也在积极思考和慢慢成长，经过先前已经有的积累，才做到现在的这一步。
所以本质上DS/SQL 已经成为除了RDD API 以外，另外一套通用的，统一的交互式API，涵盖了流式，批处理，交互式查询，机器学习等大数据领域。这也是我们第一次达成这样的统一，目前来看也仅在Spark平台上得以实现，它是的大数据的使用和学习门槛进一步降低，功在千秋。
RDD VS DS/SQL
DS/SQL 是一套数据类型首先，操作种类受限的表达语言，意味着Spark 团队可以做更好的性能优化，也意味着门槛更低，在易用性和性能上都能取得良好的平衡
Ⅳ 如何使用 Spark SQL
一、启动方法
/data/spark-1.4.0-bin-cdh4/bin/spark-sql --master spark://master:7077 --total-executor-cores 10 --executor-memory 1g --executor-cores 2
注：/data/spark-1.4.0-bin-cdh4/为spark的安装路径
/data/spark-1.4.0-bin-cdh4/bin/spark-sql –help 查看启动选项
--master MASTER_URL 指定master url
--executor-memory MEM 每个executor的内存，默认为1G
--total-executor-cores NUM 所有executor的总核数
-e <quoted-query-string> 直接执行查询SQL
-f <filename> 以文件方式批量执行SQL
二、Spark sql对hive支持的功能
1、查询语句：SELECT GROUP BY ORDER BY CLUSTER BY SORT BY
2、hive操作运算：
1) 关系运算：= ==, <>, <, >, >=, <=
2) 算术运算：+, -, *, /, %
3) 逻辑运算：AND, &&, OR, ||
4) 复杂的数据结构
5) 数学函数：(sign, ln, cos, etc)
6) 字符串函数：
3、 UDF
4、 UDAF
5、 用户定义的序列化格式
6、join操作：JOIN {LEFT|RIGHT|FULL} OUTER JOIN LEFT SEMI JOIN CROSS JOIN
7、 unions操作：
8、 子查询： SELECT col FROM ( SELECT a + b AS col from t1) t2
9、Sampling
10、 Explain
11、 分区表
12、 视图
13、 hive ddl功能：CREATE TABLE、CREATE TABLE AS SELECT、ALTER TABLE
14、 支持的数据类型：TINYINT SMALLINT INT BIGINT BOOLEAN FLOAT DOUBLE STRING BINARY TIMESTAMPDATE ARRAY MAP STRUCT
三、Spark sql 在客户端编程方式进行查询数据
1、启动spark-shell
./spark-shell --master spark://master:7077 --total-executor-cores 10 --executor-memory 1g --executor-cores 2
2、编写程序
val sqlContext = new org.apache.spark.sql.SQLContext(sc)
val df = sqlContext.read.json("../examples/src/main/resources/people.json")
查看所有数据：df.show()
查看表结构：df.printSchema()
只看name列：df.select("name").show()
对数据运算：df.select(df("name"), df("age") + 1).show()
过滤数据：df.filter(df("age") > 21).show()
分组统计：df.groupBy("age").count().show()
1、查询txt数据
import sqlContext.implicits._
case class Person(name: String, age: Int)
val people = sc.textFile("../examples/src/main/resources/people.txt").map(_.split(",")).map(p => Person(p(0), p(1).trim.toInt)).toDF()
people.registerTempTable("people")
val teenagers = sqlContext.sql("SELECT name, age FROM people WHERE age >= 13 AND age <= 19")
2、parquet文件
val df = sqlContext.read.load("../examples/src/main/resources/users.parquet")
3、hdfs文件
val df = sqlContext.read.load("hdfs://namenode.Hadoop:9000/user/hive/warehouse/spark_test.db/test_parquet/part-r-00001.gz.parquet")
4、保存查询结果数据
val df = sqlContext.read.load("../examples/src/main/resources/users.parquet")
df.select("name", "favorite_color").write.save("namesAndFavColors.parquet“)
四、Spark sql性能调优
缓存数据表：sqlContext.cacheTable("tableName")
取消缓存表：sqlContext.uncacheTable("tableName")
spark.sql.inMemoryColumnarStorage.compressedtrue当设置为true时，Spark SQL将为基于数据统计信息的每列自动选择一个压缩算法。
spark.sql.inMemoryColumnarStorage.batchSize10000柱状缓存的批数据大小。更大的批数据可以提高内存的利用率以及压缩效率，但有OOMs的风险
Ⅵ sparksql的 怎么增加 cpu的使用率，提高查询速度
Spark是一个快速的内存计算框架，同时是一个并行运算的框架，在计算性能调优的时候，除了要考虑广为人知的木桶原理外，还要考虑平行运算的Amdahl定理。
Ⅶ spark 跑spark sql时cpu利用率特别高怎么办
优化过程中常用到方法
查看查询的整个运行计划
scala>query.queryExecution
查看查询的Unresolved LogicalPlan
scala>query.queryExecution.logical
查看查询的Analyzed LogicalPlan
scala>query.queryExecution.analyzed
查看优化后的LogicalPlan
scala>query.queryExecution.optimizedPlan
查看物理计划
scala>query.queryExecution.sparkPlan
查看RDD的转换过程
scala>query.toDebugString
SparkSQL调优
Spark是一个快速的内存计算框架，同时是一个并行运算的框架，在计算性能调优的时候，除了要考虑广为人知的木桶原理外，还要考虑平行运算的Amdahl定理。
木桶原理又称短板理论，其核心思想是：一只木桶盛水的多少，并不取决于桶壁上最高的那块木块，而是取决于桶壁上最短的那块。将这个理论应用到系统性能优化上，系统的最终性能取决于系统中性能表现最差的组件。例如，即使系统拥有充足的内存资源和CPU资源，但是如果磁盘I/O性能低下，那么系统的总体性能是取决于当前最慢的磁盘I/O速度，而不是当前最优越的CPU或者内存。在这种情况下，如果需要进一步提升系统性能，优化内存或者CPU资源是毫无用处的。只有提高磁盘I/O性能才能对系统的整体性能进行优化。
SparkSQL作为Spark的一个组件，在调优的时候，也要充分考虑到上面的两个原理，既要考虑如何充分的利用硬件资源，又要考虑如何利用好分布式系统的并行计算。由于测试环境条件有限，本篇不能做出更详尽的实验数据来说明，只能在理论上加以说明。
2.1 并行性
SparkSQL在集群中运行，将一个查询任务分解成大量的Task分配给集群中的各个节点来运行。通常情况下，Task的数量是大于集群的并行度,shuffle的时候缺省的spark.sql.shuffle.partitionsw为200个partition，也就是200个Task：
而实验的集群环境却只能并行3个Task，也就是说同时只能有3个Task保持Running：
这时大家就应该明白了，要跑完这200个Task就要跑200/3=67批次。如何减少运行的批次呢？那就要尽量提高查询任务的并行度。查询任务的并行度由两方面决定：集群的处理能力和集群的有效处理能力。
l对于Spark Standalone集群来说，集群的处理能力是由conf/spark-env中的SPARK_WORKER_INSTANCES参数、SPARK_WORKER_CORES参数决定的；而SPARK_WORKER_INSTANCES*SPARK_WORKER_CORES不能超过物理机器的实际CPU core；
l集群的有效处理能力是指集群中空闲的集群资源，一般是指使用spark-submit或spark-shell时指定的--total-executor-cores，一般情况下，我们不需要指定，这时候，Spark Standalone集群会将所有空闲的core分配给查询，并且在Task轮询运行过程中，Standalone集群会将其他spark应用程序运行完后空闲出来的core也分配给正在运行中的查询。
综上所述，SparkSQL的查询并行度主要和集群的core数量相关，合理配置每个节点的core可以提高集群的并行度，提高查询的效率。
2.2 高效的数据格式
高效的数据格式，一方面是加快了数据的读入速度，另一方面可以减少内存的消耗。高效的数据格式包括多个方面：
2.2.1 数据本地性
分布式计算系统的精粹在于移动计算而非移动数据，但是在实际的计算过程中，总存在着移动数据的情况，除非是在集群的所有节点上都保存数据的副本。移动数据，将数据从一个节点移动到另一个节点进行计算，不但消耗了网络IO，也消耗了磁盘IO，降低了整个计算的效率。为了提高数据的本地性，除了优化算法（也就是修改spark内存，难度有点高），就是合理设置数据的副本。设置数据的副本，这需要通过配置参数并长期观察运行状态才能获取的一个经验值。
下面是Spark webUI监控Stage的一个图：
lPROCESS_LOCAL是指读取缓存在本地节点的数据
lNODE_LOCAL是指读取本地节点硬盘数据
lANY是指读取非本地节点数据
l通常读取数据PROCESS_LOCAL>NODE_LOCAL>ANY，尽量使数据以PROCESS_LOCAL或NODE_LOCAL方式读取。其中PROCESS_LOCAL还和cache有关。
2.2.2 合适的数据类型
对于要查询的数据，定义合适的数据类型也是非常有必要。对于一个tinyint可以使用的数据列，不需要为了方便定义成int类型，一个tinyint的数据占用了1个byte，而int占用了4个byte。也就是说，一旦将这数据进行缓存的话，内存的消耗将增加数倍。在SparkSQL里，定义合适的数据类型可以节省有限的内存资源。
2.2.3 合适的数据列
对于要查询的数据，在写SQL语句的时候，尽量写出要查询的列名，如Select a,b from tbl，而不是使用Select * from tbl；这样不但可以减少磁盘IO，也减少缓存时消耗的内存。
2.2.4 优的数据存储格式
在查询的时候，最终还是要读取存储在文件系统中的文件。采用更优的数据存储格式，将有利于数据的读取速度。查看SparkSQL的Stage，可以发现，很多时候，数据读取消耗占有很大的比重。对于sqlContext来说，支持 textFiile、SequenceFile、ParquetFile、jsonFile；对于hiveContext来说，支持AvroFile、ORCFile、Parquet File，以及各种压缩。根据自己的业务需求，测试并选择合适的数据存储格式将有利于提高SparkSQL的查询效率。
2.3 内存的使用
spark应用程序最纠结的地方就是内存的使用了，也是最能体现“细节是魔鬼”的地方。Spark的内存配置项有不少，其中比较重要的几个是：
lSPARK_WORKER_MEMORY，在conf/spark-env.sh中配置SPARK_WORKER_MEMORY 和SPARK_WORKER_INSTANCES，可以充分的利用节点的内存资源，SPARK_WORKER_INSTANCES*SPARK_WORKER_MEMORY不要超过节点本身具备的内存容量；
lexecutor-memory，在spark-shell或spark-submit提交spark应用程序时申请使用的内存数量；不要超过节点的SPARK_WORKER_MEMORY；
lspark.storage.memoryFraction spark应用程序在所申请的内存资源中可用于cache的比例
lspark.shuffle.memoryFraction spark应用程序在所申请的内存资源中可用于shuffle的比例
在实际使用上，对于后两个参数，可以根据常用查询的内存消耗情况做适当的变更。另外，在SparkSQL使用上，有几点建议：
l对于频繁使用的表或查询才进行缓存，对于只使用一次的表不需要缓存；
l对于join操作，优先缓存较小的表；
l要多注意Stage的监控，多思考如何才能更多的Task使用PROCESS_LOCAL；
l要多注意Storage的监控，多思考如何才能Fraction cached的比例更多
2.4 合适的Task
对于SparkSQL，还有一个比较重要的参数，就是shuffle时候的Task数量，通过spark.sql.shuffle.partitions来调节。调节的基础是spark集群的处理能力和要处理的数据量，spark的默认值是200。Task过多，会产生很多的任务启动开销，Task多少，每个Task的处理时间过长，容易straggle。
2.5 其他的一些建议
优化的方面的内容很多，但大部分都是细节性的内容，下面就简单地提提：
l 想要获取更好的表达式查询速度，可以将spark.sql.codegen设置为Ture；
l 对于大数据集的计算结果，不要使用collect() ,collect()就结果返回给driver，很容易撑爆driver的内存；一般直接输出到分布式文件系统中；
l 对于Worker倾斜，设置spark.speculation=true 将持续不给力的节点去掉；
l 对于数据倾斜，采用加入部分中间步骤，如聚合后cache，具体情况具体分析；
l 适当的使用序化方案以及压缩方案；
l 善于利用集群监控系统，将集群的运行状况维持在一个合理的、平稳的状态；
l 善于解决重点矛盾，多观察Stage中的Task，查看最耗时的Task，查找原因并改善；
Ⅷ sparksql 多字段join与单字段join的性能问题
1 概念：流式遍历表(streamIter)和查找表(buildIter)
流式遍历表(streamIter)和查找表(buildIter)的概念见Spark SQL 之 Join 实现 - 云+社区 - 腾讯云 (tencent.com)
一般streamlter是大表，bulidler是小表
2 概念：sparksql种3种join的实现方式
sort merge join：有shuffle操作，适用于两张大表
broadcast join：把bulidler表广播到每个executor里，所以builder表应该小一点，sparks中默认builder表小于10M时使用broadcast join方法，适用于大表+小表
hash join：默认不开启，开启了sort merge join也比它差不了太多，适用于大表+小表（比broadcast的小表略大）
3 4种join方式
inner join：我们在写sql语句或者使用DataFrmae时，可以不用关心哪个是左表，哪个是右表，在spark sql查询优化阶段，spark会自动将大表设为左表，即streamIter，将小表设为右表，即buildIter。
left outer join是以左表为准，在右表中查找匹配的记录，如果查找失败，则返回一个所有字段都为null的记录。我们在写sql语句或者使用DataFrmae时，一般让大表在左边，小表在右边。
right outer join是以右表为准，在左表中查找匹配的记录，如果查找失败，则返回一个所有字段都为null的记录。所以说，右表是streamIter，左表是buildIter，我们在写sql语句或者使用DataFrmae时，一般让大表在右边，小表在左边。
full outer join 不用关心左表右表
Ⅸ 基于spark 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: 说了一大堆，说白了最适合的还是踪迹分析因为数据量大，数据还要求实时，查询还要求快。这才是关键。
Ⅹ phoenix，impala，spark sql访问hbase数据库哪种工具性能最优
phoenix、impala、hive、shark、spark SQL等，本人目前在项目中使用的是phoenix工具，是一个访问hbase的JDBC驱动jar包，基本像访问JDBC一样，可以进行各种CRUD操作，还带有事务功能，性能据官网介绍还是非常快的