前言：

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

如何維穩(wěn)？

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

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

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

底層表的優(yōu)化

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

SQL優(yōu)化

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

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

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

總結(jié)：

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

總結(jié)

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

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