導(dǎo)讀：6 月 1 ~ 2 日，GIAC 全球互聯(lián)網(wǎng)架構(gòu)大會將于深圳舉行。GIAC 是一個面向架構(gòu)師、技術(shù)負(fù)責(zé)人及高端技術(shù)從業(yè)人員的技術(shù)架構(gòu)大會。今年的 GIAC 已經(jīng)有騰訊、阿里巴巴、百度、今日頭條、科大訊飛、新浪微博、小米、美圖、Oracle、鏈家、唯品會、京東、餓了么、美團(tuán)點(diǎn)評、羅輯思維、ofo 等公司專家出席。

在大會前夕，高可用架構(gòu)采訪了本屆 GIAC大數(shù)據(jù)分論壇 出品人馬如悅，就目大家廣泛關(guān)注的大數(shù)據(jù)方面的問題進(jìn)行了訪談。

馬如悅，百度大數(shù)據(jù)主任架構(gòu)師，當(dāng)前是百度大數(shù)據(jù)技術(shù)總負(fù)責(zé)人，百度云數(shù)據(jù)分析產(chǎn)品技術(shù)總負(fù)責(zé)人，負(fù)責(zé)百度內(nèi)外部大數(shù)據(jù)處理相關(guān)產(chǎn)品的規(guī)劃和研發(fā)。同時也是Palo項(xiàng)目的技術(shù)負(fù)責(zé)人。在領(lǐng)導(dǎo)分析數(shù)據(jù)庫方向以前，一直是百度分布式計算方向的技術(shù)負(fù)責(zé)人，是百度Hadoop團(tuán)隊的創(chuàng)始人。其領(lǐng)導(dǎo)的Palo項(xiàng)目，已經(jīng)上線百度近50個產(chǎn)品線。

高可用架構(gòu)：馬老師，您好，很高興能訪談到您。您在百度有十多年了吧？從剛開始的高級工程師，到現(xiàn)在的主任架構(gòu)師，您工作和生活中最大的改變是什么？能否結(jié)合您的親身體會談一談技術(shù)人的技術(shù)路線和管理路線的有何不同以及如何抉擇？

馬如悅：百度內(nèi)部是分技術(shù)路線和管理路線的。在技術(shù)類的公司，我自己這么多年的感受是，在級別低的時候，管理和技術(shù)實(shí)際上更偏重技術(shù)多一些，就是即使是做管理，也是需要深入了解一線技術(shù)的。但是隨著職級的提升，管理和技術(shù)也都會轉(zhuǎn)為偏向管理一些，只是側(cè)重點(diǎn)不同。

原來你只是一個模塊或者一個小方向的技術(shù)負(fù)責(zé)人的話，很多時候，更多依賴的是你個人的能力和決策；但是當(dāng)你成為多個方向的技術(shù)負(fù)責(zé)人，負(fù)責(zé)的技術(shù)團(tuán)隊到上百人的話，這個時候，你的精力和能力是無法做到像小團(tuán)隊那樣，這個時候，作為技術(shù)負(fù)責(zé)的同學(xué)，就需要培養(yǎng)技術(shù)梯隊，協(xié)同好各個子技術(shù)方向的負(fù)責(zé)人，定宏觀和長遠(yuǎn)戰(zhàn)略，充分發(fā)揮團(tuán)隊自己的能動性。這也就是我說的，隨著職級的提升，會更偏向管理多一些。

我覺得作為一個喜歡技術(shù)的新人，應(yīng)該還是從做技術(shù)開始，等到職級到了一定程度，再轉(zhuǎn)向管理。一個方面是較低的管理職級實(shí)際上發(fā)揮不了太大管理作用，所以在很多其他互聯(lián)網(wǎng)公司，在低級別，技術(shù)和管理是一體的，只是到上面才會逐漸分開。

高可用架構(gòu)：大家都知道您在OLAP和OLTP領(lǐng)域耕耘很多年了，是什么樣的契機(jī)讓您開始這兩個方向研究的？它們究竟有怎樣的魅力吸引您愿意花長時間去鉆研？

馬如悅：我研究生是在清華做ChinaGrid的，07年畢業(yè)有幸進(jìn)入百度去開辟分布式計算方向。那個時候，Hadoop開始火起來，所有的互聯(lián)網(wǎng)公司都在做。做了5、6年的離線計算平臺，當(dāng)時百度已經(jīng)比較成熟了。那個時候，遇到了很多新的業(yè)務(wù)問題，發(fā)現(xiàn)是Hadoop這種離線框架不好做的，需要類似大規(guī)模在線數(shù)據(jù)庫這種，所以自己就主動要求轉(zhuǎn)崗了，從一個幾十人的大團(tuán)隊接手了一個幾個人的在線數(shù)據(jù)庫小團(tuán)隊，開始走上了在線數(shù)據(jù)庫領(lǐng)域。在新的方向上，我們通過5年的時間，建立了百度新式數(shù)據(jù)庫團(tuán)隊，傳統(tǒng)數(shù)據(jù)庫團(tuán)隊還是有DBA團(tuán)隊在負(fù)責(zé)，百度新的數(shù)據(jù)庫技術(shù)基本都在我們這個團(tuán)隊。我們先后做了面向結(jié)構(gòu)化的在線數(shù)倉，面向文本非結(jié)構(gòu)化的搜索分析數(shù)據(jù)庫，以及面向事務(wù)的NewSQL數(shù)據(jù)庫。

我個人是一個偏向喜歡做前沿技術(shù)的人，所以只要有比較好的前沿技術(shù)，只要這些技術(shù)可能對業(yè)務(wù)帶來前所未有的改進(jìn)，就對我有無窮的吸引力。我并不崇尚那些極度高級和復(fù)雜的技術(shù)，我更崇尚那些可以帶來更大落地效果的技術(shù)。比如，隨著人工智能技術(shù)的進(jìn)步，我們現(xiàn)在也在轉(zhuǎn)向怎么利用機(jī)器學(xué)習(xí)來進(jìn)行更加智能數(shù)據(jù)分析的技術(shù)，比如AutoML技術(shù)，Augmented Analytics等技術(shù)。

高可用架構(gòu)：現(xiàn)在開源的比較知名的OLAP都有哪些？根據(jù)存儲數(shù)據(jù)的方式不同，OLAP可以分為ROLAP、MOLAP、HOLAP等等，您主導(dǎo)研發(fā)的OLAP系統(tǒng)屬于哪種類型？選擇這種類型是怎么考慮的？當(dāng)初是什么原因決定要自研的？

馬如悅：我們研發(fā)的Palo實(shí)際上是ROLAP的。但是我個人不喜歡將任何產(chǎn)品非得劃分為ROLAP、MOLAP或者HOLAP，這種被人總結(jié)成標(biāo)準(zhǔn)的條條框框，理解好了，可以指導(dǎo)你的工作方向，理解不好了，可能會限制你的思路。所以在Palo里，從來不會去說這個東西是MOLAP的，我們做得是ROLAP的，這個不合適，所以不去做。

百度的Palo都是根據(jù)自己的業(yè)務(wù)需求，和參照同行，比如Google的一些做法，去開發(fā)的，不是根據(jù)教科書去做得。Palo的分布式存儲引擎是自研的，查詢引擎是基于Impala做優(yōu)化的。Palo除了滿足業(yè)務(wù)性能要求外，主要追求的是簡單，就是開發(fā)、使用、理解都簡單。很多類似解決方案都復(fù)雜無比，比如依賴zookeeper，依賴hbase，依賴hdfs，依賴hive，依賴MapReduce等。而這些依賴都大大增加了使用和運(yùn)維的負(fù)擔(dān)，在在線系統(tǒng)中，這種依賴造成的各種問題實(shí)在是太多了。所以Palo當(dāng)時追求的目標(biāo)就是簡單有效。

高可用架構(gòu)：OLAP和OLTP場景有怎樣的不同？兩者的融合是否是未來的趨勢？您認(rèn)為融合的難點(diǎn)在哪？融合之后，將會對大數(shù)據(jù)領(lǐng)域產(chǎn)生怎樣的變化？

馬如悅：OLAP是面向分析的，OLTP是面向事務(wù)的，一般面向的業(yè)務(wù)需求不一樣。這一兩年，很多產(chǎn)品都大談HTAP的概念，所以現(xiàn)在又多出了一個HTAP的系統(tǒng)。

HTAP系統(tǒng)我個人認(rèn)為一定是未來的趨勢，分久必合，合久必分。但是這個需要多未來，就不好說了。很多產(chǎn)品大談HTAP，搞得好像這個時代就馬上到來一樣。實(shí)際上很多產(chǎn)品，一開始奔著是做NewSQL, 就是新一代OLTP領(lǐng)域去的，但是等做得差不多，出去談客戶，發(fā)現(xiàn)客戶對新的OLTP的需求不大，尤其是對新的不成熟的OLTP產(chǎn)品，在重要的業(yè)務(wù)上使用，沒有啥興趣。但是，發(fā)現(xiàn)在新的OLAP需求卻很大，那怎么辦？就談HTAP唄。所以現(xiàn)在業(yè)界大多談HTAP的都是做NewSQL出身的。是不是商業(yè)的噱頭咱先放一邊。從長遠(yuǎn)來看，隨著硬件技術(shù)，業(yè)務(wù)需求的轉(zhuǎn)變都可能對HTAP技術(shù)需求越來越大。所以我認(rèn)為HTAP是個趨勢。

但是，我十分不認(rèn)同，在解決實(shí)際問題的時候，大家為了追求趨勢而去采用HTAP技術(shù)。實(shí)際上很多當(dāng)前的業(yè)務(wù)和系統(tǒng)，OLTP和OLAP分離去解決，是最自然的，也是最高效和穩(wěn)定的，那為啥非得耦合到一起，并且可能容忍在某一個特性上的短板。HTAP技術(shù)我覺得可以作為NewSQL未來延展的一個方向去研究，但是遇到實(shí)際問題還是要綜合考慮，是OLAP/OLTP分離好，還是混合好。

高可用架構(gòu)：大數(shù)據(jù)發(fā)展超過10年了，大數(shù)據(jù)生態(tài)中各種組件層出不窮，比如ELK、Impala、Spark、Flink、Storm等等，您覺得出現(xiàn)這種情況說明了什么呢？這些組件有沒有您特別推薦大家使用的以及推薦的理由是什么？

馬如悅：出現(xiàn)大量的組件，說明這個領(lǐng)域還遠(yuǎn)未成熟，當(dāng)某個領(lǐng)域非常成熟后，就基本上會收斂成幾個穩(wěn)定的技術(shù)產(chǎn)品。也就是因?yàn)橛泻芏嘟M件，所以做集成方案是有前途的一個方向。

我個人現(xiàn)在比較傾向的是：離線使用Spark/H2O/Tensorflow組合，在線分析使用Palo/ELK，NewSQL大家可以關(guān)注一下Apple開源的FoundationDB。

高可用架構(gòu)：說到大數(shù)據(jù)就不得不說Hadoop。有人說Hadoop正在淪為日志處理工具，對此，您是如何理解的？有什么樣的看法？

馬如悅：我認(rèn)為Hadoop沒有不被Spark取代的任何理由。Hadoop能做到的，Spark都能做到，或者即將都可以做到。所以如果你是這個領(lǐng)域的新人，建議可以直接從Spark學(xué)起。很多公司都在使用Hadoop，并不一定說明Hadoop好于Spark，大部分情況是遺留系統(tǒng)，遷移成本巨大造成的。如果你能挑出一個Spark做得不如Hadoop好得點(diǎn)，不要轉(zhuǎn)向Hadoop，而是努力為Spark解決掉這個問題。

高可用架構(gòu)：最近幾年TiDB、Kylin等開源項(xiàng)目在大數(shù)據(jù)領(lǐng)域的應(yīng)用也逐漸流行起來，在您看來，他們都有什么樣的優(yōu)劣？解決了用戶怎樣的痛點(diǎn)？

馬如悅：TiDB和Kylin都是中國做得非常好的開源軟件，也讓硅谷的人了解中國人也是可以搞出世界級的開源項(xiàng)目的。TiDB的劉奇和東旭，以及Kylin的韓卿，我們都有交流，從他們那里學(xué)到了很多東西。

TiDB我更傾向于認(rèn)為是個NewSQL產(chǎn)品，主要是一個New OLTP的產(chǎn)品，可能是NewSQL叫得太多了，并且在TiDB的前期客戶中，更多人可能拿他用來做分析用，所以他們現(xiàn)在更多得是把自己定位為HTAP，畢竟叫HTAP的產(chǎn)品現(xiàn)在遠(yuǎn)少于NewSQL，哈哈。TiDB同學(xué)對技術(shù)的那種追求是令我羨慕的，所以致力于HTAP方向的同學(xué)建議可以投入他們社區(qū)研發(fā)，幫他們做到更好。

Kylin是一個New OLAP的產(chǎn)品，周圍也有很多公司在用，大家也可以試用一下。但是這里給Kylin提一個建議，就是Kylin還是依賴了太多Hadoop組件，而這些依賴讓Kylin的易用性會大大折扣。所以Kylin下一步可以不斷收斂內(nèi)聚一些，但是Kylin還是一個不錯的產(chǎn)品，大家都可以嘗試一下。

高可用架構(gòu)：容器引領(lǐng)了微服務(wù)潮流，在大數(shù)據(jù)領(lǐng)域的基礎(chǔ)設(shè)施、資源混合使用以及運(yùn)維自動化等方面應(yīng)用廣泛嗎？目前的現(xiàn)狀和可能的原因是什么？

馬如悅：AWS認(rèn)為容器和Serverless是這一兩年最火爆的技術(shù)。尤其是容器技術(shù)，在私有化部署產(chǎn)品時，更是上乘之選，直接解決了兼容性問題。AWS在容器技術(shù)方面，也在這1-2年先后推出了3款產(chǎn)品，可見其重要性。

百度也基本上從今年起，將所有的大數(shù)據(jù)計算和人工智能等計算全部遷移到容器平臺上進(jìn)行統(tǒng)一調(diào)度。

所以，容器當(dāng)前可能也有一些不好的地方，比如使用起來還是比較費(fèi)勁，對底層存儲掛載也都少許不好用，但是從長遠(yuǎn)來看，容器的大規(guī)模在IDC的使用基本沒有懸念了。

高可用架構(gòu)：您目前最關(guān)注的新技術(shù)有哪些？最有可能給大數(shù)據(jù)領(lǐng)域帶來變革的是什么？

馬如悅：我現(xiàn)在主要關(guān)注的就是機(jī)器學(xué)習(xí)、人工智能在數(shù)據(jù)分析的應(yīng)用，比如類似AutoML的技術(shù)。我們正在努力打造一款新時代的類SAS的數(shù)據(jù)分析產(chǎn)品。

高可用架構(gòu)：您此次參加GIAC，給大家?guī)砹耸裁礃拥母韶?？方便透露一下嗎?/strong>

馬如悅：此次主要還是想和大家分享一下百度云是怎么思考大數(shù)據(jù)平臺架構(gòu)的。