湯子楠：飛天、ODPS經歷了許多血淋淋教訓
阿里云飛天系統之上，提供了離線的結構化數據存儲和計算服務平臺——ODPS (Open Data Processing Service)，半結構化數據的實時隨機讀寫服務——OTS（Open Table Service），實時流數據處理服務——OSPS (Open Stream Processing Service)等等。通過這些服務，阿里巴巴內部或第三方都可以通過阿里云享受這些資源。InfoQ 采訪了阿里云事業部高級專家、云產品產品經理湯子楠，他介紹了阿里云飛天、ODPS 的演進過程，以及 ODPS、天池未來的發展和價值，以下為采訪全文：
InfoQ：湯子楠你好，介紹一下自己吧。
湯子楠：大家好，我叫湯子楠，我是阿里云的一名產品經理。簡單的介紹一下自己，我畢業后先在 微軟中國做了一段時間，做 Program Manager，國內翻譯成產品經理或項目經理，當時主要做前端產品。在 2010 年前后，我希望積累在后端的產品經驗，當時正好阿里云剛剛成立，我蠻認可阿里云的這種公有云服務的模式，希望探索云計算未來的發展道路，就加入了阿里云。 首先做飛天底層的產品經理，后來阿里巴巴成立大數據事業部后，我加入其中做了很多跟大數據相關的東西。最近回到阿里云開始負責云產品，像負載均衡，內容分 發網絡等產品。
InfoQ：阿里云在做 ODPS 這樣一個開放數據平臺，給第三方用戶提供計算和數據服務，這個平臺和飛天之間的關系是什么？我的理解是飛天更多是在基礎架構層面做支持，ODPS 在上層對用戶的數據和計算提供服務的接口，是這樣的嗎？
湯子楠：你的理解非常對，實際上 ODPS 和飛天都是阿里云飛天團隊研發的。飛天是一個類似操作系統的基礎平臺，它主要負責，在集群上將最基礎的數據存儲和計算的模型通過 C++ 的接口對外暴露出來，讓上層的應用基于飛天做更多的事情。阿里云在飛天上開發了很多產品，比如 ODPS，它是一個離線的結構化數據存儲和計算服務，主要是做海量的結構化數據的分析和挖掘。常見的使用場景，包括云端的數倉，云端的 BI 分析、日志分析等。除了 ODPS，阿里云還有其他基于飛天的產品，OTS 是半結構化數據的實時隨機讀寫服務；OSPS 是實時流數據處理服務。總的來說，可以把飛天理解成操作系統，上面的 ODPS、OTS 就像操作系統上的各個應用，這些應用分別滿足阿里云的客戶對于不同的使用場景的需求。
InfoQ：你剛才提到飛天用 C++ 來寫的。Hadoop 這套生態系統，更多是用 Java 實現的，為什么飛天選擇C++？
湯子楠：我們可以討論很多 C++ 和 Java 之間的區別，這兩個編程語言都有很多擁躉。可能很多人覺得，C++對于系統資源的控制更精準，Java 的編程模型可能更好實現。但在我看來，最直接的一個理由就是當年做飛天的創始人是一群 C++ 的 Programer，很自然的選擇了自己最擅長的語言來寫程序。
InfoQ：我們知道互聯網、云計算這幾年的發展速度是非常快的，飛天、ODPS 這樣的產品，在整個開發迭代過程當中有沒有遇到比較大的門檻，有沒有重新推倒重做的狀況？
湯子楠：這種情況在飛天和 ODPS 研發過程中是都有。阿里云剛剛成立時就在研發飛天，到現在四年多了，在這四年多走了很多彎路。我可以舉幾個小例子，實際都是蠻有意思的經歷，現在回想起來很好玩兒，但當時真的是血淋淋的教訓。
比如，當時飛天在做底層服務的時候，就已經考慮到未來上層肯定會出現很多像 ODPS、OTS 這樣的應用，在底層基礎存儲層方面做一些附加的模塊。對于結構化數據的存儲，也已經在核心系統層考慮這個問題了。當時的想法是希望能夠用一種存儲格式同時 解決在線和離線兩種場景，那我們知道實際上在線的優化方向主要是低延遲，離線更多是高吞吐，數據量要大，所以說這兩者的優化方向很難統一起來。但當時飛天 的工程師花了大量的精力去研究，怎么樣能夠把這兩者統一起來，這應該是研究性的命題了，設想了很多場景，怎樣通過算法或統一架構的手段讓兩者的代碼復用更 高效，但是從工程的角度來講，這件事情做的太早了。在產品發展的初期，可能更多應該考慮實際的用戶需求，同時還需要考慮團隊當時具有的工程能力。大概做了 三、四個月，很快做了決定，把這個團隊一拆為二，一部分人做離線，一部分人做在線。到今天為止，這兩個團隊已經是完全兩個方向。現在又開始有一種思路，把 兩個團隊合起來，原因是許多時候離線的場景需要去讀在線的數據，同時還有很多產品在線的數據，希望能夠沉淀到離線，做離線分析，所以說他們會有些交叉。但 現在再來做這種統一，跟最早想做的統一完全不是一種心態了，現在這種統一更加實際，這是一個例子。
另外，飛天的很多核心模塊，比如它的存儲模塊叫盤古，計算模塊叫伏羲，網絡通信模塊叫夸父，可能多的已經經過了三版左右的重構。在剛剛開始設計的時 候，我們沒有想到分布式的發展速度這么快，機群的規模增長這么多。記得我 2010 年加入阿里巴巴的時候，當時集群最大能力可以跑 30 臺機器，無論存儲、計算都運行的很好。但設計者并沒有考慮到，如果 30 臺變成 3000 臺或 30000 臺會發生什么，大概去年我們突破了單集群 5000 臺的限制，相比之前有一百倍提升。當到了 5000 臺的規模，就發現很多之前的設計這些假設已經完全不工作，被迫將一些核心技術模塊重寫。可能今天在單集群 5000 臺規模運行的很好，誰也說不準明年到了 20000 臺的時候，是不是還 OK。所以我覺得核心系統一定不斷的在迭代，不斷在重寫。現在很多飛天的創始人已經離開阿里云了，今天飛天的代碼可能跟他們之前寫的代碼相比已經面目全非 了，這應該是大規模分布式系統演變的必然趨勢，不斷重構，不斷的代碼重寫，來適應更多的應用場景和更大規模的挑戰。
InfoQ：阿里云提供很多不同類型的服務，包括服務于內部的業務和公有的服務，那如何做好系統平臺和應用模塊的測試，新業務不影響老業務，同時讓新業務快速的上線？
湯子楠：分布式測試有個很大的挑戰，你很難去模擬真實的情況。比如我們在單集群 5000 臺上線的時候，要做壓力測試，看一看當這個集群的資源利用率很高的時候，系統是不是工作正常，但這勢必涉及到能夠在把 5000 臺機器跑滿的測試場景。這樣的場景很難設計且不談，測試團隊也很難有機會奢侈的找到 5000 臺機器去真實的跑測試。所以要解決這個問題，大概是兩條路：
首先，在小一到兩個數量級的集群模擬更大的集群規模行為，是不是可以在 500 臺機器上模擬 5000 臺機器的行為。
第二，要求測試工程非常快速。比如，我們在 5000 臺規模的集群交付的時候，讓集群不歇，人歇。機器到位的時候，負責運維和采購同事，先給了測試的同事三周時間，他們可以在集群上把測試跑完。三周以后，集 群正式上線。在這三周內，測試的同事要把所有要做的測試以及上線所做的驗收全部做完。在這個過程中，如果發生了問題，開發團隊要去解決，當時的團隊采取三 班倒的方式，有些人白天跑完了測試，就可以脫離集群做分析，然后晚上回去休息。另一波晚上上班，把集群晚上的時間利用起來，盡可能最大化集群的使用率來保 證開發和測試團隊復用。
另外，現在我們也在做一些探索，如何在 5000 臺的分布式集群上，在線上跑一些測試，讓測試任務跟生產任務同時跑在一個集群上，并且通過各種各樣的技術來保證測試的任務不會影響到生產，在去年的幾次發 布中做了嘗試，效果蠻好。我覺得這種方式未來可能也是一個思路，當找不到這么大規模的測試集群的時候，干脆就在現場跑一跑。
InfoQ：我記得以前你曾經分享過 ODPS 上的準時計算，你怎么看像 Spark 這樣的內存計算框架。大家現在談 Spark，談內存計算談比較多，認為它是一個未來的一個方向，你怎么看？
湯子楠：我同意 Spark 是一個未來的方向，Hadoop 這個技術發展非常迅速，現在的應用場景也非常多，這兩年的 Hadoop China Summit 大會上看到越來越多的企業，甚至包括一些傳統行業都開始嘗試在使用 Hadoop。這也說明，Map Reduce 的這種離線的數據處理技術受歡迎的程度。但是，無論是軟件技術，還是硬件技術，包括我們的業務場景都在往前走，在這個過程中發現 Hadoop 有一些不足，以及可改進的地方：
第一，硬件成本大幅下降，我記得 2010 年的時候，我們的機器的主流內存配置大概是 24G，現在大概漲到了 128G，翻了 5 倍。有更低廉的內存可以使用的時候，是不是很多計算可以把它從硬盤把它遷移到內存當中去，因而獲取到性能的收益是非常客觀的。
第二，從業務場景來講，很多的業務場景已經不接受 Hadoop 這種分鐘級或小時級的離線統計，他希望能夠實時或準實時的看到統計結果。我舉幾個簡單的例子，比如淘寶的數倉每天擔負著對淘寶交易記錄做離線統計的職責， 統計出來的 BI 報表，第二天會供高管或運營人員來做運營決策。但像雙十一當天，一整天運營的同學都在密集的工作，他們需要實時的了解交易情況，包括在各個類目的分布。大 家都有印象，雙十一當天天貓的微博上會放出照片，一個很大的屏幕上面數字不斷的往上漲，這就是純粹的內存計算。所有前端數據來了之后，在內存中做匯總后直 接輸出結果，這種計算相比 Map Reduce 延遲大大縮短了，類似這樣的業務場景會越來越多。這就逼迫我們去思考，怎樣縮短數據采集、數據運行的時間，Spark 從出現到今天發展速度非常快，在阿里巴巴集團內部也開始有團隊去探索 Spark 可以怎么用，如何基于內存做計算，或者把內存當成文件存儲架構，ODPS 這個準時計算已經有一點點這樣的味道，但基本上沒有完全脫離 Hadoop 架構。
我們現在有一個團隊專門在做內存計算平臺的調研，希望未來完全脫離 Hadoop 架構，單獨設計一套純粹基于內存和網絡的計算模式，這樣的話，可能把這個海量數據分析的時間下降一到兩個數量級。
InfoQ：阿里會自己來做一套，還是直接用 Spark？
湯子楠：我們自己在做，同時我知道內部也有團隊在 Spark 上做技術調研和探索，因為自己研發的時間非常漫長，有時很多的業務團隊在技術選型的時候，會考慮業務要求的時間點，內部有合適的技術用當然更好，如果沒 有，開源如果能滿足要求，也是 OK 的。今天在阿里巴巴集團內部有 ODPS 這樣的自己開發的離線處理的平臺，同時也有一個很大的 Hadoop 集群支持了各種各樣的集團離線處理業務。在一段時間里面可能是百花齊放的狀態。
InfoQ：我們知道阿里現在有一個天池的項目，就是一個開放數據的接口，第三方可以通過這個接口訪問阿里內部的一些數據，做 一些算法或者推薦系統。從國外來看，像 推ter、Netflix 都有類似的針對第三方的接口。現在問題是，把數據開放給第三方，數據的審計怎么來做？對于一個普通用戶來講，我關心在淘寶、支付寶上的數據是不是會被拿去 他用，就是用戶隱私的問題。第二，從生態系統上來講，如何吸引第三方把他的數據上傳到這個平臺上去，讓天池的數據量更大，阿里巴巴也能夠獲益。
湯子楠：天池項目是技術發展部啟動的一個創新項目，最早的想法實際蠻簡單，希望集團內部的數據有更多的人來去挖 掘價值，可以應用于商業、科研很多方面，在科研、經濟學、心理學、數據挖掘領域可以有一些樣本數據做一些測試。因此，最開始設計天池的時候，希望面向高校 做數據方面的合作，實際上天池基于 ODPS 搭建，即底層是 ODPS 的計算平臺， ODPS 上提供存儲計算能力，并開放 API 和客戶端工具。在建設天池過程中有一個插曲，天貓想在內部搞一次算法比賽，起源是因為天貓對于線上的一些數據預測算法不是特別滿意，所以想看看有沒有可以 優化的空間。后來他們找到天池團隊，在天池平臺上做了這個比賽。天貓算法大賽動員了大概阿里巴巴內部幾百名算法工程師，組了一百多個隊 PK。他們拿到的是天貓內部的真實數據，預測的是線上真實場景，比賽持續了大概兩個月，最后的結果蠻鼓舞人心的。我們發現，排名前幾名算法的效果，可能比 天貓線上算法的效果還要更好。我們看到，當我們把數據開放出去，吸引那些懂數據，并樂意分析數據的人去對數據加工，就可以創造出很大很大的價值。因此，我 們希望把這種模式推廣出去，現在天池平臺就是在做兩件事情：
一方面，他們跟全國各地的高校合作，通過科研手段把阿里的數據利用起來。如果哪一天能夠有中國的科學家通過分析阿里巴巴的數據得一次諾貝爾經濟學 獎，那算是阿里巴巴為中國社會做出很大的貢獻，我們相信以阿里巴巴數據的含金量，這是完全可能的一件事，因為他解釋了很多在社會行為和商業購買上的規律。
另一方面，由于天貓算法大賽非常成功，技術發展部希望面向全國所有高校來搞一次大數據的競賽，現在已經進入到了預熱的階段，在 4 月到 7 月會正式開始。
回到剛才你談到的，數據開放面臨兩個非常大的挑戰，第一個是數據的隱私和安全問題，這是全世界所有做數據生意的公司都躲不過的一道砍。國外很多做大 數據的公司都非常重視這件事，包括 Google，非死book。在國內，隨著各個公司社會責任感的提高，以及消費者的隱私意識慢慢覺醒，國內的公司也開始慢慢的在重視這件事情。對于我 們而言，數據隱私和安全通過以下兩個方面保證：
第一，技術層面。我們要最大化的保證用戶數據在平臺上是安全的，所有的數據存儲是加密的，數據流通過程中是加密的，數據不能夠越權訪問，數據是不能 丟失的，不能夠泄露，不能篡改，也不能越權訪問。所有的這些都可以通過技術手段解決，這是一個很難的問題，如何在大數據的場景下解決安全問題，但這是可解 的。ODPS 在這方面也做了相當多的探索，目前 ODPS 上已經在跑支付寶的業務，支付寶是按照銀行的數據保密標準要求底層技術架構，這說明 ODPS 的安全水平已經達到了一個高度。
第二，數據流轉的商業模式，怎樣保證數據既能夠發揮它的價值，又不至于泄露，又不至于讓用戶覺得自己的隱私受到危害，這是相當難的問題。這也就是為 什么在 2012 年年底，阿里巴巴成立了大數據部門。但我們在探索數據交換業務是非常謹慎的，沒有像 推ter、Netflix 做的直接，他們通過簽屬授權協議后就把數據開放出去，讓第三方公司在上面直接做分析和挖掘。我們希望找到一條合適的道路，跟第三方數據公司和第三方數據分 析公司一起把數據利用起來，可能這個模式比較困難，我相信未來可能有更好的有商業價值的模式。
至于怎樣讓其他人把數據搬到阿里巴巴的平臺上來，這也是蠻有意思的一件事，阿里巴巴在談大數據的時候，經常把自己定義為數據交換平臺，我們更希望的 不是把我們的數據分散出去來掙錢，而是希望把我們的數據拿給需要數據的人去使用，并且把有數據的人也吸引到這個平臺上，讓數據變成一件流通的產品，方便更 多的人。今天在做這件事情的時候，一方面我們跟懂數據分析的人去談，讓他們基于阿里巴巴的平臺上構建更豐富的數據分析應用，提供更多的數據使用場景，這樣 可以吸引有數據的人來。另一方面，我們也在設計一些新的業務模式，讓第三方公司在滿足安全的前提下，讓他的數據在阿里巴巴的平臺上發揮價值。
這里舉一個例子，大概在去年，阿里巴巴的廣告部門做了一個叫做 DMP 的新業務，這個業務在美國已經有很多的公司在探索，比如像 BlueKai 這樣的公司，在國內還處在剛起步的階段。DMP 主要的使用場景是這樣的，今天的互聯網廣告大部分都是數據驅動，每當來一個客戶的時候，通過實時競價的模式把用戶的屬性告訴廣告主，估計用戶的年齡，性 別，來自什么地方，有什么喜好，廣告主決定是否把廣告投給這個客戶，這種時時競價的廣告模式的根本是基于用戶屬性的大量原始數據，很多人沒有這些數據，但 是他在做廣告的生意，也有很多人有數據，但并不擅長做廣告，DMP 構建平臺，讓那些有數據但不會做廣告的人，把數據拿給想做廣告的人使用，當數據的流轉產生了價值后，廣告主會對結果付錢，由數據的所有者和廣告方共同分享 數據的價值。
我們正在跟國內的第三方數據持有者談合作，現在已經應用到淘寶直通車廣告平臺里，這是商業模式上的探索，通過這種模式可以讓更多的人愿意把他的數據搬到這個平臺上面來。