[[411033]]

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

Hive 和 Spark 等查詢引擎對于高級工程師來說是很復(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)致：

• 失控的資源問題

• 失控的時(shí)間問題

• 導(dǎo)致停機(jī)的泄漏

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

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

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

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

• 紗線容器的效率

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

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

• 經(jīng)過的持續(xù)時(shí)間

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

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

• VCore的使用

• 內(nèi)存利用率

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

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

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

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

查詢計(jì)劃

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

表

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

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

結(jié)論

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

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

• 執(zhí)行查詢的時(shí)間

• 有問題的表及其連接

• Mapper 和 reducer 性能異常

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

• 查詢計(jì)劃可快速輕松地做出決策

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