大資料現狀和未來展望--百度大資料主任架構師馬如悅訪談
阿新 • • 發佈：2019-01-10
馬如悅：我研究生是在清華做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，給大家帶來了什麼樣的乾貨？方便透露一下嗎？
馬如悅：此次主要還是想和大家分享一下百度雲是怎麼思考大資料平臺架構的。
我個人是一個偏向喜歡做前沿技術的人，所以只要有比較好的前沿技術，只要這些技術可能對業務帶來前所未有的改進，就對我有無窮的吸引力。我並不崇尚那些極度高階和複雜的技術，我更崇尚那些可以帶來更大落地效果的技術。比如，隨著人工智慧技術的進步，我們現在也在轉向怎麼利用機器學習來進行更加智慧資料分析的技術，比如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，給大家帶來了什麼樣的乾貨？方便透露一下嗎？
馬如悅：此次主要還是想和大家分享一下百度雲是怎麼思考大資料平臺架構的。