前言：

對于任何使用大數(shù)據(jù)技術(shù)的公司來說，大數(shù)據(jù)平臺(tái)特別是Hive來說，維護(hù)其高效快速的運(yùn)行，對整個(gè)公司的運(yùn)作來說至關(guān)重要。比如說：某個(gè)調(diào)度任務(wù)失敗了造成業(yè)務(wù)部門的某些報(bào)表無法正常產(chǎn)出；hive平臺(tái)最近速度下降了，造成業(yè)務(wù)跑sql，跑半天不出結(jié)果，進(jìn)而發(fā)起投訴等等。對于數(shù)據(jù)平臺(tái)來說任何一個(gè)小的事故輕則造成公司的運(yùn)行效率降低，重則使整個(gè)公司的業(yè)務(wù)運(yùn)行異常（異常可能不會(huì)被立刻發(fā)現(xiàn)）等等，可以夸張點(diǎn)的說，數(shù)據(jù)將像電力資源一樣對整個(gè)公司至關(guān)重要，而數(shù)據(jù)平臺(tái)自然也是其中的“主角”。那我們要如何確保這個(gè)“主角”可以一直穩(wěn)定的運(yùn)行呢？廢話少說，下面就結(jié)合博主的一些經(jīng)歷，簡單聊下數(shù)據(jù)平臺(tái)維穩(wěn)的一些想法。特此聲明，本人菜鳥一枚，以下想法純屬胡扯，如有說的不對的地方，望各位大佬多多指教，也歡迎各位評論交流。

如何維穩(wěn)？

針對如何維護(hù)數(shù)據(jù)平臺(tái)穩(wěn)定的問題，我想拿一些問題從以下幾個(gè)層面說下自己的一些想法：底層表，SQL，調(diào)度任務(wù)。
問題場景一：業(yè)務(wù)頻繁反饋Hive平臺(tái)運(yùn)行查詢慢。
針對以上問題，可能是由多方面的原因引起的，也可以有多種解決辦法。但是首先我想拋出的一個(gè)問題是：“如何證實(shí)業(yè)務(wù)所說的話？”凡事講究證據(jù)，特別是在這個(gè)DT的時(shí)代。所以首先我覺得應(yīng)該有一些指標(biāo)來量化Hive平臺(tái)運(yùn)行的快慢，比如我們可以統(tǒng)計(jì)下每天Hive平臺(tái)執(zhí)行SQL的平均時(shí)間。根據(jù)這些指標(biāo)，我們知道Hive平臺(tái)的確變慢了，那如何去優(yōu)化呢？業(yè)務(wù)我們可以加資源（加機(jī)器，加內(nèi)存，換硬件設(shè)備如固態(tài)硬盤，調(diào)整集群參數(shù)等等）。但是我想說的還是我們要做的任何的優(yōu)化的操作的依據(jù)是什么？或者說如果我們不知道要進(jìn)行那種優(yōu)化的操作，那我們能不能用一些方法排除掉我們不需要進(jìn)行哪些方法去優(yōu)化？用一些什么樣的方法呢？還是指標(biāo)量化的方法，拿出有效的指標(biāo)去論證你的觀點(diǎn)，而不是通過拍腦門來決定，特別是針對已有大量數(shù)據(jù)積累的場景下。

我們經(jīng)常為業(yè)務(wù)做各種報(bào)表來輔助決策，那為什么我們不能為包含各類數(shù)據(jù)的數(shù)據(jù)平臺(tái)的來做一版“體檢表”來定位各種問題，進(jìn)而為解決各種問題做決策呢？所以這篇文章我想傳達(dá)的一點(diǎn)是通過指標(biāo)化，報(bào)表化的方法來幫助你做決策或者說定位問題，解決問題，也就是用數(shù)據(jù)分析的方法來維護(hù)數(shù)據(jù)平臺(tái)。

針對上面拋出的怎么優(yōu)化的問題，說實(shí)話，我也沒有一套很好的策略說要怎么做怎么做。但是我結(jié)合下自己的工作經(jīng)歷說下其中的一些想法吧。

底層表的優(yōu)化

問題場景：數(shù)據(jù)倉庫長時(shí)間未進(jìn)行過底層數(shù)據(jù)的整理，如果說在近期業(yè)務(wù)量未大幅增加的情況下，Hive平臺(tái)慢會(huì)不會(huì)是由于底層數(shù)據(jù)的“異常”造成的？
為了印證想法，開始著手先對數(shù)倉的底層表進(jìn)行統(tǒng)計(jì)分析，主要從以下幾個(gè)維度去初步生成一份報(bào)表：“表名，表大小，小文件數(shù)，更新時(shí)間，分區(qū)數(shù)，近段時(shí)間表的查詢次數(shù)”。有了這張表我就對數(shù)倉底層的表數(shù)據(jù)一目了然，這里針對上面的問題，我們可以從“表的查詢次數(shù)”和“小文件數(shù)量”兩個(gè)維度進(jìn)行分析，通過觀察最常用的一些表的小文件數(shù)的情況來判定是否是底層表小文件的原因造成Hive平臺(tái)慢的問題。當(dāng)然有了這張報(bào)表，后續(xù)我們可以高效的完成各種需求：比如要節(jié)省硬盤空間，可以通過“表大小”，“表更新時(shí)間”字段進(jìn)行高效的操作，以最低的成本（處理少量的表，節(jié)省大量的空間）獲取不錯(cuò)的成果。當(dāng)然后續(xù)該報(bào)表可以衍生出其他的字段如“是否包含V表”，“是否是分區(qū)表”等等，也可以和其他的數(shù)據(jù)關(guān)聯(lián)衍生出更多的新的字段，如根據(jù)表名是否可以和業(yè)務(wù)的sql_log表進(jìn)行關(guān)聯(lián)，這樣你可以從公司，部門，個(gè)人三個(gè)層面得到對不同表的查詢次數(shù)，知道這些會(huì)不會(huì)對我們數(shù)倉的搭建有幫助？再放開腦洞一點(diǎn)，如果知道sql中每條sql對應(yīng)的引用的表和查詢的用戶，可否利用算法建模來做一個(gè)推薦系統(tǒng)，比如用戶輸入sql的過程中可以自動(dòng)推薦出接下來需要關(guān)聯(lián)的表；更甚者是否能從中提取出表和表之間的類似相關(guān)系數(shù)的指標(biāo)去衡量各個(gè)表之間的關(guān)聯(lián)？最終如果說能再細(xì)分到字段和字段之間的聯(lián)系（比如我知道對于某個(gè)部門來說哪幾個(gè)字段一起出現(xiàn)的概率很大），那么我們就真的達(dá)到了利用數(shù)據(jù)挖掘技術(shù)來倒推出業(yè)務(wù)知識(shí)（業(yè)務(wù)知識(shí)體現(xiàn)在某組一起出現(xiàn)字段，但是為什么這組字段會(huì)一起出現(xiàn)，背后的業(yè)務(wù)含義我們并不知道，但是這又有什么關(guān)系，至少有了這些信息對我們搭建數(shù)倉來說已經(jīng)足夠了。畢竟比如你讓搞數(shù)倉的去熟知業(yè)務(wù)和搞業(yè)務(wù)的去熟知數(shù)倉表是同等難度（這也是技術(shù)和業(yè)務(wù)之間的代溝），如果有了上面的一些信息，那就相當(dāng)于搞數(shù)倉的搞懂了業(yè)務(wù)，這不正是技術(shù)人員所需要的）。

SQL優(yōu)化

針對SQL的優(yōu)化，我們可否利用報(bào)表去定位問題？
比如有時(shí)候，對于已經(jīng)上線的調(diào)度任務(wù)，由于各種原因會(huì)去優(yōu)化相關(guān)的sql。但是如何篩選這些sql以及如何快速的優(yōu)化這些sql呢？自己的一個(gè)想法：以sql_log為基礎(chǔ)數(shù)據(jù)，首先篩選出目標(biāo)類別的sql數(shù)據(jù)（調(diào)度任務(wù)的sql），之后可以以sql耗時(shí)為度量篩選簇耗時(shí)較多的sql進(jìn)行優(yōu)化，一條sql耗時(shí)慢可能和許多因素有關(guān)：如表相關(guān)的因素小文件數(shù)量、表大小等，sql語法的因素等。那么如何才能快速的確定到底是那些因素呢？正常的操作，也許我們需要將這條sql拿出來，然后一點(diǎn)點(diǎn)執(zhí)行，一步步的分析問題原因。但是針對一些經(jīng)驗(yàn)化，固定化的操作可否轉(zhuǎn)化為相應(yīng)的指標(biāo)？比如針對優(yōu)化調(diào)度任務(wù)sql的問題，如果我有一張報(bào)表里面包含以下字段“sql語句，sql耗時(shí)，sql中各表的大小，sql中各表的小文件數(shù)”等，那么我們是不是就可以直接排除小文件數(shù)量的問題，進(jìn)而去驗(yàn)證其他的原因。當(dāng)然這張報(bào)表絕不可能停留在這個(gè)階段，后續(xù)根據(jù)排查問題的需要，你可以添加任何的指標(biāo)字段（如針對Spark的任務(wù)能否將sql執(zhí)行時(shí)你在SparkUI中看到的信息加進(jìn)來等），來幫助排查問題，這樣的話，你甚至不需要執(zhí)行一條sql就能定位到問題！

調(diào)度任務(wù)的優(yōu)化

調(diào)度任務(wù)如何才能科學(xué)合理的規(guī)劃？也是一直再思考的問題。雖然市面上有各種調(diào)度任務(wù)框架如Azkaban等，他們有很好的功能來滿足調(diào)度的需求，但是這對于整個(gè)調(diào)度任務(wù)更高效的運(yùn)行來說好像還有點(diǎn)差距。比如最近要上個(gè)新的調(diào)度任務(wù)，我要把它放到那個(gè)時(shí)間段去執(zhí)行？某些調(diào)度任務(wù)經(jīng)常性失敗的原因是什么？
嗯~~，我想表達(dá)的是無論是Azkaban也好還是其他的調(diào)度任務(wù)框架，我們能看到的只是單個(gè)的調(diào)度任務(wù)本身，并沒有一個(gè)更高的維度來描述一群調(diào)度任務(wù)運(yùn)行的情況。針對上面的問題同樣可能的原因有很多中，那我們能否通過一些圖表來排除一些原因呢？如果我們有一張描述調(diào)度任務(wù)的圖表，橫軸代表的時(shí)間，縱軸代表的是平臺(tái)總的資源使用情況，如內(nèi)存（如果能顯示并行的任務(wù)名稱更好）。那么我們就能知道任何的時(shí)間點(diǎn)，我們平臺(tái)的任務(wù)并行度以及對應(yīng)的資源使用情況，這樣對我們新增的調(diào)度任務(wù)的添加或者說整個(gè)調(diào)度任務(wù)更科學(xué)的規(guī)劃會(huì)不會(huì)有更好的幫助？如果能在圖中的時(shí)間軸標(biāo)注下每次發(fā)生的事故事件，那對我們分析事故會(huì)不會(huì)有一個(gè)更高層面的認(rèn)識(shí)？有了更高維度的認(rèn)識(shí)，也就會(huì)少犯很多錯(cuò)誤，產(chǎn)生更少的事故。

總結(jié)：

以上只是自己腦洞大開的一些想法，比較亂，也是想到哪寫到哪，如果能對各位有幫助更好。但是只想傳遞一點(diǎn)：就是如何將工作中一些經(jīng)驗(yàn)性、重復(fù)性的工作給指標(biāo)化，利用數(shù)據(jù)分析的思路來“高效”的工作，更好的去定位問題，解決問題，甚至預(yù)防問題的發(fā)生等。總之，在這個(gè)DT的時(shí)代，我們要利用好深表的數(shù)據(jù)，凡事盡可能的拿數(shù)據(jù)說話，而不是拍腦門做決定。

總結(jié)

以上是生活随笔為你收集整理的浅谈管理数据平台的一些想法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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