關(guān)于現(xiàn)代數(shù)據(jù)分析員在分布式計算環(huán)境中的有效性，引起了人們很久的爭論。分析師習(xí)慣 SQL 在短時間內(nèi)可以查詢到問題的答案。當(dāng)查詢在幾個小時內(nèi)沒有返回結(jié)果時，RDBMS 用戶通常會無法理解根本原因。

創(chuàng)新互聯(lián)建站不只是一家網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司；我們對營銷、技術(shù)、服務(wù)都有自己獨特見解，公司采取“創(chuàng)意+綜合+營銷”一體化的方式為您提供更專業(yè)的服務(wù)！我們經(jīng)歷的每一步也許不一定是最完美的，但每一步都有值得深思的意義。我們珍視每一份信任，關(guān)注我們的成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計質(zhì)量和服務(wù)品質(zhì)，在得到用戶滿意的同時，也能得到同行業(yè)的專業(yè)認(rèn)可，能夠為行業(yè)創(chuàng)新發(fā)展助力。未來將繼續(xù)專注于技術(shù)創(chuàng)新，服務(wù)升級，滿足企業(yè)一站式全網(wǎng)營銷推廣需求，讓再小的品牌網(wǎng)站制作也能產(chǎn)生價值！

Hive 和 Spark 等查詢引擎對于高級工程師來說是很復(fù)雜的，但是有的并不這樣認(rèn)為。在 Acceldata上，我們可以看到完整的表掃描在多 Tera Byte 表上運行從而獲取行數(shù)，這在 Hadoop中至少是不允許操作的。實際上，數(shù)據(jù)需要轉(zhuǎn)化為洞察力才能做出業(yè)務(wù)決策。值得一提的是，大數(shù)據(jù)的價值需要實時獲取。

Hadoop 管理員/工程師準(zhǔn)備闡釋大量的度量指標(biāo)，并分析性能不佳和從集群中拿走資源的原因，從而導(dǎo)致：

? 失控的資源問題

? 失控的時間問題

? 導(dǎo)致停機的泄漏

在開始糾正步驟之前必須提供以下詳細(xì)信息：

? 歷史查詢性能（查詢是重復(fù)的前提下）

? 執(zhí)行視圖——Mappers（映射器）、Reducer（減速器）、連接效率

? 數(shù)據(jù)視圖 - 哪些表（事實維度）

? 紗線容器的效率

? 執(zhí)行計劃——（邏輯和物理計劃）

歷史查詢性能： Acceldata APM 對在交互式 BI 隊列上運行的每個 SQL 進行指紋識別。這是通過解析 AST 來完成的，并記住經(jīng)常使用的查詢的參數(shù)進行不斷變化，例如，在每日報告的情況下。在下一次運行 SQL 時，Acceldata 能夠?qū)⒃摬樵兊倪^去性能與最近的運行相關(guān)聯(lián)。查詢執(zhí)行參數(shù)中的異常（如下所示）在視覺上表示異常：

? 經(jīng)過的持續(xù)時間

? 從 HDFS 讀取數(shù)據(jù)

? 數(shù)據(jù)寫入 HDFS

? VCore的使用

? 內(nèi)存利用率

執(zhí)行視圖： 在某些情況下，當(dāng)一個Reducers需要花費很長時間時，查詢則需要很長的持續(xù)時間，就好像一個“掉隊者”，消耗超過 90% 的持續(xù)時間。這種識別有助于整改；然而，如果要實現(xiàn)這一點，不登錄多個服務(wù)器，并且沒跨層的橫截面視圖的幫助，是非常具有挑戰(zhàn)性的。Acceldata 結(jié)合紗線診斷日志，將Mappers和Reducers的持續(xù)時間、順序可視化。

以下是紗線診斷數(shù)據(jù)，顯示紗線應(yīng)用程序從開始到結(jié)束的執(zhí)行階段。這提供了一個清晰的概念，假如 Yarn 應(yīng)用程序被搶占，那么內(nèi)存和 VCore 的分配是什么，在這些應(yīng)用程序中可以處理作業(yè)的容器的數(shù)量是多少。同時還提供了診斷消息，允許用戶在作業(yè)失敗的情況下識別異常，而無需離開UI。

SQL 和數(shù)據(jù)視圖

Acceldata Query 360 的提供了 SQL、被查詢的表和正在運行的連接的視圖。除此之外，還有關(guān)于過濾條件的詳細(xì)信息、過濾謂詞是否準(zhǔn)確，以及特定連接是否對查詢產(chǎn)生了不利影響，這是 SQL 診斷最重要的方面之一。

查詢計劃

對任何查詢的最終診斷都需要知曉查詢計劃。Acceldata 支持所有類型的 Hive和Map Reduce-Tez、MapReduce和LLAP的查詢計劃。這為管理員和數(shù)據(jù)工程師提供了一種簡單的方法來了解——TableScans ，操作行為是有意的還是偶然的，廣播連接在哪里發(fā)生，CBO 是否已啟動，是否為特定查詢設(shè)置了 PPD ，以及可以完成哪些連接優(yōu)化。

表

Hive 表的布局對查詢性能的影響是顯著的。在沒有數(shù)據(jù)壓縮或準(zhǔn)確分區(qū)的情況下，很可能會對表進行端到端掃描，或者稱為 TableScan，因此Mappers器將花費更長的時間來完成，盡管有過濾謂詞。

但是，為了對分區(qū)策略做出明確的決定，需要了解表和列的使用組合。分析員運行的不是一個查詢，而是幾個查詢的組合，以確定哪個是理想的分區(qū)鍵，以及表是否可以靜態(tài)分區(qū)或動態(tài)分區(qū)。視圖如下所示：

結(jié)論

Hive 和 Spark 用戶和管理員很難獲得一個表示查詢/作業(yè)執(zhí)行橫截面的視圖。在分布式計算領(lǐng)域，可見性仍然是一個挑戰(zhàn)，尤其是在 Hive 和 Spark 工作負(fù)載上。Acceldata 支持 360 度視圖以進行決策。通過以上部分，我們可以清楚地看到 管理員/工程師擁有所有可用于識別和糾正的信息：

? 相同查詢的當(dāng)前運行和過去運行的歷史比較

? 執(zhí)行查詢的時間

? 有問題的表及其連接

? Mapper 和 reducer 性能異常

? 物理文件系統(tǒng)上的數(shù)據(jù)布局，用于分區(qū)策略 

? 查詢計劃可快速輕松地做出決策

【譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為.com】

本文名稱：修復(fù)配置單元（Hive）查詢的5個基本診斷視圖
文章出自：http://uogjgqi.cn/article/coegese.html