建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
關(guān)于現(xiàn)代數(shù)據(jù)分析員在分布式計(jì)算環(huán)境中的有效性，引起了人們很久的爭(zhēng)論。分析師習(xí)慣 SQL 在短時(shí)間內(nèi)可以查詢(xún)到問(wèn)題的答案。當(dāng)查詢(xún)?cè)趲讉€(gè)小時(shí)內(nèi)沒(méi)有返回結(jié)果時(shí)，RDBMS 用戶(hù)通常會(huì)無(wú)法理解根本原因。
創(chuàng)新互聯(lián)建站不只是一家網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司；我們對(duì)營(yíng)銷(xiāo)、技術(shù)、服務(wù)都有自己獨(dú)特見(jiàn)解，公司采取“創(chuàng)意+綜合+營(yíng)銷(xiāo)”一體化的方式為您提供更專(zhuān)業(yè)的服務(wù)！我們經(jīng)歷的每一步也許不一定是最完美的，但每一步都有值得深思的意義。我們珍視每一份信任，關(guān)注我們的成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)質(zhì)量和服務(wù)品質(zhì)，在得到用戶(hù)滿(mǎn)意的同時(shí)，也能得到同行業(yè)的專(zhuān)業(yè)認(rèn)可，能夠?yàn)樾袠I(yè)創(chuàng)新發(fā)展助力。未來(lái)將繼續(xù)專(zhuān)注于技術(shù)創(chuàng)新，服務(wù)升級(jí)，滿(mǎn)足企業(yè)一站式全網(wǎng)營(yíng)銷(xiāo)推廣需求，讓再小的品牌網(wǎng)站制作也能產(chǎn)生價(jià)值！
Hive 和 Spark 等查詢(xún)引擎對(duì)于高級(jí)工程師來(lái)說(shuō)是很復(fù)雜的，但是有的并不這樣認(rèn)為。在 Acceldata上，我們可以看到完整的表掃描在多 Tera Byte 表上運(yùn)行從而獲取行數(shù)，這在 Hadoop中至少是不允許操作的。實(shí)際上，數(shù)據(jù)需要轉(zhuǎn)化為洞察力才能做出業(yè)務(wù)決策。值得一提的是，大數(shù)據(jù)的價(jià)值需要實(shí)時(shí)獲取。
Hadoop 管理員/工程師準(zhǔn)備闡釋大量的度量指標(biāo)，并分析性能不佳和從集群中拿走資源的原因，從而導(dǎo)致：
? 失控的資源問(wèn)題
? 失控的時(shí)間問(wèn)題
? 導(dǎo)致停機(jī)的泄漏
在開(kāi)始糾正步驟之前必須提供以下詳細(xì)信息：
? 歷史查詢(xún)性能（查詢(xún)是重復(fù)的前提下）
? 執(zhí)行視圖——Mappers（映射器）、Reducer（減速器）、連接效率
? 數(shù)據(jù)視圖 - 哪些表（事實(shí)維度）
? 紗線(xiàn)容器的效率
? 執(zhí)行計(jì)劃——（邏輯和物理計(jì)劃）
歷史查詢(xún)性能： Acceldata APM 對(duì)在交互式 BI 隊(duì)列上運(yùn)行的每個(gè) SQL 進(jìn)行指紋識(shí)別。這是通過(guò)解析 AST 來(lái)完成的，并記住經(jīng)常使用的查詢(xún)的參數(shù)進(jìn)行不斷變化，例如，在每日?qǐng)?bào)告的情況下。在下一次運(yùn)行 SQL 時(shí)，Acceldata 能夠?qū)⒃摬樵?xún)的過(guò)去性能與最近的運(yùn)行相關(guān)聯(lián)。查詢(xún)執(zhí)行參數(shù)中的異常（如下所示）在視覺(jué)上表示異常：
? 經(jīng)過(guò)的持續(xù)時(shí)間
? 從 HDFS 讀取數(shù)據(jù)
? 數(shù)據(jù)寫(xiě)入 HDFS
? VCore的使用
? 內(nèi)存利用率
執(zhí)行視圖： 在某些情況下，當(dāng)一個(gè)Reducers需要花費(fèi)很長(zhǎng)時(shí)間時(shí)，查詢(xún)則需要很長(zhǎng)的持續(xù)時(shí)間，就好像一個(gè)“掉隊(duì)者”，消耗超過(guò) 90% 的持續(xù)時(shí)間。這種識(shí)別有助于整改；然而，如果要實(shí)現(xiàn)這一點(diǎn)，不登錄多個(gè)服務(wù)器，并且沒(méi)跨層的橫截面視圖的幫助，是非常具有挑戰(zhàn)性的。Acceldata 結(jié)合紗線(xiàn)診斷日志，將Mappers和Reducers的持續(xù)時(shí)間、順序可視化。
以下是紗線(xiàn)診斷數(shù)據(jù)，顯示紗線(xiàn)應(yīng)用程序從開(kāi)始到結(jié)束的執(zhí)行階段。這提供了一個(gè)清晰的概念，假如 Yarn 應(yīng)用程序被搶占，那么內(nèi)存和 VCore 的分配是什么，在這些應(yīng)用程序中可以處理作業(yè)的容器的數(shù)量是多少。同時(shí)還提供了診斷消息，允許用戶(hù)在作業(yè)失敗的情況下識(shí)別異常，而無(wú)需離開(kāi)UI。
SQL 和數(shù)據(jù)視圖
Acceldata Query 360 的提供了 SQL、被查詢(xún)的表和正在運(yùn)行的連接的視圖。除此之外，還有關(guān)于過(guò)濾條件的詳細(xì)信息、過(guò)濾謂詞是否準(zhǔn)確，以及特定連接是否對(duì)查詢(xún)產(chǎn)生了不利影響，這是 SQL 診斷最重要的方面之一。
查詢(xún)計(jì)劃
對(duì)任何查詢(xún)的最終診斷都需要知曉查詢(xún)計(jì)劃。Acceldata 支持所有類(lèi)型的 Hive和Map Reduce-Tez、MapReduce和LLAP的查詢(xún)計(jì)劃。這為管理員和數(shù)據(jù)工程師提供了一種簡(jiǎn)單的方法來(lái)了解——TableScans ，操作行為是有意的還是偶然的，廣播連接在哪里發(fā)生，CBO 是否已啟動(dòng)，是否為特定查詢(xún)?cè)O(shè)置了 PPD ，以及可以完成哪些連接優(yōu)化。
表
Hive 表的布局對(duì)查詢(xún)性能的影響是顯著的。在沒(méi)有數(shù)據(jù)壓縮或準(zhǔn)確分區(qū)的情況下，很可能會(huì)對(duì)表進(jìn)行端到端掃描，或者稱(chēng)為 TableScan，因此Mappers器將花費(fèi)更長(zhǎng)的時(shí)間來(lái)完成，盡管有過(guò)濾謂詞。
但是，為了對(duì)分區(qū)策略做出明確的決定，需要了解表和列的使用組合。分析員運(yùn)行的不是一個(gè)查詢(xún)，而是幾個(gè)查詢(xún)的組合，以確定哪個(gè)是理想的分區(qū)鍵，以及表是否可以靜態(tài)分區(qū)或動(dòng)態(tài)分區(qū)。視圖如下所示：
結(jié)論
Hive 和 Spark 用戶(hù)和管理員很難獲得一個(gè)表示查詢(xún)/作業(yè)執(zhí)行橫截面的視圖。在分布式計(jì)算領(lǐng)域，可見(jiàn)性仍然是一個(gè)挑戰(zhàn)，尤其是在 Hive 和 Spark 工作負(fù)載上。Acceldata 支持 360 度視圖以進(jìn)行決策。通過(guò)以上部分，我們可以清楚地看到 管理員/工程師擁有所有可用于識(shí)別和糾正的信息：
? 相同查詢(xún)的當(dāng)前運(yùn)行和過(guò)去運(yùn)行的歷史比較
? 執(zhí)行查詢(xún)的時(shí)間
? 有問(wèn)題的表及其連接
? Mapper 和 reducer 性能異常
? 物理文件系統(tǒng)上的數(shù)據(jù)布局，用于分區(qū)策略
? 查詢(xún)計(jì)劃可快速輕松地做出決策
【譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為.com】
網(wǎng)頁(yè)題目：修復(fù)配置單元（Hive）查詢(xún)的5個(gè)基本診斷視圖
本文URL：http://m.5511xx.com/article/coegese.html
