【CSDN人物訪談】蔣守壯分享他的技術成長之路以及對Hive技術的解讀與思考

結緣大數據技術

CSDN:請簡單地介紹一下本身。

蔣守壯：首先很是感謝CSDN可以給我此次被專訪的機會，可讓我從新審視本身的職業發展歷程，也但願可以幫助一些同行的朋友們。目前就任萬達網絡科技集團有限公司，是一名大數據分析師和大數據平臺架構師。

我是電子專業出身，但本身對軟件行業很是感興趣，因此大學裏一邊學習本專業課程，一邊到圖書館或活躍在相關技術網站上學習計算機專業課程。雖然累點苦點，可是爲本身職業生涯打下了紮實的基礎。

從畢業後至今，我已經在IT圈跌打滾爬5年多了，經歷了不少，有苦有樂，這些都豐富了本身的閱歷。工做以來，我一直熱愛分享和交流技術，熱衷於寫博客（CSDN），參與開源社區（Apache一些頂級項目），也樂於在Github上開源本身的軟件產品。慢慢地，我從一名菜鳥，成長爲資深工程師和架構師，可是我要學習的東西太多了，我會一直堅持下去。

CSDN:你是如何與計算機結緣，踏上大數據開發之路的，可否跟咱們分享一下。

蔣守壯： 其實我與計算機結緣的緣由，可能會和一些朋友類似，是由於黑客，以爲很酷，也頗有挑戰性的。這是一個啓蒙階段，因而我開始漫長的探索，學習彙編，C語言，C++，Java；學習計算機原理，Linux內核；學習網絡，TCP/IP；學習密碼學；學習各類主流數據庫；學習腳本，Perl，Python，Shell等等。爲了測試一些病毒，由於不可能用本身筆記本的操做系統測試，因而就開始研究虛擬化技術，使用虛擬機搭建各類Linux操做系統進行模擬測試，就這樣，走上了一條不歸路（是技術研究不歸路，不是進局裏了）。在這個探索的過程當中，發現本身對Linux和數據庫方面特別感興趣，因而2011年畢業後就從事了Linux和數據庫方面的工做。

從2012年末開始，我開始接觸MPP（大規模並行處理）架構的關係型數據庫，使用和維護過Vertica和Greenplum等MPP架構的數據庫。在電信行業分析TB和PB級別海量數據時性能仍是很是不錯的。可是隨着業務的發展，處理非結構化和半結構化數據的需求迫在眉睫。我一直關注和參與Apache開源社區，見證了Hadoop生態圈的快速發展，Hadoop很是方便處理非結構化和半結構化數據，因而咱們的大數據平臺架構開始融合Hadoop，造成混合架構。隨着Hadoop生態圈家族不斷壯大，支持各類場景的組件出現，SQL支持也很是完善，因而大數據平臺架構就逐漸以Hadoop爲核心來構建。尤爲這兩年來，Spark，Flink等通用並行框架不斷髮展壯大，集成批處理，流計算，實時分析，機器學習和圖計算，爲企業級構建大數據平臺提供更多的選擇。

CSDN:分享一下你最近使用的框架，它們都解決了哪些方面的問題。

蔣守壯： 前段時間，我使用Kafka，Spark Streaming和HBase來進行實時數據計算分析，將保險用戶相關的數據發送到Kafka消息隊列，後端將從Kafka消費數據，並使用Spark Streaming進行流數據實時分析，而後將處理後的數據寫入HBase集羣中，最後用戶從HBase中獲取分析好的數據。

現階段，咱們基於現有的Hadoop大數據平臺，集成Apache Kylin組件，Kylin能夠對Hive中的表進行關聯後多維度處理，並將結果寫入HBase，其與Hadoop生態圈整合很是完善，很是適合用來作海量數據規模下的OLAP分析，進行實時或準實時查詢上百億數據。另外，Kylin和BI工具也能夠很好的集成，好比Tableau，Saiku等。

Hive痛點直擊&經驗分享

CSDN：hive的使用場景有哪些？適合實時性強的分析場景使用麼？

蔣守壯： Hive是創建在Hadoop上的數據倉庫基礎構架，它的最佳使用場合是大數據集的批處理做業，通常延遲性比較高，並不可以在大規模數據集上實現低延遲快速的查詢，因此不適合實時性強的分析場景。不過目前Hive底層的計算框架除了支持原生的MapReduce，還支持Tez和Spark，這對提高Hive的查詢處理性能幫助很大，從Hive 2.0版本開始，推薦使用Tez或Spark做爲Hive的計算引擎。

若是但願實時查詢分析，能夠結合Impala，Presto，Drill等開源的交互式、實時的查詢引擎使用，它們可以訪問Hive中的表進行數據查詢分析。

CSDN：hive的技術特色有哪些？ 類sql操做啊，內置大量用戶函數udf等等。

蔣守壯： Hive應該是第一個出現的SQL on Hadoop的產品，技術特色以下：

• 類SQL查詢方式，支持標準SQL也比較全面；
• 支持索引，加快數據查詢；
• 元數據保存在關係型數據庫中，好比MySQL，能夠減小查詢過程當中執行語義檢查的時間；
• 支持多種數據存儲格式類型，好比Text，Sequence，RCFile，Parquet和ORC等，針對不一樣的場景進行選擇；
• 數據存儲在HDFS分佈式文件系統中，實現冗餘高可用；
• 內置經常使用的基本函數，以及窗口分析型函數，同時支持用戶自定義UDF，UDAF，UDTF函數；
• 底層計算引擎支持MapReduce，Tez和Spark，根據須要進行動態選擇。

CSDN：Hive建立的內部表和外部表有何異同？

蔣守壯： 這個其實和不少傳統數據庫中的內部表和外部表同樣，沒有什麼差異。

我將從表的建立和刪除兩方面簡單介紹一下：

• Hive 建立內部表時，後面執行導入操做時會將用戶數據移動到表所在的數據倉庫指向的路徑；
• 若建立外部表時，只會記錄表對應的用戶數據所在的路徑，不對用戶數據的位置作任何改變。
• 在刪除表的時候，內部表的元數據和用戶數據會被一塊兒刪除；
• 而外部表只會刪除元數據，不刪除用戶數據。這樣外部表相對來講更加安全些，數據組織也更加靈活，方便共享源數據。

CSDN：Hive的優化技巧有哪些？好比如何處理數據傾斜、大表與小表join時，如何優化性能。

蔣守壯： Hive優化其實涉及到幾方面，其中一方面是計算引擎方面的優化，好比你使用MapReduce做爲計算引擎，那麼就須要優化MapReduce；若是你選擇Spark做爲計算引擎，那麼須要對Spark進行優化。

這裏我僅從Hive這一層面介紹該如何優化，基本內容以下：

(1)表設計層面優化

• 合理利用中間結果集，避免查過就丟的資源浪費，減低Hadoop的IO負載
• 合理設計表分區，包括靜態分區和動態分區
• 儘可能不使用複雜或低效函數，好比count(distinct)，可使用其餘方式實現
• 選擇合適的表存儲格式和壓縮格式
• 若是某些邏輯使用系統函數可能嵌套好幾層，那麼可使用自定義函數實現
• 適當使用索引

(2)語法和參數層面優化

• 合理控制mapper和reducer數
• 設置map和reduce的內存大小
• 合併小文件
• 避免數據傾斜，解決數據傾斜問題

處理數據傾斜的方法其實有不少，不管是Group by仍是Join時出現數據傾斜，其實都是數據熱點的問題，即某些Key值太多，致使都分發到一個節點執行，那麼咱們能夠將數據量比較大的Key拿出來單獨處理，最後再合併到結果集中。若是出現數據傾斜的Key值對結果可有可無，好比空值，那麼咱們能夠過濾處理，或者將空值加上隨機數，進行分發到集羣的全部節點並行處理。固然也能夠利用Hive自帶的參數進行優化，設置當分組或關聯的Key值超過多少數量時，進行單獨處理，即額外啓動一個MapReduce做業處理。 這方面的具體優化過程，請參考個人技術博客。

• 減小Job數
• Join優化

儘可能將小表放到join的左邊。小表和大表join時，若是差一個以及以上數量級而且小表數據量很小，可使用mapjoin方式，將小表所有讀入內存中，在map階段進行表關聯匹配。大表和大表進行關聯時，要注意數據傾斜的問題。若是兩個表以相同Key進行分桶，以及表的桶個數是倍數關係，可使用bucket join，加快關聯查詢。

• 避免笛卡爾積
• 提早裁剪數據，減小處理的數據量，避免資源浪費

(3)Hive Job優化

• 並行化執行——每一個查詢被Hive轉化成多個階段，有些階段關聯性不大，則能夠並行化執行，減小執行時間。
• 本地化執行
• JVM重利用——JVM重利用能夠是Job長時間保留slot，直到做業結束，這在對於有較多任務和較多小文件的任務是很是有意義的，減小執行時間。
• 推測執行——所謂的推測執行，就是當全部的task都開始運行以後，Job Tracker會統計全部任務的平均進度，若是某個task所在的節點配置內存比較低或者CPU負載很大，致使任務執行比整體任務的平均執行要慢，此時Job Tracker就會在其餘節點啓動一個新的相同的任務，原有任務和新任務哪一個先執行完就把其餘節點的另一個任務kill掉。
• Hive中間結果壓縮數據——中間壓縮就是處理Hive查詢的多個job之間的數據，對於中間壓縮，最好選擇一個節省CPU耗時的壓縮方式

CSDN：分享一下Hive數據倉庫經驗。

蔣守壯：因爲Hive的類SQL和類數據庫功能，它向非編程人員開放了大數據Hadoop生態系統，Hive也推進了Hadoop的普及和發展。

企業使用Hive來構建數據倉庫，一是能夠節約成本，二是基於SQL開發，將傳統數據庫遷移到Hadoop平臺上分析也相關方便，三是支持和Hive集成的Hadoop生態圈的產品也豐富，知足架構擴展。

在使用Hive來構建企業級數據倉庫時要注意如下幾點：

• 根據不一樣業務數據來源，在Hive建立不一樣的數據庫，方便分類管理；
• 表的文件存儲格式儘可能採用Parquet或ORC，不只下降存儲量，還優化了查詢，壓縮，表關聯等性能；
• Hive的計算引擎，推薦使用Tez或Spark；
• 實現用戶權限的控制，針對不一樣項目設置相應的用戶，相互之間權限獨立，實現數據安全，也能夠根據須要，授予相應表權限。

學習心得

CSDN：關於技術學習您有什麼心得？咱們上線了知識庫系統化學習的方法，您會怎麼應用呢？

蔣守壯： 其實我學習任何一門新技術的過程都比較類似，能夠總結爲如下幾點：

1. 俗話說，工欲善其事，必先利其器，首先我通常都會根據官方文檔將環境搭建起來，而後運行官方的示例，先從總體上感覺一下。
2. 閱讀該新技術比較好的書籍或博客文檔，最好結合官方文檔一塊兒閱讀，必定要記得作筆記或寫博客。與此同時，能夠多加入一些技術羣或公衆號。
3. 當對該技術的原理，架構，基本操做都熟練時，就開始尋找好的項目進行實戰，如今Github上開源項目不少，能夠學習別人的思路或開發過程。
4. 源碼分析，這個是加深理解該技術的關鍵步驟。若是你只但願達到應用的水平，能夠不用分析源碼；可是若是你但願可以優化或者定製該技術某些方面，那麼分析源碼是必經的過程。
5. 對於源碼分析，必定不要漫無目的的查看源碼，由於如今不少開源軟件的代碼比較多，這樣你將很容易進入黑洞，不可自拔，回頭一看，可能啥都不知道了。源碼分析先挑選簡單的模塊分析，搭建好調測平臺，進行代碼跟蹤，這樣能夠增長自信心。假如我要分析Spark源碼，我首先查看Spark啓動、客戶端訪問部分的源碼，看一下RDD底層源碼如何實現，也就是你要選擇一個主題去分析源碼並跟蹤調測，長此以往，我就會將不少模塊內容串聯起來，也慢慢加深對Spark源碼的理解。
6. 最後，對修改的源碼進行從新編譯打包，而後部署環境進行驗證，體會激動的時刻。

上面的過程是交互循環的，不是一蹴而就的，你將須要經歷時間的磨練，並且在這過程當中，你會遇到不少問題，必定要對每一個問題刨根問底，從根本上解決，而且堅持作好筆記或寫博客，方便後續查看。

另外，CSDN推出的知識庫，給咱們提供了系統學習的方法。若是我要學習一門新技術，好比Docker，我能夠進入Docker知識庫，裏面列出了Docker的每一個知識點，而且每一個知識點下面都會有該領域的專家精選的博客文章。此外，還能夠把其它平臺上看到的乾貨添加到本身的我的圖譜當中，建立你的專屬知識庫。選擇本身感興趣的知識點進行系統學習，效率很是高。

CSDN:據說你在10月份即將推出本身的第一本技術書籍，請簡單介紹一下。

蔣守壯： Apache的頂級項目Apache Kylin，這是一個開源的分佈式分析引擎，是由eBay研發並貢獻給開源社區，其提供Hadoop之上的SQL查詢接口及多維分析（OLAP）能力以支持超大規模數據。書的名字暫定爲《基於Apache Kylin構建企業級大數據分析平臺》，預計10月份底左右出版，該書比較全面地介紹Apache Kylin的各方面，以及集成到現有的大數據平臺中進行多維數據分析。

關注Kylin項目好久了，也見證了第一個由中國團隊完整貢獻到Apache的頂級項目。尤爲這一年多，Kylin快速發展，功能和穩定性不斷提高，我也積極地參與Kylin開源社區，同時也但願藉助本身的微薄力量來推廣Kylin的使用，幫助更多的朋友認識和使用Kylin來解決企業中基於Hadoop的多維數據分析的需求。

CSDN：你最近關注的技術有哪些？

蔣守壯：這段時間研究的技術，大致上有三方面，這裏我就簡單描述一下，具體你們能夠訪問官網查詢更多內容：

第一方面：自動化運維工具Ansible。Ansible算是比較新的自動運維工具，基於Python開發，集合了衆多運維工具的優勢，實現了批量系統配置，批量程序部署和批量運行命令等功能。研究這方面內容，主要是由於項目組已經實現基於Ansible快速部署高可用而且安全的大數據平臺，提高用戶的體驗效果和滿意度。

第二方面：Flink實時流處理框架。我的一直以爲Flink在實時流方面的架構很是優秀，並且只須要不多的配置就可以實現高吞吐率和低延遲。未來但願在項目中更多地實戰Flink實時流處理應用。

第三方面：Docker容器技術。深刻研究Docker在分佈式和大數據架構中的應用，好比基於Docker構建企業的私用鏡像倉庫，方便企業可以快速部署大數據平臺，也能夠將企業中的一些應用實現Docker微服務化。