我們知道，大部分Spark計(jì)算都是在內(nèi)存中完成的，所以Spark的瓶頸一般來(lái)自于集群(standalone, yarn, mesos, k8s)的資源緊張，CPU，網(wǎng)絡(luò)帶寬，內(nèi)存。Spark的性能，想要它快，就得充分利用好系統(tǒng)資源，尤其是內(nèi)存和CPU。有時(shí)候我們也需要做一些優(yōu)化調(diào)整來(lái)減少內(nèi)存占用，例如將小文件進(jìn)行合并的操作。

彭陽(yáng)網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、APP開(kāi)發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)等網(wǎng)站項(xiàng)目制作，到程序開(kāi)發(fā)，運(yùn)營(yíng)維護(hù)。創(chuàng)新互聯(lián)成立與2013年到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來(lái)保證我們的工作的順利進(jìn)行。專(zhuān)注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

一、問(wèn)題現(xiàn)象

我們有一個(gè)15萬(wàn)條總數(shù)據(jù)量133MB的表，使用SELECT * FROM bi.dwd_tbl_conf_info全表查詢(xún)耗時(shí)3min，另外一個(gè)500萬(wàn)條總數(shù)據(jù)量6.3G的表ods_tbl_conf_detail，查詢(xún)耗時(shí)23秒。兩張表均為列式存儲(chǔ)的表。

大表查詢(xún)快，而小表反而查詢(xún)慢了，為什么會(huì)產(chǎn)生如此奇怪的現(xiàn)象呢?

二、問(wèn)題探詢(xún)

數(shù)據(jù)量6.3G的表查詢(xún)耗時(shí)23秒，反而數(shù)據(jù)量133MB的小表查詢(xún)耗時(shí)3min，這非常奇怪。我們收集了對(duì)應(yīng)的建表語(yǔ)句，發(fā)現(xiàn)兩者沒(méi)有太大的差異，大部分為String，兩表的列數(shù)也相差不大。

CREATETABLEIFNOTEXISTS`bi`.`dwd_tbl_conf_info`(`corp_id`STRINGCOMMENT\'\',`dept_uuid`STRINGCOMMENT\'\',`user_id`STRINGCOMMENT\'\',`user_name`STRINGCOMMENT\'\',`uuid`STRINGCOMMENT\'\',`dtime`DATECOMMENT\'\',`slice_number`INTCOMMENT\'\',`attendee_count`INTCOMMENT\'\',`mr_id`STRINGCOMMENT\'\',`mr_pkg_id`STRINGCOMMENT\'\',`mr_parties`INTCOMMENT\'\',`is_mr`TINYINTCOMMENT\'R\',`is_live_conf`TINYINTCOMMENT\'\') CREATETABLEIFNOTEXISTS`bi`.`ods_tbl_conf_detail`(`id`string,`conf_uuid`string,`conf_id`string,`name`string,`number`string,`device_type`string,`j_time`bigint,`l_time`bigint,`media_type`string,`dept_name`string,`UPDATETIME`bigint,`CREATETIME`bigint,`user_id`string,`USERAGENT`string,`corp_id`string,`account`string)

因?yàn)閮蓮埍砭鶠楹芎?jiǎn)單的SELECT查詢(xún)操作，無(wú)任何復(fù)雜的聚合join操作，也無(wú)UDF相關(guān)的操作，所以基本確認(rèn)查詢(xún)慢的應(yīng)該發(fā)生的讀表的時(shí)候，我們將懷疑的點(diǎn)放到了讀表操作上。通過(guò)查詢(xún)兩個(gè)查詢(xún)語(yǔ)句的DAG和任務(wù)分布，我們發(fā)現(xiàn)了不一樣的地方。

查詢(xún)快的表，查詢(xún)時(shí)總共有68個(gè)任務(wù)，任務(wù)分配比如均勻，平均7~9s左右，而查詢(xún)慢的表，查詢(xún)時(shí)總共1160個(gè)任務(wù)，平均也是9s左右。如下圖所示：

至此，我們基本發(fā)現(xiàn)了貓膩所在。大表6.3G但文件個(gè)數(shù)小，只有68個(gè)，所以很快跑完了。而小表雖然只有133MB，但文件個(gè)數(shù)特別多，導(dǎo)致產(chǎn)生的任務(wù)特別多，而由于單個(gè)任務(wù)本身比較快，大部分時(shí)間花費(fèi)在任務(wù)調(diào)度上，導(dǎo)致任務(wù)耗時(shí)較長(zhǎng)。

那如何才能解決小表查詢(xún)慢的問(wèn)題呢?

三、業(yè)務(wù)調(diào)優(yōu)

那現(xiàn)在擺在我們面前就存在現(xiàn)在問(wèn)題：

為什么小表會(huì)產(chǎn)生這么小文件 已經(jīng)產(chǎn)生的這么小文件如何合并

帶著這兩個(gè)問(wèn)題，我們和業(yè)務(wù)的開(kāi)發(fā)人員聊了一個(gè)發(fā)現(xiàn)小表是業(yè)務(wù)開(kāi)發(fā)人員從原始數(shù)據(jù)表中，按照不同的時(shí)間切片查詢(xún)并做數(shù)據(jù)清洗后插入到小表中的，而由于時(shí)間切片切的比較小，導(dǎo)致這樣的插入次數(shù)特別多，從而產(chǎn)生了大量的小文件。

那么我們需要解決的問(wèn)題就是2個(gè)，如何才能把這些歷史的小文件進(jìn)行合并以及如何才能保證后續(xù)的業(yè)務(wù)流程中不再產(chǎn)生小文件，我們指導(dǎo)業(yè)務(wù)開(kāi)發(fā)人員做了以下優(yōu)化：

使用INSERT OVERWRITE bi.dwd_tbl_conf_info SELECT * FROM bi.dwd_tbl_conf_info合并下歷史的數(shù)據(jù)。由于DLI做了數(shù)據(jù)一致性保護(hù)，OVERWRITE期間不影響原有數(shù)據(jù)的讀取和查詢(xún)，OVERWRITE之后就會(huì)使用新的合并后的數(shù)據(jù)。合并后全表查詢(xún)由原來(lái)的3min縮短到9s內(nèi)完成。 原有表修改為分區(qū)表，插入時(shí)不同時(shí)間放入到不同分區(qū)，查詢(xún)時(shí)只查詢(xún)需要的時(shí)間段內(nèi)的分區(qū)數(shù)據(jù)，進(jìn)一步減小讀取數(shù)據(jù)量。

分享文章：Spark優(yōu)化之小文件是否需要合并?
路徑分享：http://vcdvsql.cn/article44/choiee.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、Google、搜索引擎優(yōu)化、網(wǎng)頁(yè)設(shè)計(jì)公司、App開(kāi)發(fā)、用戶(hù)體驗(yàn)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)