前言：
對於任何使用大數據技術的公司來說，大數據平臺特別是Hive來說，維護其高效快速的運行，對整個公司的運作來說至關重要。比如說：某個調度任務失敗了造成業務部門的某些報表無法正常產出；hive平臺最近速度下降了，造成業務跑sql，跑半天不出結果，進而發起投訴等等。對於數據平臺來說任何一個小的事故輕則造成公司的運行效率降低，重則使整個公司的業務運行異常（異常可能不會被立刻發現）等等，可以誇張點的說，數據將像電力資源一樣對整個公司至關重要，而數據平臺自然也是其中的“主角”。那我們要如何確保這個“主角”可以一直穩定的運行呢？廢話少說，下面就結合博主的一些經歷，簡單聊下數據平臺維穩的一些想法。特此聲明，本人菜鳥一枚，以下想法純屬胡扯，如有說的不對的地方，望各位大佬多多指教，也歡迎各位評論交流。
如何維穩？
針對如何維護數據平臺穩定的問題，我想拿一些問題從以下幾個層面說下自己的一些想法：底層表，SQL，調度任務。
問題場景一：業務頻繁反饋Hive平臺運行查詢慢。
針對以上問題，可能是由多方面的原因引起的，也可以有多種解決辦法。但是首先我想拋出的一個問題是：“如何證實業務所說的話？”凡事講究證據，特別是在這個DT的時代。所以首先我覺得應該有一些指標來量化Hive平臺運行的快慢，比如我們可以統計下每天Hive平臺執行SQL的平均時間。根據這些指標，我們知道Hive平臺的確變慢了，那如何去優化呢？業務我們可以加資源（加機器，加內存，換硬件設備如固態硬盤，調整集羣參數等等）。但是我想說的還是我們要做的任何的優化的操作的依據是什麼？或者說如果我們不知道要進行那種優化的操作，那我們能不能用一些方法排除掉我們不需要進行哪些方法去優化？用一些什麼樣的方法呢？還是指標量化的方法，拿出有效的指標去論證你的觀點，而不是通過拍腦門來決定，特別是針對已有大量數據積累的場景下。
我們經常爲業務做各種報表來輔助決策，那爲什麼我們不能爲包含各類數據的數據平臺的來做一版“體檢表”來定位各種問題，進而爲解決各種問題做決策呢？所以這篇文章我想傳達的一點是通過指標化，報表化的方法來幫助你做決策或者說定位問題，解決問題，也就是用數據分析的方法來維護數據平臺。
針對上面拋出的怎麼優化的問題，說實話，我也沒有一套很好的策略說要怎麼做怎麼做。但是我結合下自己的工作經歷說下其中的一些想法吧。
底層表的優化
問題場景：數據倉庫長時間未進行過底層數據的整理，如果說在近期業務量未大幅增加的情況下，Hive平臺慢會不會是由於底層數據的“異常”造成的？
爲了印證想法，開始着手先對數倉的底層表進行統計分析，主要從以下幾個維度去初步生成一份報表：“表名，表大小，小文件數，更新時間，分區數，近段時間表的查詢次數”。有了這張表我就對數倉底層的表數據一目瞭然，這裏針對上面的問題，我們可以從“表的查詢次數”和“小文件數量”兩個維度進行分析，通過觀察最常用的一些表的小文件數的情況來判定是否是底層表小文件的原因造成Hive平臺慢的問題。當然有了這張報表，後續我們可以高效的完成各種需求：比如要節省硬盤空間，可以通過“表大小”，“表更新時間”字段進行高效的操作，以最低的成本（處理少量的表，節省大量的空間）獲取不錯的成果。當然後續該報表可以衍生出其他的字段如“是否包含V表”，“是否是分區表”等等，也可以和其他的數據關聯衍生出更多的新的字段，如根據表名是否可以和業務的sql_log表進行關聯，這樣你可以從公司，部門，個人三個層面得到對不同表的查詢次數，知道這些會不會對我們數倉的搭建有幫助？再放開腦洞一點，如果知道sql中每條sql對應的引用的表和查詢的用戶，可否利用算法建模來做一個推薦系統，比如用戶輸入sql的過程中可以自動推薦出接下來需要關聯的表；更甚者是否能從中提取出表和表之間的類似相關係數的指標去衡量各個表之間的關聯？最終如果說能再細分到字段和字段之間的聯繫（比如我知道對於某個部門來說哪幾個字段一起出現的概率很大），那麼我們就真的達到了利用數據挖掘技術來倒推出業務知識（業務知識體現在某組一起出現字段，但是爲什麼這組字段會一起出現，背後的業務含義我們並不知道，但是這又有什麼關係，至少有了這些信息對我們搭建數倉來說已經足夠了。畢竟比如你讓搞數倉的去熟知業務和搞業務的去熟知數倉表是同等難度（這也是技術和業務之間的代溝），如果有了上面的一些信息，那就相當於搞數倉的搞懂了業務，這不正是技術人員所需要的）。
SQL優化
針對SQL的優化，我們可否利用報表去定位問題？
比如有時候，對於已經上線的調度任務，由於各種原因會去優化相關的sql。但是如何篩選這些sql以及如何快速的優化這些sql呢？自己的一個想法：以sql_log爲基礎數據，首先篩選出目標類別的sql數據（調度任務的sql），之後可以以sql耗時爲度量篩選簇耗時較多的sql進行優化，一條sql耗時慢可能和許多因素有關：如表相關的因素小文件數量、表大小等，sql語法的因素等。那麼如何才能快速的確定到底是那些因素呢？正常的操作，也許我們需要將這條sql拿出來，然後一點點執行，一步步的分析問題原因。但是針對一些經驗化，固定化的操作可否轉化爲相應的指標？比如針對優化調度任務sql的問題，如果我有一張報表裏面包含以下字段“sql語句，sql耗時，sql中各表的大小，sql中各表的小文件數”等，那麼我們是不是就可以直接排除小文件數量的問題，進而去驗證其他的原因。當然這張報表絕不可能停留在這個階段，後續根據排查問題的需要，你可以添加任何的指標字段（如針對Spark的任務能否將sql執行時你在SparkUI中看到的信息加進來等），來幫助排查問題，這樣的話，你甚至不需要執行一條sql就能定位到問題！
調度任務的優化
調度任務如何才能科學合理的規劃？也是一直再思考的問題。雖然市面上有各種調度任務框架如Azkaban等，他們有很好的功能來滿足調度的需求，但是這對於整個調度任務更高效的運行來說好像還有點差距。比如最近要上個新的調度任務，我要把它放到那個時間段去執行？某些調度任務經常性失敗的原因是什麼？
嗯~~，我想表達的是無論是Azkaban也好還是其他的調度任務框架，我們能看到的只是單個的調度任務本身，並沒有一個更高的維度來描述一羣調度任務運行的情況。針對上面的問題同樣可能的原因有很多中，那我們能否通過一些圖表來排除一些原因呢？如果我們有一張描述調度任務的圖表，橫軸代表的時間，縱軸代表的是平臺總的資源使用情況，如內存（如果能顯示並行的任務名稱更好）。那麼我們就能知道任何的時間點，我們平臺的任務並行度以及對應的資源使用情況，這樣對我們新增的調度任務的添加或者說整個調度任務更科學的規劃會不會有更好的幫助？如果能在圖中的時間軸標註下每次發生的事故事件，那對我們分析事故會不會有一個更高層面的認識？有了更高維度的認識，也就會少犯很多錯誤，產生更少的事故。
總結：
以上只是自己腦洞大開的一些想法，比較亂，也是想到哪寫到哪，如果能對各位有幫助更好。但是隻想傳遞一點：就是如何將工作中一些經驗性、重複性的工作給指標化，利用數據分析的思路來“高效”的工作，更好的去定位問題，解決問題，甚至預防問題的發生等。總之，在這個DT的時代，我們要利用好深表的數據，凡事儘可能的拿數據說話，而不是拍腦門做決定。