摘要：本文從馬力作為功率衡量標準為切入點，介紹了大資料領域的計算力衡量標準TPCBB以及MaxCompute2.0在Big Bench上的卓越表現。同時詳細地分享了取得優異成績背後的產品在最新有哪些進展，幫助大家全面的瞭解MaxCumpute2.0。另外，對於共有云使用者非常關注的-資料安全話題，阿里巴巴通過邏輯隔離/資源隔離/執行隔離機制，保障了資料安全，同時實現了安全的資料交換與共享。
演講嘉賓簡介：
雲郎，MaxCompute資深產品專家
以下內容根據演講嘉賓視訊分享以及PPT整理而成。
PPT材料下載地址：click.aliyun.com/m/100000306…
視訊地址：edu.aliyun.com/lesson_1010…
產品地址：click.aliyun.com/m/100000306…
本次的分享主要圍繞以下四個方面：
一、背景簡介
二、TPCBB
三、MaxCompute2.0演進
四、資料安全
一、背景簡介
最近在看一些紀錄片，從這裡面受到很大的啟發，就是它從很多切入點將我們人類的歷史真實的再現出來了，在這個過程中我發現在人類的大歷史中很多東西都是相通的。我想起來我們們國內一位大家魯迅說的話“治學要先治史”，通過學習歷史，從更深層次上有更多的碰撞，甚至可能上升到哲學的層面，或者文化的層面。所以說搞大資料不可怕，可怕的是搞大資料的還要搞文化。
大家有沒有看過一個紀錄片-人類大歷史，它拍了幾十集，其中有一集就是講馬的變革，馬對人類整個人類歷史產生了什麼樣的影響？小時候學歷史有四個字印象比較深，就是胡服騎射。下圖中可以很容易想到這是成吉思汗的鐵軍，另外我們對西方的文明和文化也比較熟悉，提到羅馬，看到白袍子的時候可以看到貴族一般穿著很白很白的袍子。在這個紀錄片裡面，古羅馬人的穿著變化就如下圖的三個人，逐步演變成三個人都穿褲子，之前都是穿袍子。那麼產生的影響，第一個，人類因為馬穿上了褲子。第二個，不管是西方的羅馬帝國，或者是說我們的成吉思汗的帝國，馬起到了很重要的作用，它創造了東方和西方的帝國。同時馬決定了疆土，所以馬對我們產生了很重要的影響。
整個地球上有6600萬個物種，在這麼多物種裡面為什麼馬成為了我們人類的最重要的朋友呢？任何事情我們都有很多選擇，為什麼最終人類會選擇馬呢？天上飛的昆蟲，鳥類很多，是不是可以把它們訓練好呢？但問題是它們體量太小，它無法承擔人類的重量。第二個，獅子老虎能否訓練呢，首先它們很難馴化，另外它們都是肉食動物，吃的比人類還貴，無法飼養。第三類，大象可以表演，很聰明，那麼大象為什麼不行，因為它體量太大，要把它馴化成大小合適，時間上要花很長很長。最終，只有馬結合了我們想要的幾方面的優勢，第一個馬有力量，第二個馬的脾性好，第三個，最最重要的就是速度。這是馬能成為人力最重要朋友的幾點原因。
最早的時候，火車被叫為“鐵馬”，小汽車最早發明的時候也不叫car，它叫無馬馬車。到今天，我們做火車，飛機，汽車等，對功率標準的度量叫做“馬力”，1公制馬力=0.735千瓦（kw）。通過人類大歷史，我們知道了馬力出現的原因，以及馬為什麼會成為我們的朋友。
二、TPCBB
那麼在大資料領域，我們怎麼樣去定義它的度量衡呢，作為計算平臺，我們怎麼樣去評估計算力呢？
在最近幾年，我們跟國際上很多標準化的組織做了很多大資料方面的benchmark測試，包括最早做sort bench，TPCH，TPC-DS，然後在去年做TPCBB（big bench）。到去年我們發現TPCBB才是衡量大資料計算力的標準。大資料這裡面要考慮到資料的種類，有半結構化的，結構化的，以及非結構化的資料，這些都要在場景裡面有。另外在分析的場景裡面，我們要包含普通的建模，如靜態的建模。還有資料的分析和挖掘。還有要做Reporting，因為做報表和靜態分析的SQL寫法又是不一樣的。這是要基本的三個場景。對於查詢的型別而言，僅僅有SQL的，做機器學習，自然語言處理，通過標準語言，還有流計算。對於做大資料來說，整個處理的資料，作業，技術要從以上幾個角度面面覆蓋到。
這個測試案例集包含30個，它完整的覆蓋了不同的資料型別，不同的技術，不同的查詢型別。大家都可以下載到這30個測試集，然後看怎麼去做TPCBB。在TPCBB之前是TPC-DS，它在很多面向OLTP場景測試基礎外，把我們的benchmark的場景覆蓋到了OLAP，就是聯機分析的場景。然後TPCBB就進一步的從OLAP延伸，擴充套件了日誌檔案，機器學習等等大資料所有的特徵。這30個測試場景完整的覆蓋了我們對大資料計算層面的全部的訴求。這裡面很重要的一點是最大程度代表了真實場景，結果更接近上生產後的實際表現。很多情況下，PB，EB的量級是常見的，目前官方網站上有1TB，3TB，10TB，30TB，最大的規格是100TB。
去年阿里雲在北京的雲棲大會上，受到一個靈感，跟手機一樣，MaxCompute是不是也可以跑個分。在去年做了一個現場跑分，當時呼叫了北京，深圳的叢集，北京的跑得很好，下圖是從三個緯度得出的結果。資料集是100TB，首次測試就用了最大的規模。第二個表示每分鐘能跑多少任務，我們跑的全球最高8200QPM。還有第三個是成本，達到了最低的$354.7/QPM。所以MaxCompute在資料的容量，效能和價效比上全面的得到了突破。我們找到了大資料的衡量標準，同時也在不斷的做優化，期望能得到更多的突破。
三、MaxCompute2.0演進
在計算力得到突破的背後，我們都做了哪些工作。其實MaxCompute在阿里阿巴已經有十年的歷史，這十年中並不是一成不變的，從最早開始基本滿足阿里巴巴集團內部業務，然後能替代Hadoop，進而成為真正的資料的計算中臺，基礎設施。在阿里巴巴，99%的儲存資料，95%的計算都是跑在MaxCompute上的，我們來看怎麼樣演進的。如下圖，近期重點優化的內容大家已經可以看到，那可能沒看到的是我們最近在做的索引支援，如果MaxCompute深度使用的話，這方面的優化會帶來非常大的幫助，在效能，成本，全盤掃描等方面得到極大的優化。包括資料組織結構跟ORC的相容，因為大家知道不同資料組織結構和ORC在儲存的壓縮比和效能上是有一定平衡的。所以在這方面我們會挑選最好的資料組織方式，很快可以看到給大家帶來的優勢，最終的體會就是MaxCompute更便宜了。另外我們在語言層面，NewSQL的優化，以及優化器，語言的覆蓋程度上有了全面的優化和升級。從2.0上線差不多有快1年，這個過程非常漫長，直到5月份才把原先2.0上試用的開關關閉，真正的面向全網開啟了。
下圖是在MaxCompute上支援的作業型別，從去年開始我們開始思考怎麼樣和生態進行結合。也就是說在資料只有一份的情況下，怎麼樣支援更多的任務型別，在這個過程中，不用對資料進行搬家，不用多一步的copy。資料在project級別是達到共享的，在這個之上我們整合聯合計算平臺支援更多的作業型別。在這裡可以預先發布的是我們會支援實時互動式分析作業，也就是說表的資料量比較小的情況下，我們可以秒級響應結果，叫做“閃電（Lightning）”。第二個是我們會支援Spark的作業型別，Spark可以直接訪問MaxCompute的表，而不用來回匯入匯出，搬遷。這樣我們可以達到聯合計算平臺的目的：在統一的資料基礎上，支援更多作業型別，滿足更多的計算場景。
在SQL方面的優化包括編譯器的優化，支援複雜資料型別等。整體做的工作圍繞提高易用性與開發效率，提高相容性，和降低遷移成本等三個方面，從開發者的角度做的優化。
SQL得天獨厚的是它可以宣告，寫出來的東西大家都可以看得懂，不用去翻程式碼就可以知道要解決什麼問題，但在這個過程中它失去了一定的靈活性。那麼通過Function這種函式的形式，通過Java函式，通過Python函式的形式將兩者之間做更好的結合。也就是說SQL加上Function，在保持宣告的簡化性上以及複雜業務的支援上達到最完美的結合。在Function方面，MaxCompute2.0上也推出了更多的內建函式，通過函式提高複雜業務邏輯的方便程度。
那麼怎麼樣處理非結構化的資料，在阿里雲上非結構化的資料都存在OSS上，裡面存了檔案，圖片，視訊等等。在阿里雲上半結構化的資料存在TableStore上。這是阿里雲上兩個最重要的資料來源。在這邊定義一個外表，把OSS作為非結構化的資料來源，還有TableStore作為半結構化資料來源，直接Select來操作非結構化和半結構化的資料。因為在OSS和TableStore上都是通過API，這邊提供新的資料庫的方式，進一步降低非結構化資料操作的成本和開發的便捷程度。所以外表非常有效的補充了MaxCompute的計算場景和資料的範圍。
效能一直是阿里極致追求的，可以看到我們每年都在不斷的努力，持續的優化效能。MaxCompute2.0的效能提升了一倍，當大家每天晚上12點開始跑作業的時候，我們不希望到第二天9點才跑完。如果我們提升一倍，一層，二層，三層表的計算在早上5，6點跑完的話被業務同學找的機會就小一些了。所以說效能在離線作業中是非常非常關鍵的。還有排程量加大，跑幾萬作業，每天晚上堆積，怎麼樣能減少這個量，所以這一點上效能也是非常重要的。
因為阿里在做計算引擎，在工具方面Studio有很多新的特性。並且Studio釋出的非常快，它是基於IntelliJ平臺，為MaxCompute定製構建的IDE。
還有命令列的釋出，很多管理人員會喜歡非常高效的黑屏，操作命令，授權，管理資料。我們命令列也在不斷的釋出新的版本，大家可以根據不同的角色選用不同的工具。比如開發者可以用Studio，管理者推薦使用客戶端的方式做日常管理。
Logview是一個共享的服務，深深被使用者打動的是說終於不用從很多的日誌裡面搜下發的任務相關資訊，一個任務釋出完之後，我們會推給他一個連結，開啟之後需要的所有相關資訊，上下文都會完整的打出來，這裡麵包括常見的全盤掃描，資料清洗等等所有關於效能方面的問題通過DAG圖，通過任務可以詳細的進一步分析，定位，診斷。經常有情況是下發的任務很大，需要同時幾千個核計算，其中只要有一個跑得慢，整個拉慢了作業，我們可以通過Logview進行調優、診斷。
我們推出PyODPS，大家可以用它來以非常簡單的開發方式來排程非常複雜的計算。同時PyODPS，也就是Python的SDK可以很方便的跟Pandas DataFrame整合。這樣可以得到很高的開發效率。
另外還有R，我們認為在國內R應該有更好的推廣，所以我們支援了RODPS。
還有JDBC，現在大家用的很少，大家大部分通過SDK訪問，那麼大家也可以通過JDBC，進一步的和第三方整合。
還有我們ETL工具整合中，開源了很多專案，包括Flume外掛，OGG外掛，Sqoop，Kettle外掛，還有Hive的Data Transfer。我們都是通過這一套機制開源了很多專案，通過下圖連結，可以做ETL工具的整合。
在網際網路公司內，包括最早加入阿里時，一個很明顯的感受是都不願意記文件，但是跟客戶溝通之後發現看不到程式碼情況下，文件是作為長期溝通的東西。我們作為產品在這上面也做了很多工作，在雲棲社群有MaxCompute葵花寶典，我們關注的不僅僅是技術，還有工具，文件，傳播等方面也做了很多工作。
四、資料安全
資料安全用於都是首要的問題，沒有安全就沒有云計算。這個問題在產品經理角度來看永遠都是第一的，任何蛛絲馬跡的安全問題一定是最優先要解決的問題，資料安全就是身家性命。在4月27日，Hadoop Yarn遇到一個安全漏洞，阿里有一個很強大的安全部叫雲盾，也給出了很多安全建議，其中有一條是說阿里雲的MaxCompute可對Hadoop漏洞免疫。阿里雲的MaxCompute在公有云上執行這麼久，我們的資料安全是零安全事故。
我們是怎麼樣做安全的，下圖是我們的資料中心，每次要開一個Region。下面來看看MaxCompute特別的安全機制，首先在邏輯層，MaxCompute是標準的Severless服務，也就是說它是無伺服器的雲服務，這個叢集裡面通過租戶隔離。之後做邏輯隔離，裡面最大的隔離程度是project，在project裡面按照表，按照列做更細粒度的授權控制。所以邏輯層非常細的隔離從而確保模型是足夠的，而不是說開放出了檔案系統。在資料不能被別人拿到，偷走的情況下，一旦作業執行起來，它要進到記憶體裡面，進到CPU裡面，這時候該怎麼隔離呢？所以還需要資源的隔離，當每個UDF調起來之後，都會把它放到獨立的資源池裡面，一個隔離的資源環境裡面執行，確保資源方面和執行時候記憶體的安全。所以整體來說，雲的安全不僅有多租戶就夠了，要從邏輯層面，資源層面，和執行層面全面的進行隔離，確保每個租戶在共享之間達到安全可靠。
另外資料僅僅有安全是不夠的，安全和共享一定是結伴而來的，所以通過邏輯機制不但做到了安全，同時也做到了安全的資料交換和共享。這是我們想要的，並不是說絕對的安全，什麼都不發生，那資料一定是死水一潭。
最近我們和Forrester也有合作，Forrester一直在做雲上評測，我們這次MaxCompute，DataWorks，以及推的阿里雲的雲上資料倉儲解決方案，被評為第一象限，然後非常榮幸得到了第二名的排名。第一個是AWS，第二個是阿里巴巴，第三個是Google，第四個是Microsoft，以及後面的很多。這個過程中也在思考他們是怎麼認識當前雲上資料倉儲（CDW,Cloud Data Warehouse）的，分為三類，第一種是標準的多租戶的CDW，第二個是獨立專享的CDW，還有一個是託管的CDW。這三個差別非常大，第一類，如MaxCompute共享叢集，還有BigQuery也是Serverless。專有的是說整個大的裡面完全給出一塊，所有資源都是被鎖定的，不可能被共享，只是邏輯上做了資源的劃分。還有託管的，如果把虛機當作物理資源的話，在那個層面就劃分出來了。
另外也從不同角度做出全面的判斷，包括自助服務，彈效能力，自動升級，資料載入能力，解除安裝能力，混合雲，資料復原等等。
回到最開始的故事，路遙知馬力。每個人都有資料帝國的夢想，怎麼樣去擴充套件疆土來決定帝國半徑的大小，選擇什麼樣的千里馬非常重要。我們非常希望MaxCompute成為大資料旅途上的“千里馬”。MaxCompute努力的方向仍然很樸素，回到初心，我們希望能更開放，有更好的生態，更快更經濟，然後更簡單更易用，同時更穩定，能夠日行千里夜行八百。從馬力到計算力，思考更多，也希望大家能選到心儀的大資料的千里馬，讓每一位的大資料歷程跑的更遠，帝國建的更加強大。