在大會前夕，高可用架構採訪了本屆 GIAC大數據分論壇 出品人馬如悅，就目大家廣泛關注的大數據方面的問題進行了訪談。
馬如悅，百度大數據主任架構師，當前是百度大數據技術總負責人，百度雲數據分析產品技術總負責人，負責百度內外部大數據處理相關產品的規劃和研發。同時也是Palo項目的技術負責人。在領導分析數據庫方向以前，一直是百度分佈式計算方向的技術負責人，是百度Hadoop團隊的創始人。其領導的Palo項目，已經上線百度近50個產品線。
高可用架構：馬老師，您好，很高興能訪談到您。您在百度有十多年了吧？從剛開始的高級工程師，到現在的主任架構師，您工作和生活中最大的改變是什麼？能否結合您的親身體會談一談技術人的技術路線和管理路線的有何不同以及如何抉擇？
馬如悅：百度內部是分技術路線和管理路線的。在技術類的公司，我自己這麼多年的感受是，在級別低的時候，管理和技術實際上更偏重技術多一些，就是即使是做管理，也是需要深入瞭解一線技術的。但是隨著職級的提升，管理和技術也都會轉為偏向管理一些，只是側重點不同。
原來你只是一個模塊或者一個小方向的技術負責人的話，很多時候，更多依賴的是你個人的能力和決策；但是當你成為多個方向的技術負責人，負責的技術團隊到上百人的話，這個時候，你的精力和能力是無法做到像小團隊那樣，這個時候，作為技術負責的同學，就需要培養技術梯隊，協同好各個子技術方向的負責人，定宏觀和長遠戰略，充分發揮團隊自己的能動性。這也就是我說的，隨著職級的提升，會更偏向管理多一些。
我覺得作為一個喜歡技術的新人，應該還是從做技術開始，等到職級到了一定程度，再轉向管理。一個方面是較低的管理職級實際上發揮不了太大管理作用，所以在很多其他互聯網公司，在低級別，技術和管理是一體的，只是到上面才會逐漸分開。
高可用架構：大家都知道您在OLAP和OLTP領域耕耘很多年了，是什麼樣的契機讓您開始這兩個方向研究的？它們究竟有怎樣的魅力吸引您願意花長時間去鑽研？
馬如悅：我研究生是在清華做ChinaGrid的，07年畢業有幸進入百度去開闢分佈式計算方向。那個時候，Hadoop開始火起來，所有的互聯網公司都在做。做了5、6年的離線計算平臺，當時百度已經比較成熟了。那個時候，遇到了很多新的業務問題，發現是Hadoop這種離線框架不好做的，需要類似大規模在線數據庫這種，所以自己就主動要求轉崗了，從一個幾十人的大團隊接手了一個幾個人的在線數據庫小團隊，開始走上了在線數據庫領域。在新的方向上，我們通過5年的時間，建立了百度新式數據庫團隊，傳統數據庫團隊還是有DBA團隊在負責，百度新的數據庫技術基本都在我們這個團隊。我們先後做了面向結構化的在線數倉，面向文本非結構化的搜索分析數據庫，以及面向事務的NewSQL數據庫。
我個人是一個偏向喜歡做前沿技術的人，所以只要有比較好的前沿技術，只要這些技術可能對業務帶來前所未有的改進，就對我有無窮的吸引力。我並不崇尚那些極度高級和複雜的技術，我更崇尚那些可以帶來更大落地效果的技術。比如，隨著人工智能技術的進步，我們現在也在轉向怎麼利用機器學習來進行更加智能數據分析的技術，比如AutoML技術，Augmented Analytics等技術。
高可用架構：現在開源的比較知名的OLAP都有哪些？根據存儲數據的方式不同，OLAP可以分為ROLAP、MOLAP、HOLAP等等，您主導研發的OLAP系統屬於哪種類型？選擇這種類型是怎麼考慮的？當初是什麼原因決定要自研的？
馬如悅：我們研發的Palo實際上是ROLAP的。但是我個人不喜歡將任何產品非得劃分為ROLAP、MOLAP或者HOLAP，這種被人總結成標準的條條框框，理解好了，可以指導你的工作方向，理解不好了，可能會限制你的思路。所以在Palo裡，從來不會去說這個東西是MOLAP的，我們做得是ROLAP的，這個不合適，所以不去做。
百度的Palo都是根據自己的業務需求，和參照同行，比如Google的一些做法，去開發的，不是根據教科書去做得。Palo的分佈式存儲引擎是自研的，查詢引擎是基於Impala做優化的。Palo除了滿足業務性能要求外，主要追求的是簡單，就是開發、使用、理解都簡單。很多類似解決方案都複雜無比，比如依賴zookeeper，依賴hbase，依賴hdfs，依賴hive，依賴MapReduce等。而這些依賴都大大增加了使用和運維的負擔，在在線系統中，這種依賴造成的各種問題實在是太多了。所以Palo當時追求的目標就是簡單有效。
高可用架構：OLAP和OLTP場景有怎樣的不同？兩者的融合是否是未來的趨勢？您認為融合的難點在哪？融合之後，將會對大數據領域產生怎樣的變化？
馬如悅：OLAP是面向分析的，OLTP是面向事務的，一般面向的業務需求不一樣。這一兩年，很多產品都大談HTAP的概念，所以現在又多出了一個HTAP的系統。
HTAP系統我個人認為一定是未來的趨勢，分久必合，合久必分。但是這個需要多未來，就不好說了。很多產品大談HTAP，搞得好像這個時代就馬上到來一樣。實際上很多產品，一開始奔著是做NewSQL, 就是新一代OLTP領域去的，但是等做得差不多，出去談客戶，發現客戶對新的OLTP的需求不大，尤其是對新的不成熟的OLTP產品，在重要的業務上使用，沒有啥興趣。但是，發現在新的OLAP需求卻很大，那怎麼辦？就談HTAP唄。所以現在業界大多談HTAP的都是做NewSQL出身的。是不是商業的噱頭咱先放一邊。從長遠來看，隨著硬件技術，業務需求的轉變都可能對HTAP技術需求越來越大。所以我認為HTAP是個趨勢。
但是，我十分不認同，在解決實際問題的時候，大家為了追求趨勢而去採用HTAP技術。實際上很多當前的業務和系統，OLTP和OLAP分離去解決，是最自然的，也是最高效和穩定的，那為啥非得耦合到一起，並且可能容忍在某一個特性上的短板。HTAP技術我覺得可以作為NewSQL未來延展的一個方向去研究，但是遇到實際問題還是要綜合考慮，是OLAP/OLTP分離好，還是混合好。
高可用架構：大數據發展超過10年了，大數據生態中各種組件層出不窮，比如ELK、Impala、Spark、Flink、Storm等等，您覺得出現這種情況說明了什麼呢？這些組件有沒有您特別推薦大家使用的以及推薦的理由是什麼？
馬如悅：出現大量的組件，說明這個領域還遠未成熟，當某個領域非常成熟後，就基本上會收斂成幾個穩定的技術產品。也就是因為有很多組件，所以做集成方案是有前途的一個方向。
我個人現在比較傾向的是：離線使用Spark/H2O/Tensorflow組合，在線分析使用Palo/ELK，NewSQL大家可以關注一下Apple開源的FoundationDB。
高可用架構：說到大數據就不得不說Hadoop。有人說Hadoop正在淪為日誌處理工具，對此，您是如何理解的？有什麼樣的看法？
馬如悅：我認為Hadoop沒有不被Spark取代的任何理由。Hadoop能做到的，Spark都能做到，或者即將都可以做到。所以如果你是這個領域的新人，建議可以直接從Spark學起。很多公司都在使用Hadoop，並不一定說明Hadoop好於Spark，大部分情況是遺留系統，遷移成本巨大造成的。如果你能挑出一個Spark做得不如Hadoop好得點，不要轉向Hadoop，而是努力為Spark解決掉這個問題。
高可用架構：最近幾年TiDB、Kylin等開源項目在大數據領域的應用也逐漸流行起來，在您看來，他們都有什麼樣的優劣？解決了用戶怎樣的痛點？
馬如悅：TiDB和Kylin都是中國做得非常好的開源軟件，也讓硅谷的人瞭解中國人也是可以搞出世界級的開源項目的。TiDB的劉奇和東旭，以及Kylin的韓卿，我們都有交流，從他們那裡學到了很多東西。
TiDB我更傾向於認為是個NewSQL產品，主要是一個New OLTP的產品，可能是NewSQL叫得太多了，並且在TiDB的前期客戶中，更多人可能拿他用來做分析用，所以他們現在更多得是把自己定位為HTAP，畢竟叫HTAP的產品現在遠少於NewSQL，哈哈。TiDB同學對技術的那種追求是令我羨慕的，所以致力於HTAP方向的同學建議可以投入他們社區研發，幫他們做到更好。
Kylin是一個New OLAP的產品，周圍也有很多公司在用，大家也可以試用一下。但是這裡給Kylin提一個建議，就是Kylin還是依賴了太多Hadoop組件，而這些依賴讓Kylin的易用性會大大折扣。所以Kylin下一步可以不斷收斂內聚一些，但是Kylin還是一個不錯的產品，大家都可以嘗試一下。
高可用架構：容器引領了微服務潮流，在大數據領域的基礎設施、資源混合使用以及運維自動化等方面應用廣泛嗎？目前的現狀和可能的原因是什麼？
馬如悅：AWS認為容器和Serverless是這一兩年最火爆的技術。尤其是容器技術，在私有化部署產品時，更是上乘之選，直接解決了兼容性問題。AWS在容器技術方面，也在這1-2年先後推出了3款產品，可見其重要性。
百度也基本上從今年起，將所有的大數據計算和人工智能等計算全部遷移到容器平臺上進行統一調度。
所以，容器當前可能也有一些不好的地方，比如使用起來還是比較費勁，對底層存儲掛載也都少許不好用，但是從長遠來看，容器的大規模在IDC的使用基本沒有懸念了。
高可用架構：您目前最關注的新技術有哪些？最有可能給大數據領域帶來變革的是什麼？
馬如悅：我現在主要關注的就是機器學習、人工智能在數據分析的應用，比如類似AutoML的技術。我們正在努力打造一款新時代的類SAS的數據分析產品。
高可用架構：您此次參加GIAC，給大家帶來了什麼樣的乾貨？方便透露一下嗎？
馬如悅：此次主要還是想和大家分享一下百度雲是怎麼思考大數據平臺架構的。
本期 GIAC 大會上，大數據和人工智能部分的精彩議題如下：
參加 GIAC，盤點2018最新技術。點擊“閱讀原文”瞭解大會更多詳情。
閱讀更多 高可用架構 的文章
