阿里雲的MaxCompute數加（原ODPS）用的怎樣？

01-04

阿里巴巴最新推出了ODPS服務，請問下該項服務是基於什麼平台？怎麼運行？跟Hadoop有什麼區別？並對未來的交通行業產生什麼影響。

搬過來 墨跡天氣運維部經理章漢龍 一份技術分享：阿里雲ODPS實踐：墨跡為4億用戶提供個性化天氣服務-CSDN.NET

這個可能是目前對阿里雲ODPS最完整的體驗、對比報告。

---------------------------割-------------------------割------------------------------------割-----------------------------

墨跡天氣成立到現在5年多，已經積累了4億用戶，4億是什麼概念？13.5億中國人，每四個人中就有一個下載過墨跡天氣，4億的獨立註冊用戶數超過美國人口總數。

同時，在墨跡天氣上，每天有超過 5 億次的天氣查詢需求，這個數字甚至要大於 Twitter 每天發帖量。

墨跡天氣已經集成了多語言版本，可根據手機系統語言自動適配，用戶覆蓋包括中國大陸、港澳台，日韓及東南亞、歐美等全球各地用戶。運營團隊每天最關心的是這些用戶正在如何使用墨跡，在他們操作中透露了哪些個性化需求。

這些數據全部存儲在墨跡的API
日誌中，對這些數據分析，就變成了運營團隊每天的最重要的工作。墨跡天氣的API每天產生的日誌量大約在400GB左右，分析工具採用了阿里雲的大數據計算服務ODPS。

使用ODPS的邏輯流程如下：

流程介紹：

1.
在每個日誌伺服器上都安裝了Fluentd及ODPS數據導入插件。日誌數據通過流通道DataHub實時導入到ODPS；

2.
數據分析作業分小時級和天級任務。數據開發工程師通過ODPS Python SDK向ODPS提交SQL 分析腳本，將統計後的數據導入Mongo DB。報表系統直接對接Mongo DB；

3.
運營人員通過報表系統來查看用戶統計結果；

整個數據分析過程也做了很多優化。以下是幾點說明：

1.
導入工具Fluentd。Fluentd是一款優秀的日誌導入軟體。代碼開源，支持Apache License 2.0。Fluentd支持300多個插件，基本上今天的大數據處理系統，Fluentd都能支持。Fluentd還支持自定義插件，允許通過代碼編寫其它數據源和目標。使用配置簡單、靈活，底層引擎關鍵部分通過使用C語言類庫編寫，所以性能比較好。墨跡選擇了使用Fluentd向ODPS導入數據。

2.
時區數據的統一。
墨跡的伺服器部署在不同時區，日誌數據按天和小時兩級分區流入到ODPS表中，但統計作業是發生在北京時間。例如，對於2015年12月1日的數據統計是在12月2日凌晨來做的。由於時區不同，統計作業運行完畢後，仍有部分時區在12月1日的數據會持續流入1日的分區表中，這就會導致這部分數據在統計時落掉。

解決這個問題，在實施時將所有的日誌數據中的local時間按北京時間做了轉換，截止到北京時間12月1日結束時，所有數據流入1日的分區中。其它時區是1日的數據會流入2日的分區，數據會在第二天完成統計。Fluentd中Filter 插件可以完成這個轉換操作，配置非常簡單，如下面部分代碼：

& type record_transformer enable_ruby & Bjdatetime ${(Time.strptime(LocalDatetime,"%m/%d-%H:%M:%S,%L").gmtime+8*3600).strftime("%Y-%m-%d %H:%M:%S")} & &

3.
任務的調度。墨跡分析的作業每天和每小時都會執行。分析後的數據導入本地Mongo DB，報表系統接入Mongo DB來做展現。墨跡分析工程師在本地使用定時調度Python腳本完成這些流程。SQL 分析腳本可以通過ODPS Python SDK直接提交到ODPS上執行完，完成後將統計結果放到List 對象。通過Python Mongo Client 將List寫入Mongo DB。

墨跡天氣的這一流程之前是在國外某雲計算平台上完成的，需要分別使用雲存儲、大數據分析等服務，數據分析完成後再同步到本地Mongo DB中與報表系統對接。在遷移到ODPS後，流程上做了優化，EMR的工作省掉了，日誌數據導入到ODPS表後，通過SQL進行分析，完成後直接將結果寫入本地Mongo DB。

在存儲方面，ODPS中的表按列壓縮存儲，更節省存儲空間，整體上存儲和計算的費用比之前省了70%，性能和穩定性也提高了很多。同時墨跡可以藉助ODPS上的機器學習演算法，對數據進行深度挖掘，為用戶提供個性化的天氣服務。

1.墨跡天氣這麼好的示例才幾十贊，可見大家是多麼不關心這個事情

2.我曾經回答一個問題的時候說，哪天各大招聘網站上招etl工程師招的爆表了，odps才有機會，今天看來，機會還沒有來。

3.大勢沒有來，風口沒有來，odps做得再好也無所謂，做的再爛也無所謂

4.阿里搞ob和odps，最大的好處可能是為阿里培養了一批具有大型系統工程經驗的工程師，怎麼樣在人員符合zipf分布的情況下利用組織保障系統開發進度，怎麼樣找一個英雄程序員在細節的泥潭裡硬抗，怎麼樣通過大規模的測試保障系統穩定，在這些方面，odps都走在行業前面很遠，今天odps的工程師比天天用java寫網站的不知道高到哪裡去了。

最底層是Linux+PC Server，上層軟體是飛天，飛天是阿里雲09年開始開發的一款分散式系統軟體，主要提供分散式存儲和分散式計算的調度、編程框架。開發語言是C++, 2013年該系統在生產環境支持調度5000台機器的集群。

飛天比較有意思的是模塊的名字，都是從中國傳統的神話中選擇，比如分散式存儲模塊叫盤古，調度叫伏羲。

站在hadoop的角度看，飛天提供的功能和hadoop是類似的，在yarn之前，hadoop主要的編程模型是MapReduce，飛天的編程模型是一個有向無環圖，而且除了支持批處理任務以外還支持常駐的Service。實現的細節上當然完全不同，首先實現的編程語言飛天就選擇了C++。其他像安全、運維體系都有很大區別。

ODPS是在飛天之上提供的一套服務，功能包括SQL，基於java的Mapreduce編程框架，圖計算編程模型，一系列機器學習演算法的實現等等。所有的功能是以RESTful API的形式對外提供，所以從系統邊界上說，這層API隔離了ODPS平台和用戶的系統，和hadoop的區別也很明顯。ODPS設計之初就是為了對外開放，做基於互聯網的多租戶的公共數據處理服務，所以安全性在ODPS的設計和實現中具有最高的優先順序。

對於未來交通行業產生的影響不具備足夠的知識回答，我想大概可以從大規模數據處理能力對交通運輸行業的影響這個角度考慮。在加上ODPS方便了大規模數據處理能力獲取這個角度。

利益相關：阿里員工，前ODPS團隊成員

利益相關：阿里員工。

首先，討論和對比之前，所有的同類產品都應該先向hadoop致敬，向google那三篇論文致敬。

@shellc 的答案很細了。我再補充一些ODPS與同類產品的簡單比較。

ODPS與Google BigQuery、Amazon有Redshift和EMR的比較？

Google的BigQuery，Amazon的Redshift和EMR，可以認為是ODPS的類似產品。在國內，ODPS是首款大數據存儲和計算開放服務。ODPS和BigQuery的產品形態比較類似，比如都支持海量數據的存儲和計算，都支持SQL語法等。兩者的主要區別在於：

1）底層技術實現不同。BigQuery基於Google自研的Dremel引擎，而ODPS則基於阿里雲自研的飛天系統，兩者在存儲、任務調度、任務優化上有很多細節都不一樣。

2）BigQuery的主要應用場景是互動式BI分析，而ODPS的適用場景則廣的多：目前已經開放的SQL功能主要用於數據倉庫和日誌分析；後續還將開放UDF和Map Reduce，支持用戶編程的離線計算；ODPS准實時，支持互動式BI分析；ODPS流處理，支持實時計算等。同時，ODPS的數據授權體系功能更加豐富，使用更加靈活，可以同時滿足數據擁有者、數據消費者和數據分析者的需要，ODPS未來可以成長為一個基於數據的生態系統的底層平台。

3）BigQuery僅是一款產品，而ODPS則是阿里雲產品線的一部分。除了ODPS之外，阿里雲還有SLS、OTS等一系列大數據服務，組成一個綜合的大數據解決方案，滿足用戶在大數據領域的多項需求。

最後是廣告時間（求不摺疊）。我離開阿里巴巴創業了，團隊在招人，雲計算、大數據、分散式計算人才很合適，歡迎投簡歷，具體信息參考 GeneDock 也歡迎推薦，成功入職後獎勵推薦人iPhone或DJI大疆無人機。

親，這個問題雲棲君來解答一下。

在近期的2017杭州雲棲大會阿里雲大數據計算服務（MaxCompute）專場上，阿里巴巴通用計算平台負責人/資深專家觀滔為大家分享了阿里巴巴的大數據計算服務的進化演進之路以及MaxCompute近期的發展動向。希望可以解答您的疑惑。

他的分享主要圍繞以下三個方面：阿里雲大數據計算服務概述、阿里巴巴數據平台進化之路、MaxCompute 2.0 Moving forward 。

一、阿里雲大數據計算服務概述

阿里巴巴大數據計算服務MaxCompute的前身叫做ODPS，是阿里巴巴內部統一的大數據平台，其實從ODPS到MaxCompute的轉變就是整個阿里巴巴大數據平台的演化過程。所以在本次會著重分享阿里巴巴大數據在過去七八年的時間所走過的路以及後續技術發展大方向。

首先做一個基本的定位，大家可以看到下面這張圖是一個航空母艦戰隊。如果把阿里巴巴整體數據體系比作這個戰隊，那麼MaxCompute就是中間的那艘航空母艦，幾乎阿里巴巴99%的數據存儲以及95%的計算能力都在這個平台上產生。

每天有大概超過一萬四千名阿里巴巴內部的開發者會在這個平台上進行開發，也就是每四個阿里員工中就有一個在使用這個平台。每天有超過三百萬個作業在這個平台上運行，幾乎涵蓋了阿里內部所有的數據體系，包括支付寶的芝麻信用分，淘寶商家的每日商鋪賬單以及「雙11」的大流量處理都是在這個平台上進行的。MaxCompute平台有上萬台伺服器分布在多個不同地域的集群中，具備多集群的容災能力。在公共雲上，MaxCompute每年以250%的用戶量和計算量在增長。此外MaxCompute對接到專有雲平台上提供了幾十套的部署，這裡包括了大安全、水利等所有政府業務，也包括城市大腦項目，幾乎所有城市大腦項目的底層都是使用這套系統做存儲和大數據計算服務，以上就是對於MaxCompute平台的整體定位。

如下圖所示的是MaxCompute平台技術全景圖。其中最底層是計算平台，最下面是數據流入流出的數據匯流排，稱為DataHub，它現在也為公有雲提供服務。數據會通過DataHub流入到MaxCompute大數據計算平台上來，在MaxCompute平台上會與包括人工智慧平台在內的所有平台進行互動構成完整數據平台的計算體系。在這之上是開發套件，如Dataworks、MaxCompute Studio，其包括最基本的對數據的管理和認知、對於數據的開發以及對作業的開發和管理。針對於這樣的開發和基礎平台，向上提供的計算服務包括語音轉文本、光學文字識別、機器翻譯以及智能大腦這些業務類的產品。在應用層就包括了向淘寶、天貓等比較老牌的淘系產品以及比較新的高德、菜鳥網路以及合一集團等提供所有的技術服務，以上就是MaxCompute平台對內和對外的整體布局。

二、阿里巴巴數據平台進化之路

接下來分享MaxCompute平台在過去的七八年時間裡是如何演化的。在淘系建立之初，在2009年之前使用基本都是IOE的系統，當時阿里更加偏重電商系的系統，屬於垂直線的。當時每個BU都有自己的一套從上到下、從業務到平台的產品。2009年的時候，使用的資料庫基本都是Oracle，當時阿里巴巴擁有亞洲最大的Oracle集群，所以在那個時候戲稱為Oracle之巔，當時的計算規模已經到達百TB的級別了。然後發現隨著淘寶運算量的發展，也隨著用戶量每年以百分之幾百甚至上千的增長速率不斷增加，Oracle集群無法承接所有業務的發展，所以當時思考的第二個項目就是Greemplum。因為Greenplum與Oracle的兼容度比較好，所以當時想到在Oracle遇到瓶頸的時候使用Greenplum做第二條的基礎發展路線。

在阿里巴巴發展之初，各BU都以各自為戰的狀態發展，其實這也是各個公司在創立之初的普遍狀態。大約經過了一年多的時間，阿里巴巴又遇到了Greenplum的天花板，此時的數據量大概比Oracle擴展了10倍。但是此時發現Greenplum在百台機器之後就很難再擴展上去了，但是即便是百台機器的規模對於阿里這樣蓬勃發展的企業而言是遠遠不夠的。2009年9月阿里雲啟動，當時給出的願景是要做一整套計算平台，其包括三大部分：底層的分散式存儲系統——盤古、分散式調度系統——伏羲、分散式大數據存儲服務——ODPS，也就是現在的MaxCompute。

大概花了一年的時間，第一個平台開始運行了，當時的ODPS就作為核心的計算引擎在其中發揮作用。到了2012年，這個平台基本上穩定了，這時候開始做到數據統一存儲、數據統一的標準化和安全統一管理。當做實現了上述目標之後，在2013年的時候開始大規模的商業化。當時做了一個「5K」項目，也就是單集群突破5千台，同時具備多集群的能力，這種二級擴展能力基本上就標誌著阿里內部的數據平台的奠基基本完成。與此同時，因為在做這套產品時候，由於各個BU之間之前是各自為戰的，有很多的BU採用了開源的Hadoop體系，所以在當時有兩套體系同時存在，一套稱為雲梯1也就是基於開源體系的，另外一套叫做雲梯2就是阿里內部自研體系的。那時候阿里巴巴的Hadoop集群做到了亞洲最大規模，達到了5000台，能夠提供PB級別的數據處理能力。在2014年到2015年，因為有兩套技術體系並立，所以阿里內部做了一個決定就是將整個技術體系進行統一，所以啟動了「登月」計劃。而在「登月」的過程中必須要考慮幾個需求，第一個就是多集群的能力，第二個就是良好的安全性，第三個就是要有海量的數據處理能力並且需要具備金融級的穩定性。基於上述需求，阿里巴巴當時選擇了雲梯2系統，也就是今天大家看到的MaxCompute。在2016年到2017年，MaxCompute開始對內支撐所有的業務，並且也開始對外提供服務。多集群擴展到超過萬台，並且開始全球化的部署，現在MaxCompute在美東、美西、新加坡、日本、澳大利亞、香港、德國以及俄羅斯都部署了集群。

登月計劃 – 一個統一的過程

接下來分享「登月」計劃和為什麼選擇這樣的一條技術路線。正如上述所提到的在執行「登月」計劃之前，各個BU之間存在著大大小小數十個計算平台，這是業務初期的必然屬性。而在技術上最終出現了兩套體系，一套是基於開源的體系，另外一套則是基於自研的體系。其實這兩套體系在技術和架構上來講或多或少都有相互的借鑒，但是在技術發展線路上又各不相同，在數據存儲格式、調度方法以及對外運算介面上也是各不相同的。當時遇到了以下幾個問題：

擴展性差，在兩三年前的那個時候，Hadoop體系的NameNode，JobTracker，HiveServer等都還是單點系統，在穩定性層面上存在一定的問題。
性能低，在5K及以上的規模上引擎性能的提升有限，也就是在5K以下基本上可以做到線性擴展，但是超過5千台之後可能就會有問題。
安全性不夠高，這一點是非常值得關注的問題。因為整個阿里巴巴在萬人級別的規模上是一套標準的多租戶體系。所謂多租戶就是阿里有很多個BU，每個BU之下有很多個部門，每個部門之下還有組和員工，那麼每個BU以及每個部門之間獲取的許可權應該是不同的，對於如何在數據安全的前提下進行共享的要求非常高，對此基於文件的授權體系不能滿足靈活要求。
穩定性比較差，不能支持多個集群和跨集群容災。

並且當時代碼雖然開源但反饋回社區的周期很長，很多集群變成事實上的「自研」系統；這又進一步導致的版本不統一，各個集群無法互聯互通！當時出現的問題就是淘寶的數據天貓都無法使用，小微金融的數據其他的BU也無法使用，互相申請許可權非常困難，整個體系無法打通。但是大家都知道阿里巴巴不是依靠實體資產，阿里巴巴沒有商品和倉儲，內部最為核心的就是數據資產。如果在平台性的體系中，數據無法做到互聯互通和高效運轉，那麼就會對公司發展造成很大的危害。

所以阿里巴巴就經歷了這樣的一個「漫長」和「昂貴」的登月過程。在登月計劃中，阿里巴巴集團層面牽頭，其中有名有姓的項目大概有24個，當時的登月1號是阿里金融，登月2號是淘寶，這24個項目的「登月」總共歷時了一年半的時間，將整個數據統一到了一起。

為了保障「登月計劃」的順利實施，當時MaxCompute平台做了這樣的幾件事情：

保證能夠滿足當時Hadoop集群所能夠提供的功能，在性能方面至少不會比其他平台差。
在編程介面層面，需要讓編程模型等多個方面兼容。
提供完善的上雲工具和數據遷移/對比工具，使得可以方便地從Hadoop體系中遷移到MaxCompute上來。
由於不得不在業務進行中升級，和業務方一起做無縫升級方案，「在行駛的飛機上換引擎」。

在實現了統一之後大致有這樣三點好處：

打造了集團統一的大數據平台。「登月計劃」將阿里巴巴內部所有的機器資源、數據資源統一到了一起。因為數據具備「1+1&>2」的特性，所有的數據貫通之後，集群整體的利用效率、員工的工作效率以及數據流轉等方面就變得非常高效的。到目前阿里集團內部計算業務運行於MaxCompute集群上，總存儲能力達到EB級別，每天運行ODPS_TASK超過幾百萬。
新平台是安全的，同時可管理、能開放。因為阿里巴巴內部存儲的數據和其他的廠商並不一樣，阿里巴巴內部很多數據都是交易或者金融數據，所以對於數據的安全性要求非常高，比如同一張表中不同的欄位對於不同的用戶而言許可權應該是不同的，MaxCompute平台提供了這種細粒度的安全性。在登月的過程中，不僅將數據統一到了一起，還實現了數據分級打標、數據脫敏、ODPS授權流程、虛擬域接入在雲端查詢版等工作。
新平台具備高性能和全面的數據統一。隨著把數據統一到一起，阿里巴巴在管理平台上也做了統一化，比如統一的調度中心、同步工具和數據地圖等，通過這些將阿里的數據體系進行全面的統一。而且新平台因為經過了很多的業務錘鍊和梳理以及人員的整合，整個團隊在一個比較大的規模上可以投入到一個平台上做更好的性能優化和功能調優，所以在2014年存儲資源優化節約幾百PB，通過梳理，各業務團隊的作業數/計算量分別有30%-50%的下降，一些歷史遺留問題得到全面的清理。

三、MaxCompute 2.0 Now and moving forward

接下來分享當阿里巴巴具備了內部的統一的大數據平台之後，未來在基礎和業務上應該如何做。

MaxCompute 2.0 架構持續升級

在2016年杭州雲棲大會上，阿里巴巴發布了MaxCompute 2.0，那個時候推出了全新的SQL引擎並且提供非結構化處理能力，在2017年MaxCompute做了持續的創新和優化。如下圖所示，MaxCompute 2.0實現了很多的技術創新，最上面MaxCompute提供了DataWorks開發套件以及MaxCompute Studio；在運算模式上可以支持多種，比如批處理、互動式、內存以及迭代等。再往下在介面層面，今年會推出一個新的查詢語言叫做NewSQL，它是阿里巴巴定義的一套新的大數據語言，這套語言兼容傳統SQL特性，同時又提供imperative與declarative優勢。

在引擎層面，優化器除了可以基於代價還可以基於歷史運行信息進行優化。在運行時方面，將IO做成了全非同步化。在元數據管理、資源調度和任務調度方面主要做了兩件事，一個是做到了Bubble Based Scheduling，也就是當將所有作業數據連接到一起進行Bubble Shuffle的時候，要求上下游是完全拉起的，這對於資源的消耗是非常高的，而Bubble是通過做一個合理的failover 的Group在資源和效率上找到一個平衡點；另外一點是今年著眼於生態和開放性，可以和Hadoop以及Spark等集群做靈活的互動，這是今年在生態層面的發力。在底層，MaxCompute今年除了提供原始的文件格式之外還提供了Index的支持，提供了AliORC，它與社區原生ORC兼容，性能卻更高。此外，MaxCompute今年還開始做分級存儲，除了內存和緩存以外，還會在SSD、SSD的HDD以及冷備壓縮存儲上做分層存儲，今年其實在內部已經提供了超密存儲的機型，未來也會逐步地轉移到公有雲上來。

大數據計算 典型場景分析（從開發到上線）

下圖所示的是大數據計算的典型場景分析，這也是阿里內部大多數員工以及雲上的經常會接觸的事情。通常情況下，一套大數據體系的建立需要分成這樣幾個過程，需要從數據源到開發階段再到生產階段。首先，數據源可以是應用，也可以是應用的服務，也可能來自應用的log日誌。一方面可以將應用的信息通過log或者message的方式上傳上來，另一方面很多數據信息其實落在DB中，DB的binlog其實可以被採集下來同步到數據平台中。另外一部分數據源就是已有的存量數據。當擁有了這些數據之後可以通過主動拉取、手動上傳以及同步中心的方式將數據上傳到集群中來。之後就可以進入開發階段，開發階段又分為三個部分，第一個部分是數據發現，也就是究竟有什麼樣的數據可以用，通過IDE的方式做作業的編寫或者做數據的編寫。在開發階段提供了通用計算、機器學習、圖計算以及流計算等。

在開發完成之後進入到生產階段，在生產階段的Workload就分成3部分、一類叫做Workflow，每個月生成一份賬單報表就是一個典型的Workflow任務，其特點就是具備周期性，比如每天、每小時或者每個月，這種類型的作業通常情況下作業量比較大，但是周期性卻是可以預測的。再往下就是Interactive Analysis，也就是互動式查詢，大家可能某一天希望看到數據上的某些統計信息，然後基於這些信息做商業決策，這也許會寫到明天的某一份報告里，這種是與開發者做交互的，寫一個作業上去發現數據有問題再調整回來，然後來回做這樣的交互。第三點是基於時序或者流式的數據處理，這種處理比較典型的就是「雙11」數據大屏，它就是滾動的流式計算的典型特點，基本的生產場景就分為以上三大類。

這三大類場景的要求是各不相同的，在數據源層面，對於數據的上傳，當數據量比較大的時候，隔離流控是一個技術要點。同時當進入到生產階段，數據的上傳上載需要具備完整性的檢查，包括需要進行規則檢查的補充。當數據上傳變成常規形態的時候，每天都會進行數據上傳的時候就有可能因為系統、應用或者數據源的問題導致數據斷裂，這種情況發生之後就需要系統具備補數據的能力。而系統也需要對於開發階段提供必要的支持，因為開發階段通常是小數據量的，代碼和腳本的更新速度比較快，可能經常處於試錯的過程，所以需要系統具備准實時的能力、開發效率和Debug效率，這實際上是對人提出的要求。當進入到生產階段的時候，通常情況下作業相對比較固定，資源和數據量消耗大，對於穩定性的要求就比較高，系統需要提供系統級別的優化能力以及運算能力。以上就是站在阿里巴巴的角度看的從開發到上線的大數據典型場景的分析。

大數據計算 典型場景分析（從計算量和延遲的角度）

下圖所示的是一個從計算量和延遲的角度看的數據軸，從數據量上看，從100GB到10TB再往上，最高可以到PB級別，在「雙11」當天，MaxCompute平台處理了上百PB的數據。在延遲的角度，會達到非常低的延遲狀態。可以看到圖中的橘色斜線，其含義是當對於數據量以及實時性的要求越高成本就會越高，所以大數據計算的要求就是將這個軸一直向上移動，也就是能夠在更短的時間內處理更大量的數據的時候成本越來越低。

在作業分析來看，主要分成三塊，其中最典型的數據清洗、數倉建立以及報表類的作業等通常情況下是以小時和天為單位運行的，按照阿里巴巴的數據統計基本上20%這樣類型的任務會消耗掉80%的計算資源，這樣任務的特定就是基本上以定時任務為主，query是固定的，所以通常情況下運行效率比較高。而實時監控類型的作業就是典型的流計算業務，比如像監控報警、大屏廣播等。而互動式作業大致分成兩部分，一類是分析類的另外一類是BI類，BI類的意思是說大多數的人可能看不到Query和中間系統，只能看到BI環境比如像阿里雲對外推出的QuickBI，大家可以通過配置和拖拽的形式訪問系統，這種用戶通常是非技術人員，這對於系統的交互性要求比較高，因為其是在UI上進行工作的，同時對於這樣的工作一般有比較強的延時要求，一般是在秒級或者幾十秒之內完成這樣的作業，所以通常情況下數據量比較小，要求數據提前整理好。而交互分析的數據量處於中小級別，有一定的延遲要求。所以這樣不同任務對應的不同的技術優化方案，Data Workflow就偏向pipeline型的作業，提升運行性能和效率是關鍵，對於以開發類和BI類的作業為主的，作業量比較大佔大頭，但是整體資源佔用率比較低，對於這種類型開發效率和時序化是關鍵。今年在MaxCompute大數據平台的發展上，除了繼續提升整體系統效率以外，時序化和開發效率也是今年的重點。

大數據計算 互動式BI類場景分析

在這三種Workload中重點分享一下其中比較基本的BI類的作業。為了實現這樣的業務所以對於實時性有更高的要求，比如onlineJob的優化、熱表Cache、Index Support等，還要有更優的查詢計劃、運行時的優化、生態連接、存儲格式的進一步提升，需要在數據上支持Index使得在進行運算的時候可以將數據聚集到更小的規模上去，以上這些都是相關的優化。

如下圖所示的是OnlineJob的基本設計思想，OnlineJob主要是針對中等規模、低延遲的互動式場景，並且提供了可靠的服務，目前在阿里巴巴內部60%的作業都以這種方式來運行。這個模式主要使用了這樣的幾點技術：

進程常住（以服務的形式Stand by），進程隨著作業完成之後不銷毀，一直處於等待狀態。
進程可以做到作業間復用。
網路直連，避免落盤。
事件驅動的調度方式。
基於統計和歷史信息的自動切換，用戶不感知。

下圖所展示的是互動式BI類場景下一個優化的例子。傳統基於MapReduce的方式拉起多個Mapper做Shuffle的時候數據會落到磁碟里，然後再由下面的Join去讀取，中間是割裂的，需要進行一次磁碟的數據交換，而MaxCompute的方式是做網路直連，這樣的好處是不用等到第一個Session做完，第二個Session就可以啟動，而這樣同時也會帶來一個壞處就是當failover的時候Group就會變得很大，所以需要做的額外工作就是在內存中及時地進行Checkpoint，這個Checkpoint也可以做到SSD上或者另外一台機器上，這樣的方式既提高了效率也降低了延遲並且能夠保證failover Group不失效。

MaxCompute今年與Intel進行了合作在2017 BigBench新的大數據標準上做了評測，這個評測不再是簡單地進行Sort，它一共具有30多個Query，這裡面包括了基本的SQL Query以及MapReduce Query以及機器學習的作業，其評測的標準除了規模以外也會關心性價比。目前MaxCompute是全球第一個將這些Query從10TB做到100TB級別的引擎，這樣的能力也是基於阿里內部龐大的數據量的錘鍊獲得的，其次MaxCompute是首個達到7000分的引擎，第三點是MaxCompute性價比的優勢，我們是首個基於公共雲的服務可以跑通整個Query的服務，總體而言費用也是非常便宜的。

為什麼選擇MaxCompute作為大數據平台

為什麼選擇MaxCompute作為大數據計算平台呢？在商業層面來講，有以下幾點優點：

MaxCompute是一個開箱即用的系統，大家完全不用考慮系統的規模問題。
MaxCompute有很多性能層面的評測和優化，可以實現性能和性價比的最優。
MaxCompute基於阿里巴巴內部的非常豐富的安全體系保障多租戶情況下的數據安全。
MaxCompute可以支持多種分散式計算模型。
MaxCompute支持上雲工具，包括社區兼容和生態鏈。

從整體流程來看，如果用戶的數據已經在阿里雲上了，那麼就可以非常容易地通過多種形式遷移到MaxCompute上來。如果數據在線下，可以通過專線或者VPN等形式在已有的數據集上通過各種同步工具遷移到雲上。在雲上可以通過數據集成和大數據項目的開發工具進行開發。針對普通的數據集成可以使用Data IDE以及專門的插件進行開發。當進入集群中使用平台做數據計算服務的時候，可以非常方便地實現與機器學習平台的聯動，也可以和阿里雲的推薦引擎、報表分析產品工具等緊密地結合在一起。

原文鏈接

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎

好愛墨跡天氣，一天要打開4、5次，據我所知，墨跡好像之前在用aws~

我也要評價，最近一周在搞ODPS的MR，尼瑪的，文檔和代碼不匹配啊，看到網上人家的各種「下載SDK，run wordcount，so easy」，我都懷疑自己智商問題了。後來就非要搞，那真是瞎貓碰死耗子一樣的調試，最後發現：SDK中的例子根本就不對。。。。。。。

後來將MR放到ODPS上跑（之前是本地local模式），又是一堆問題，繼續開啟「瞎貓碰死耗子」模式，一點點猜，一點點消除bug，後來終於run通了，瞬間感覺自己高大上了！但又一想，尼瑪，這ODPS的開發和文檔的人是不是有仇啊，要不就是和用戶有仇。

給視頻教材可以的吧

抄hive又不抄完整

沒在外部用過，內部用的web端挺好用的，數據開發，測試，發布，數據流，數據許可權管理都很好用，支持python，java的udf，可自己上傳第三方python庫。支持一些機器學習演算法，雖然不多，但還算夠用！幾百G的數據分析任務比較輕鬆。最多的時候跑了十幾T的數據速度也不是特別慢。沒接觸過其他的類似產品。

不好意思，我要來吐槽了。

之前在前公司的時候經常需要和ODPS的童鞋打交道，ODPS的童鞋都挺好的，當然某負責開發老大沒接觸過，不好評價，但從某些行為上看，還是算了。

另我震驚的是，有次幫一位用戶調試一個ODPS上MR的問題，那位用戶的代碼裡面依賴Hadoop 2.0，代碼很簡單，但運行時拋出的異常就在Hadoop HDFS的一個類裡面。我在HDFS的代碼裡面不斷試呀試，嘗試重新打不通的包試圖跳過所謂的ODPS 沙箱對HDFS的兼容問題。但發現很奇怪，就是錯誤一直是一樣的。後來把ODPS 運行MR的Classloader的所有依賴都打了出來，發現竟然有Hadoop 0.19的jar。瞬間震驚了，ODPS為啥會依賴 Hadoop 0.19，問了ODPS的開發童鞋後，他們說就是會依賴。

其他各種坑爹的問題就不說了，反正在前公司用ODPS的時候經常半夜被報警吵醒，已經習慣了。幾天都不收到報警都感覺怪怪的。

此外某廠最擅長的是搞個大新聞，比方說5k，5k+之類的，然後宣傳多牛逼多牛逼，但是實際上呢？為了表面上的光鮮後面需要多少開發童鞋來擦屁股，某些人的KPI上去了，但這些人你考慮過後面接手的童鞋需要迫不得已最後只能重寫，同時又要考慮之前已暴露出去不成熟的介面設計帶來的兼容問題嗎？

另外ODPS需要比雲梯1多幾倍的機器，多幾倍的運維，多幾倍的測試，多幾倍的開發有人算過嗎？雲梯1的運維只要1個人，ODPS呢？不過沒事，某司有的就是錢，像OceanBase之流這種要耗費多少倍機器才能撐住支付寶xx分之一流量的東西都可以到外面到處宣傳多牛逼，為啥ODPS相比其他東西已經這麼靠譜的為啥不能用呢？

可以