1. Sparksql和Hive在做cast boolean存在的不同
今天在看一些数据的时候发现,一些SparkSQL与Hive之间在进行cast转化时候存在一些差异。
HiveVersion 1.2.1
SparkSQL 1.6.0
总结:
在Hive中, boolean类型的隐式转化,Hive中非boolean非null转化默认为True,
而在SparkSQL中，则根据传入的不同数据类型判断值后返回结果.
Hive
Converts the results of the expression expr to . For example,
cast(‘1’ as BIGINT) will convert the string ‘1’ to its integral representation.
A null is returned if the conversion does not succeed.
If cast(expr as boolean) Hive returns true for a non-empty string.
hive> select cast('false' as boolean) from default.le;
OK
true123
SparkSQL
在SparkSQL中如果是string的话，会检查StringUtils中枚举的；其他原子类型数据进行是否不等于0,不等于0返回true，否则为false
具体代码逻辑如下
classname: org.apache.spark.sql.catalyst.expressions.Cast
// UDFToBoolean
private[this] def castToBoolean(from: DataType): Any => Any = from match {
case StringType =>
buildCast[UTF8String](_, s => {
if (StringUtils.isTrueString(s)) {
true
} else if (StringUtils.isFalseString(s)) {
false
} else {
null
}
})
case TimestampType =>
buildCast[Long](_, t => t != 0)
case DateType =>
// Hive would return null when cast from date to boolean
buildCast[Int](_, d => null)
case LongType =>
buildCast[Long](_, _ != 0)
case IntegerType =>
buildCast[Int](_, _ != 0)
case ShortType =>
buildCast[Short](_, _ != 0)
case ByteType =>
buildCast[Byte](_, _ != 0)
case DecimalType() =>
buildCast[Decimal](_, !_.isZero)
case DoubleType =>
buildCast[Double](_, _ != 0)
case FloatType =>
buildCast[Float](_, _ != 0)
}
classname: org.apache.spark.sql.catalyst.util.StringUtils
//
private[this] val trueStrings = Set("t", "true", "y", "yes", "1").map(UTF8String.fromString)
private[this] val falseStrings = Set("f", "false", "n", "no", "0").map(UTF8String.fromString)
def isTrueString(s: UTF8String): Boolean = trueStrings.contains(s.toLowerCase)
def isFalseString(s: UTF8String): Boolean = falseStrings.contains(s.toLowerCase)
2. hive和sparksql的区别
历史上存在的原理，以前都是使用hive来构建数据仓库，所以存在大量对hive所管理的数据查询的需求。而hive、shark、sparlSQL都可以进行hive的数据查询。shark是使用了hive的sql语法解析器和优化器，修改了执行器，使之物理执行过程是跑在spark上；而sparkSQL是使用了自身的语法解析器、优化器和执行器，同时sparkSQL还扩展了接口，不单单支持hive数据的查询，可以进行多种数据源的数据查询。
3. spark sql和sql的区别
Shark和sparkSQL 但是，随着Spark的发展，其中sparkSQL作为Spark生态的一员继续发展，而不再受限于hive，只是兼容hive；而hive on spark是一个hive的发展计划，该计划将spark作为hive的底层引擎之一，也就是说，hive将不再受限于一个引擎，可以采用map-rece、Tez、spark等引擎。
4. sparkSQL用jdbc连接hive和用元数据连接hive的区别，各自优缺点
spark on hive : 是spark 通过spark-sql 使用hive 语句操作hive ,底层运行的还是 spark rdd.
*（1）就是通过sparksql，加载hive的配置文件，获取到hive的元数据信息
* （2）spark sql获取到hive的元数据信息之后就可以拿到hive的所有表的数据
* （3）接下来就可以通过spark sql来操作hive表中的数据
hive on spark: 是hive 等的执行引擎变成spark , 不再是maprece. 相对于上一项,这个要实现责麻烦很多, 必须重新编译你的spark. 和导入jar包,
5. 基于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: 说了一大堆，说白了最适合的还是踪迹分析因为数据量大，数据还要求实时，查询还要求快。这才是关键。
6. spark on hive和hive on spark的区别
spark on hive : 是spark 通过spark-sql 使用hive 语句操作hive ,底层运行的还是 spark rdd.
*（1）就是通过sparksql，加载hive的配置文件，获取到hive的元数据信息
* （2）spark sql获取到hive的元数据信息之后就可以拿到hive的所有表的数据
* （3）接下来就可以通过spark sql来操作hive表中的数据
hive on spark: 是hive 等的执行引擎变成spark , 不再是maprece. 相对于上一项,这个要实现责麻烦很多, 必须重新编译你的spark. 和导入jar包,
======================下面是送的=============
而 hive on spark 是把hive查询从maprece 的mr (hadoop 计算引擎)操作替换为spark rdd 操作. 不过目前大部分使用的是spark on hive
======================================
后面补充的:: 我去了某通之后, 知道了 把 hive的执行引擎换成spark 的也挺多的. 主要是为了使用类 sql 和相关脚本来完成任务.
为了真理,我要把那个垃圾的回答给顶下去...
7. spark sql能替代hive吗
Spark SQL解决了这两个问题。 第一，Spark SQL在Hive兼容层面仅依赖HQL parser、Hive Metastore和Hive SerDe。也就是说，从HQL被解析成抽象语法树（AST）起，就全部由Spark SQL接管了。执行计划生成和优化都由Catalyst负责。借助Scala的模式匹配...