Ⅰ 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操作，還帶有事務功能，性能據官網介紹還是非常快的