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的模式匹配...