Bucket Table

Bucket?Table是一種Spark常見的優(yōu)化查詢的建表方式。創(chuàng)建方式是使用distributed by語法進(jìn)行創(chuàng)建，會根據(jù)spark.sql.shuffle.partitions的值創(chuàng)建若干個(gè)bucket。Spark中對于兩個(gè)大表的join，采用的方式是SortMergeJoin.而如果兩個(gè)表都是bucket表，而且bucket數(shù)量相同(業(yè)界有公司針對這塊的優(yōu)化，如果兩個(gè)bucket表bucket數(shù)量是倍數(shù)關(guān)系也可以進(jìn)行bucket join)，那么可以跳過sort和shuffle，直接進(jìn)行join, 會產(chǎn)生較好的性能，通常需要業(yè)務(wù)方會約定好bucket的數(shù)量。

Spark針對bucket表讀取的時(shí)候，會對每一個(gè)bucket分配一個(gè)task來讀取，因?yàn)槿绻M(jìn)行bucket join就不能再對這個(gè)bucket的數(shù)據(jù)進(jìn)行拆分。但是問題來了，我們并不是每次讀取bucket表都是為了進(jìn)行bucket join，比如說有時(shí)候我們會對這個(gè)bucket進(jìn)行更新操作。如果只是單純的對這個(gè)bucket表進(jìn)行一些處理操作，例如就是一個(gè)單純的shuffle操作。而這個(gè)bucket表的每個(gè)bucket都特別大，例如大于1個(gè)G，而在shuffle write階段要生成3G的數(shù)據(jù)。那么這時(shí)候?qū)γ總€(gè)bucket分配一個(gè)task來處理就會非常吃力。

其實(shí)Spark?SQL中有一個(gè)參數(shù)spark.sql.sources.bucketing.enabled,默認(rèn)是true。如果我們將這個(gè)參數(shù)設(shè)置為false，那么spark就會將一個(gè)bucket table看做一個(gè)普通的table。這意味著什么呢？Spark對于普通表，如果他的單個(gè)文件大于一個(gè)hdfs ?block大小(通常是128M)，而且這個(gè)文件又是可拆分的(例如text文本，snappy 壓縮格式的parquet文件等等)，那么Spark會按照這個(gè)文件拆分，分配多個(gè)task來處理。因此，針對我們上面的場景，設(shè)置這個(gè)參數(shù)為false，可以大大的加快map階段的執(zhí)行，起到優(yōu)化的效果。

解析和更改Spark SQL語句

如果你有對一個(gè)Spark?SQL語句進(jìn)行解析和更改部分語句的需求。

例如我需求對一條SQL中的表名進(jìn)行映射修改，或者對其中的UDF(其實(shí)在Spark?SQL中function和table是很類似的東西)和location信息進(jìn)行修改。

可能首先想到的就是使用正則進(jìn)行字符串匹配，去尋找自己需要的字段，但是這種方法十分的不靠譜，因?yàn)镾QL的語法十分復(fù)雜，我們很難完全準(zhǔn)確的抓取到自己需要的信息。

所以我們能不能根據(jù)抽象語法樹去拿到我們想要的字段呢？答案當(dāng)然是OK的，一條SQL語句進(jìn)行解析器之后都成為一個(gè)抽象語法樹，每個(gè)TreeNode都有自己的類型，我們可以根據(jù)這些類型拿到自己想要的信息，比如table name，function name，location等等信息(table根據(jù)TableIdentifier類型節(jié)點(diǎn)獲得，function根據(jù)FunctionIdentifier, location信息從LoadDataCommand或者CreateTableCommand中獲取)。如下圖所以，一條SQL語句INSERT INTO TRABLE tb SELECT ta.id FROM ta JOIN tb on ta.id=tb.id會被大概轉(zhuǎn)化為下面一個(gè)AST.

但是，當(dāng)我們拿到我們想要的信息，之后如何轉(zhuǎn)換想要的SQL呢？

我第一想法是說，直接修改這個(gè)AST，然后將這個(gè)AST轉(zhuǎn)化為一條SQL語句。但是AST轉(zhuǎn)SQL很麻煩的事情，需要你自己精通SQL語法，然后寫一套 Plan轉(zhuǎn)String的規(guī)則。這聽起來就很麻煩。好在經(jīng)過一番探索:

• Spark使用antlr v4進(jìn)行sql解析

• 每個(gè)SQL最開始解析為一個(gè)原始的AST(parsedPlan，未經(jīng)過analyze/optimize)

• 這個(gè)SQL也對應(yīng)一個(gè)ParserRuleContext(package?org.antlr.v4.runtime)

ParserRuleContext其實(shí)也是一棵樹，類似于AST，但是它的每個(gè)葉子節(jié)點(diǎn)會對應(yīng)一段text,也就是說對應(yīng)一部分原始的SQL語句(table對應(yīng)TableIdentifierContext，function對應(yīng)QualifiedNameContext, location對應(yīng)LocationSpecContext)。

感興趣的話可以去看這個(gè)類的源碼:

https://github.com/antlr/antlr4/blob/master/runtime/Java/src/org/antlr/v4/runtime/ParserRuleContext.java。

前面我們提到的語句會被轉(zhuǎn)化為下面的一棵樹，我這里是將其轉(zhuǎn)為String打印出來，在每個(gè)節(jié)點(diǎn)處進(jìn)行換行。

有了這樣的兩棵樹AST和ParserRuleContext，我們就可以根據(jù)第一棵樹，拿到我們想要的信息，然后再在第二棵樹上面找到其對應(yīng)的偏移量。然后對對應(yīng)部分進(jìn)行替換，之后再把第二棵樹的碎片對應(yīng)的文本拼接起來就好了。

HBase?官方社區(qū)推薦必讀好文

HBase 原理|HBase 內(nèi)存管理之 MemStore 進(jìn)化論

HBase 抗戰(zhàn)總結(jié)|阿里巴巴 HBase 高可用8年抗戰(zhàn)回憶錄

HBase 實(shí)踐|說好不哭，但 HBase 2.0 真的好用到哭

↓掃碼關(guān)注?HBase?技術(shù)社區(qū)公眾號↓

總結(jié)

以上是生活随笔為你收集整理的sql语句换行_Spark随笔|关于Bucket Table与SQL语句转换的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。