阿里雲的大數據平台「數加」厲害在哪裡？
阿里雲發布全球首個一站式大數據平台「數加」
看了直播，有一些產品覺得挺牛逼，但講的並不是很清楚。想知道，這個平台的技術優勢有哪些，對於我們數據民工有什麼幫助。這個是數加的官網：首頁 - 數加平台
利益相關：阿里雲離職員工，前數加團隊技術負責人以下問答的內容大部分首發於袋鼠雲公眾號：＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
阿里雲在雲棲大會上海站的主題是DT World，這是一場規模宏大的大數據產品的發布會。發布的近20款產品， 幾乎都出自阿里巴巴一個存在已久的團隊：數據平台事業部，從2015年初開始變成了阿里雲數據事業部。這個團隊存在有多久？可以說比阿里雲本身還要久。這個團隊最早和DBA在一起，負責人是淘寶的第一位DBA七公，後來DBA歸屬運維，數據平台則在七公的帶領下迅猛發展，底層的平枱曆經多次升級，集群規模也從最初的4個節點Oracle RAC到20個節點Oracle RAC，再從數百名到數千台Hadoop，直到目前的數萬台ODPS，並且在CDO時期整合了當時集團各個BU最強的一幫大數據人才，成為了承載集團大數據夢想的數據公司。這中間的故事，幾個團隊的糾纏不休，幾個項目的驚心動魄，估計講個幾天幾夜都毫無尿點。
還是略過歷史，回到數加吧。前面說到數據平台事業部是承載集團夢想的數據公司，這個夢想是很遠大的，就像某年年會的口號說的，是星辰大海。下要做好大規模計算的分散式平台，中要做好集團數據人的開發平台，上要挖掘集團數據的商業價值，三路大軍浩浩蕩蕩，場面頗為壯觀。但細看之下，卻好比段譽同學通過北冥神功吸收了好幾股真氣，在沒有融為己用之前，真氣亂串導致偶爾是神功蓋世，偶爾是武功盡失。
直到2015年初，獨立山頭的數據平台事業部，變成阿里雲旗下數據事業部，名字相差不多，但其實角色發生了很大的變化。阿里雲總裁孫權同學對新的數據事業部提出了內部創業的想法，希望將過去幾年主要為集團內提供服務的大數據平台能夠正式全面的對外商用，並通過內部的創業工作室模擬外部客戶來打磨平台。這是一個很大膽的想法，對於大部分都是技術人員的數據事業部來說，不啻於一場大革命。從15年4月份開始，數加業務團隊、數加技術團隊和內部幾個創新工作室相繼成立，並搬到了當時還沒有什麼人氣的雲棲小鎮辦公。我也是這個時候開始正式負責數加技術團隊，有幸和一群飽經磨難的數據同學一起感受了一段內部創業的過程。
從一開始，我就把數加定位成大數據業務平台。在數加之前，集團內部實際上已經有兩個大數據的平台，一個是面向集團內部的在雲端，另外一個是面向外部電商場景的御膳房。這兩個平台的底層技術組件基本是一致的，2014年底的5K+項目也致力於讓兩者的底層完全統一，內部稱之為一個Base，多套部署實例。既然已經有一個對外的實例了，那麼數加做為業務平台，是基於已有的御膳房實例來構建，還是單獨再部署一個實例呢？這是要做的第一個決定。從技術上來說，當然應該選擇基於已有實例來做，這樣可以輕裝上陣。但實際情況是御膳房針對電商場景做了比較多的業務邏輯封裝，有點類似於聚石塔在電商場景下對阿里雲的封裝。這種封裝在電商場景下是合理的設計，但要面向通用的雲計算和大數據場景，就有很多不盡合理的限制，甚至在最底層的租戶模型上，當時也有一些設計衝突。
所以我們做的第一件事情是重新梳理租戶模型，在此基礎上部署了一套新的Base實例。現在回頭來看，這一年能夠快速的把數加平台搭起來，能夠在這次DT World上順利發布，最初的決定是對的，省去了很多的依賴和扯皮，並且從一開始就把租戶這個最核心的依賴做對了。但數加是顆尚未發芽的種子，面對已經有一顆樹開始抽枝散葉的情況下，這是非常不容易的，這中間至少給兩位CXO級別的老闆寫過郵件才得到最終的資源和授權。所以我一開始跟團隊強調，現在不要提什麼平台，沒有足夠多的客戶也不要想什麼平台，先踏踏實實的做好工具產品。
2015年4月還發生了另外一件事情，我開始跑步了。沒多久數加在產品方向上基本確定了要做新的計費模型、服務商模型和數據服務市場等主要的事情。老張和我討論團隊的口號的時候，我們達成了三點，就是前面數加的PD王峰說的：成全他人、莫向外求、跑馬拉松。其中跑馬拉松是我提出的，一方面是讓團隊做好持久戰的心理準備，另外一方面我也給自己定下跑馬拉松的目標。到數加發布為止，我一共跑完了三個半馬一個全馬，想想當年在學校跑1500米都要死要活的，只要有目標，沒有什麼不可能。
簡單的八卦故事到這裡應該告一段落了。我在2015年11月從阿里雲離職，和幾個前同事一起創立了袋鼠雲。很多人問為什麼離職？數加當時雖然做得辛苦，需要從法務到財務到底層的Base/ODPS技術，到計費團隊，要做一點事情都需要從最上面的業務一直貫通到最下面的技術運維，但總體上目標是清晰的，前景是光明的，數加這個小團隊自身相處得也很融洽。但也正是在做數加的過程中，我看到了雲的趨勢、計算的趨勢和數據的趨勢，也堅信面向企業的雲服務和大數據有一波新的機會。我已經在阿里八年多，歷經淘寶DBA、手機淘寶數據產品和數據事業部數加團隊，收穫很多，也錯過了很多。如果再多待幾年，還是會有不錯的收入，頭頂著平台的光環也可以吹吹牛B，但可能會失去從頭開始的勇氣。錯過這波機會，未來回頭來看的時候，我想我會後悔的。當然，創業維艱，失敗的概率很大，但至少我經歷過的選擇都從不後悔。
那麼，說了這麼多，到底數加是什麼鬼？當天發布的底層計算引擎有類似Hadoop/EMR的ODPS（發布會上宣布改名為MaxCompute）、有類似Storm的StreamCompute、有做實時多維計算的Analytic DB、有機器學習的PAI。計算引擎之上，有數據開發者友好的Web IDE、有業務任務的調度系統、有元數據管理等一整套操作界面。對於大部分做大數據開發的同學來說，底層的計算引擎大部分情況是不可見的，日常需要操作的主要就是這層界面，也就是首頁 - 數加平台這個網站。這兩層產品相互依賴，可以說是數加的平台產品。基於這個平台，不管是阿里內部，還是外部的數據開發者，都可以來做大數據的開發和應用。大會上發布的其他產品，包括移動數據分析、DataV可視化、規則引擎、推薦引擎、BI報表、應用託管、郡縣圖治等，雖然看起來名目繁多，實際上只是平台之上進行補充和豐富的工具、服務以及典型的大數據應用案例。阿里雲的主要目標應該是做好下面兩層平台，並將平台的能力更多更快更好的開放出來，這兩層才是阿里雲大數據的核心競爭力，上層開放則可以形成豐富的生態，未來應該有更多的第三方基於數加平台來開發和提供豐富的大數據服務和應用，這是我對這個事情的理解。
今天有關注，寫幾句
列幾個數字：
1、全球那個很知名的排序競賽，在一項比賽中，阿里雲的成績是100TB數據377秒。打破了四項世界紀錄。2、阿里雲官方披露的：自建Hadoop集群的成本是數加的3倍多，國外計算廠商AWS 的EMR成本更是數加的5倍。3、大麥網通過採用「數加」的推薦引擎，研發成本從900人天降低到了30人天，效率提升了30倍。最起碼，從速度、成本、開發效率上， 有很大提升。
之前，我轉發過一個墨跡天氣的分享：
阿里雲的ODPS用的怎樣？ - 任志濤的回答成本降低很顯，主要是EMR太尼瑪貴啦！
利益聲明：在阿里雲做數據方面的研究，把數加平台建起來的攻城獅之一。
阿里雲大數據平台數加發布，看到很多人關注，有同行來詢問，也有不做技術的朋友關心大數據能給生活帶來什麼改變。作為參與者，想寫寫我的理解。僅代表個人。
先說說大數據：
大數據說了好多年，其實需要解決的核心問題，和「小數據」沒有本質的區別，都是為了解決信息的缺失和不對稱。
信息的不對稱帶來了決策的錯誤，導致了整個經濟系統的運營低效，浪費了社會的資源。今天有了大數據的技術，和應用場景，這種不對稱就會被大大的改善。
每一個個體都可以作出一個相對優的決策，整個系統的運轉，也自然就變的高效了。
例如，我要從上海虹橋機場到浦東，而且要在三點鐘之前趕到。大家如果開車，第一個動作可能是打開高德地圖或者百度地圖看一下，哪些地方是擁堵的，我就避開。
這個流程我們每天都在重複。但大家仔細一想，這裡有一個時間差——我出發時候看的交通狀況，和到達那裡時候是不一樣的，沒有人告訴我三十分鐘後那裡是不是堵的。
但是因為我們有阿里雲的平台，我們有數加背後所沉澱出來的數據體系和加工的能力，能夠告訴你30分鐘後的路況是怎麼樣的。
這是浙江省交通運輸廳最近剛剛做的一件事，他們用數加平台來預測高速路況。在浙江省1300公里的高速上面，告訴你的不是當前的路況，而是未來60分鐘每一個地區未來的路況是什麼樣的，當前的情況你可以實時查詢到，同時還可以告訴你5分鐘之後、10分鐘之後、60分鐘之後是什麼樣的。
再講一個應用
剛剛講的這個應用是面向C端的信息服務，幫助咱們的司機朋友，有更好的出行。下面講一個面向交通管理者的服務，如果真正的發生了擁堵我要怎麼辦？
交通管理機構們可以用數加平台，來掃描它周邊的所有的控制節點，每一個控制節點都有一個排列因子，這個因子是演算法算出來的，算出來之後給你一個結果，實時的告訴你說，你應該在哪些地方，在什麼時間範圍內，按照多大的力度進行限流和放行，能夠儘快的緩解大橋的擁堵。
實際的運行是秒級之內產生的，因為所有的數據都在這個平台上，演算法的啟動，當我們接到警報，大橋嚴重擁堵的時候就實時起動，自動產生了這個結果。
這個結果的落地是怎麼回事，大家可以想像一下，如果上海的匝道上有信號燈，建議在某一個匝道口限行20%，就可以達到這個效果。
所以從數據驅動的角度來講，最後的行動點就是落實在了調紅綠燈的綠信比。現在調整是憑經驗的。我不是說人工經驗不對，我們的方法，或者這一套理念可以讓人的工作更加的輕鬆或者精準。
還有訂單派送的場景
在最開始，一般的訂單推送，就是暴力的方法，沿著乘客的中心，1.5公里的半徑，圈所有的司機進行群發，分批的發。司機端承接了非常多的定單，那麼小的屏幕上面目不暇給，而乘客也要等待很久，司機才會去搶單。最後演算法可以做到精準的，圈選某些司機去推，他搶單的概率更高。這個演算法就是基與數加平台上的東西，那一套數據加工、建演算法的模型。
最後專門說說數加
用「大炮」打「蚊子」是我們團隊自己聊到一個比喻。因為在數加累計的技術和平台，之前是服務於阿里巴巴內部的，有足夠的場景和足夠的量，所以造出來的東西都是「核武器」。有的人會說，外面實際上不需要這樣的「核武器」，覺得這個東西太重了。
「核武器」真的太重了嗎？但我們剛剛說的這幾個案例，都是我們阿里自己的人用阿里的平台，給大家演示用這個大炮怎麼打蚊子，和打大型的飛機。
現在講的這幾個問題都是行業非常大的痛點。同樣的道理，希望大家能夠從這些實踐當中看到，阿里雲的這個平台，或者說數加的這個平台的魅力。這不僅僅是一個簡單的加工平台，當它植入到垂直行業當中去的時候，所產生的顛覆性是難以想像的，可能不久的將來你可能看到它在更多領域的實踐，並且會讓每一個人感受到實際的改變。
最後我想舉一個例子給大家講一下，如果你對雲平台，或者對阿里雲還有遲疑的時候，十八世紀汽車剛剛出來的時候，在英國倫敦，當時居民們有非常大的抱怨，因為這個車又慢，噪音又大，而且有很大污染，還經常的跟馬車搶道，後來英國的議會出了一個法律，規定這個車，就是當時最原始的汽車，行駛速度不能超過多少，有個今天看來匪夷所思的法律。
在那個時刻，這是個非常合理的決定，因為居民都反對。但是今天大家都知道，這個決定是多麼的違背歷史的潮流。所以如果你對數據上雲，或者對公共雲這種服務模式還有遲疑的時候，我覺得這個例子可以給大家非常好的借鑒。如果不去擁抱變化，最終被顛覆的就是自己。
我是數加的PD。看到同事有來回答大家的疑問，我也補充一下產品方面的東西。歡迎大家一起來關注和討論。
同時，作為直接參与者，也想講講我們是怎麼做的，不敢說我們有多牛b，但我敢說我們是最用心的，諸色眾相，所存者靈。
========先說說幾個數字=========
1. Maxcompute（就是原名ODPS）是數加底層的計算引擎。有兩個維度可以看這個計算引擎的性能，1）6小時處理100PB數據，相當於1億部高清電影。2）單集群規模過萬台，並支持多集群聯合計算。
2. Analytic DB是實時多維分析引擎，可以實現百億量級多維查詢只需100毫秒。阿里內部很多面向海量互聯網用戶的產品的在線大數據查詢，很大程度上依賴於Analytic DB。
3. 流計算StreamCompute具有低延時、高性能的特點。每秒查詢率可以達到千萬級，日均處理萬億條消息、PB量級的數據。
=========廣告結束===============
賣了一段廣告，我先說說數加怎麼做的。
做數加項目之前，我們作為集團的數據事業部，已經摸爬滾打了多年，像大家耳熟能詳的ODPS、在雲端、數據魔方、淘寶時光機、淘寶指數、TCIF、阿里媽媽DMP、全景洞察、以及無數個大大小小的定向、推薦、演算法類服務等都是這個號稱坐在金山上挖礦的筒子們乾的，這個部門很屌都是牛人。
數加絕不是從開始就做所謂的平台，而是從客戶具體問題開始，必然換位思考客戶的問題在哪？我們能幫助到他什麼。
開始很多用雲的客戶提出有大數據的支持，我們跑了很多行業的客戶，累計了不少。就拿醫療行業來講，從原來的HIS、電子病歷、化驗單識別切入時碰得頭破血流，到逐漸找到遠程診療在模式識別、演算法分析、調度上的痛點，並從最需要的底層社區醫院進行公益推行。
中間過程需要很多的努力，但客戶給了我們信心，他們說會感覺到我們的專業與誠意，他們甚至願意以我們為中介，為其他客戶提供數據服務。
當下的大數據業務，我個人感覺知道做什麼比有數據更重要。前者意味著至少了解某些行業下數據的應用價值，後者只是單純的有數據而已。
我們的數據工程師、演算法工程師會衝到客戶的門口，衝到客戶現場，買行業書籍、去接觸之前壓根不懂的硬體設備、去看客戶看起來很接地氣的官網去找業務痛點的蛛絲馬跡，有的放矢，不YY，只為說人話，說客戶懂的話，謹慎拿出我們的解決方案。
做大數據最動人的風景，是看到自己的方案被客戶認可，因為這個領域，沒有專家，有的只是行者。
凡所有相，皆為虛妄。
就這麼一點一點，我們沉澱了除了一些核心通用的產品，如規則引擎（從營銷、安全場景沉澱）、推薦引擎（精準化運營沉澱）、智能語音交互（智能客服解決方案沉澱）、整合分析（客戶洞察解決方案）、DataV（可視化大屏解決方案）…再往下走，為了讓數據在各引擎間流動，我們又向下沉澱標籤管理、標籤數據同步、數據採集如MAN等底層組件…
==============廢話太多，接著說說產品本身============
做平台就是搭檯子，串，從客戶視角來看要達到的目的如下：
1． 體驗上：是一站式的。
2． 功能上：產品之間打通。
所以，對數據從業者的幫助主要體現在：
1.
工具提供的功能，極大降低數據相關工作如建倉、ETL、BI、建模、應用開發等的工作量。
2.
工具與引擎的結合，以及數據工作端到端產品線配置上的完備性。
總而言之就是方便。
===============挑幾個典型產品==============
數加平台一共發布了20個產品。平台上公測與發布的多款產品，技術優勢可以直接看看官網寫的很明白，我挑幾個典型給大家說說，希望能說明白。
- 數據可視化DataV：
作為大屏可視化業務，要點有三：
1. 如何講出故事（設計，最最最重要的一點）
2. 前端、大屏、交互控制（實現）
3. 數據設計（數據）
不用 DataV：
1. 設計
- 產品與業務狗自己想用哪些圖標，怎麼布局，吹出什麼故事，釐清脈絡，畫手稿、畫原型，設計交互的邏輯，選配客戶的數據，需要做到能在簡單的一頁之內讓人讀懂數據之間的層次與關聯，這就關係到色彩、布局、圖表的綜合運用。
2. 實現
- 開發人員不但會前端，還得懂審美進行特效開發，還得對非傳統圖標的組件進行分析展現開發對應的新組件，比如海量數據的地理軌跡、地理飛線、熱力分布、地域區塊、3D地圖、3D地球，地理數據的多層疊加，還得學習大屏技術，對接中控，拼接渲染集群。
3. 數據
- 再好的設計，沒後面的數據引擎也跑不動，需要進行數據管理，做數據同步，對接不同的數據源，還得支持動態請求，實時計算、流計算等。
用DataV：
1.
設計
直接用DataV提供的模板，或者從獲取靈感。
比如：
2.
實現
多種圖表支持，常規圖表以及地理、地球、熱力分布、多層疊加的支持。大屏技術支持多解析度適配與發布方式。
3.
數據
多種數據源計接入：支持API、CSV、RDS、阿里雲分析型資料庫，支持動態請求。
此外，圖形化的搭建工具，用戶只需要配配就行
- 再看一款產品叫規則引擎：
規則引擎的核心是將複雜易變的業務邏輯從應用代碼中剝離出來，使業務規則的定義和運行隔離開來，這樣當業務需求改變時，只需要更改規則定義，而不需要修改代碼，以及重新編譯、部署整個項目，提高了應用的擴展性和可維護性。
我們的規則引擎特點：
1. 場景化一站式服務：輕量，降低接入成本
如：移動場景下，APP可快速集成SDK實現數據採集、上報、預定義用戶profile，配備圖形化用戶分層工具實現定向營銷，精準運營流量、提升用戶粘性。
2. 實時
a) 支持實時數據（實時事件、行為、LBS等）計算（整型、字元串、枚舉、多值、範圍、時間）
b) 規則配置實時生效
c) 實時規則計算、規則匹配
3. 特徵支持
a) 規則描述語言支持SQL、UDF、ODPS表
b) 支持規則匹配自定義排序
c) 數據類型支持整型、字元串、枚舉、多值列、範圍、時間。
4. 大規模、高並發、低延遲
a) 支持十萬以上規則量、億級別數據量
b) QPS高達10萬
c) 毫秒級延遲
5. 系統及業務安全：多副本容災、業務數據及規則隔離
架構如下：
適用場景：
當然，相對業界成熟的老一輩規則引擎，我們還有很多路要走。
===========最後，如果還有人看到這裡的話==============
大數據問題本身是個系統性問題，不是靠某一單點的技術突破就能帶來業務價值的轉化，這裡面必然存在一個GAP，即對業務本質的把握、以及問題的上下游、前後鏈路等方面的深入理解。
數加團隊有個內部信條：成全他人、莫向外求、跑馬拉松。我們堅信，你好我也好。我們堅信，有問題，先問己。我們更堅信跑跑更健康。
今天數加的發布只是一個小小的里程碑，工欲善其事必先利其器，一切才剛剛開始。而如何用好工具、配好數據，為業務進行定製設計的解決方案，才是大數據的核心。
以前大家都是談論大數據，實際上有大數據的企業不多，當然，大家能使得上的工具也不多。那現在阿里雲實際上是把之前在阿里巴巴集團內部用的一些產品給開放出來。從這個角度來看，應該成熟度是非常高的。跟單純做產品的公司相比，阿里勝出在於自己有場景，有需求。（這是很難的）
談談我的看法。
對社會的作用。暫且不談它收費標準的問題，先說它的意義。在現在中國互聯網界，無論大家是否願意，阿里巴巴已經成為了某些領域的技術旗幟，特別是雲計算大數據領域。在阿里雲穩定運作的情況下，推出數加這樣的大數據服務，無疑讓國內很多相關企業有了更明確的思考方向和技術參考，知道，原來大數據是可以這樣，我覺得這對國內的相關領域的技術推動作用是巨大的：不會做，沒足夠的技術實力，沒足夠的行業積累，又想自己弄，那你先抄啊，抄著抄著，又不是傻抄，總歸會根據自己的實際情況做一些針對性的改變的，也許就有了不起的發現呢。
再者，很多所謂的媒體和評論員連雲計算和大數據是不是一回事都沒徹底弄明白就天天在那炒作在那吹，搞得普通非技術領域的人云里霧裡，然後趁機獲利。數加的推出，這叫大數據落地，叫實踐。它告訴你，用大數據的確對你的業務有幫助，然後告訴你你只需要這樣這樣操作，step by step，達到我告訴你的效果，而不再是西裝領帶所謂大數據專家唾沫橫飛跟你吹幾個月，拿完諮詢費拍屁股走人實際屁事沒幹。至於收費，東西做出來本來就是賺錢的，阿里雲不是政府機構沒有能力強制用戶用或者不用，如果覺得不合理，那麼可以選擇自己喜歡的其他服務商；如果發現沒的選，那恭喜你你發現一個好的創業點了，祝你成功，有空瞎炮轟不如去考慮實踐吧。
綜上，要問厲害在哪？我們不談技術，就一個理由足以證明：你們不是要大數據么，喏，這就是大數據，看得見摸得著的…這就是數加做的事情。利益相關：MaxCompute(原名ODPS)產品經理
很少在知乎上回答問題，特別是這種「敏感」問題，如果有紕漏，還請大家指正。因為有看到部分同學對「AWS比MaxCompute高5倍的成本」這句話有疑義，我上來解釋下。首先，MaxCompute是和AWS下的EMR做對標的。其次，我們說的成本是指什麼？用戶在採購雲計算服務的時候要考慮兩個因素：售價和計算效率。如果MaxCompute的價格是EMR的2倍，但效率是EMR的10倍，在我們看來，從用戶角度看，EMR的成本依然是MaxCompute的5倍。從價格上看，那位匿名同學說的有一定道理，但不全對。我猜你沒有真正算過兩個產品的價格。「最低1500元每月起，而且流氓的只有包月和包年，尼瑪誰家的大數據批量任務需要7*24小時跑，不跑的時候還收錢，然後跟人家能按小時收費的去pk」。這句話有一定道理，是因為odps最低1500元的門檻比較高，是事實。因為這種計費方式本身就是針對大用戶的，因此設了這樣的使用門檻。但我們沒有強姦或者排斥用戶的意思，因為阿里雲官網上MaxCompute(原名ODPS)有按量後付費的收費方式，阿里雲官網上的是沒有收費門檻的。我們建議用戶先在阿里雲官網上採購MaxCompute，而後在數加上使用MaxCompute。阿里雲論壇上有相關的使用介紹，大家可以找找看。這兩種使用方式後續會全部統一到數加平台上來，不會給用戶割裂的感覺。但上面這句話也不全對，因為你沒完整的將亞馬遜的售賣方式描述清楚。亞馬遜分按需付費和預留實例付費。按需實例的單價高，沒折扣。預留實例單價低，有折扣，但要預交前，且至少要預付1年的費用或者1年費用的一部分（這句話好繞，大家聽聽就好了）。MaxCompute的售賣方式與EMR的按需付費和預留實例付費都不太一樣，因此很難嚴格對標。如果按照那位同學的說法，EMR的按需付費是沒有使用門檻的。可ODPS也有按需後付費的方式。如果說，MaxCompute 1500元的底線是強姦用戶一個月，那麼EMR的1年或3年預留實例就是強姦用戶好多年了。其實這個說法是不對的，給大用戶，忠實用戶讓利，這是再正常不過的商業邏輯了。EMR沒做錯，MaxCompute也沒做錯。從價格對比上既然沒有嚴格的對比方式，那就只能將MaxCompute的售賣分別與AWS的按需售賣和預留實例作對比。如果是按需售賣，MaxCompute的價格大約是EMR的30%~40%，即AWS賣10元，MaxCompute賣3~4元。如果是預留實例1年（我們沒考慮3年，因為在目前的雲計算市場上很少有3年的訂單），亞馬遜的價格大約會下降到6~7元。好，以上是售價分析。在正常價格下，EMR價格是MaxCompute的3倍左右。在預留實例1年情況下，EMR價格是MaxCompute的2倍。那麼，5倍是怎麼算出來的？是因為還要考慮效率。我們拿EMR和MaxCompute做過性能對比，MaxCompute大約是EMR的2.5倍。別問我這個數字是怎麼算出來的。。。。大家也可以試試，哈哈。我猜又會有很多人挑戰我這個2.5倍是什麼鬼。。。綜合以上兩方面考慮，我們才會說出5倍這個數字。是不是5倍這個問題，我想大家也不要太糾結，如果有人覺得這個數字偏高，那他一定有辦法推翻。我啰嗦這麼多是想告訴大家，我們是以一個嚴謹的態度核算用戶成本，給用戶承諾的。
如果大家不相信，可以看阿里雲的ODPS用的怎樣？ - 大數據 這個問題中活生生的應用案例。這個裡面說墨跡成本下降到30%。這還是在MaxCompute（ODPS）降價之前，他們就是使用的MaxCompute官網按需後付費的方式。
就先這樣了，謝謝大家。這是我看到過的阿里人答題密度最高的知乎問題了，可見公關重視程度非常高哈。數加有什麼厲害的？用我一個同事自嘲的話說叫做獨門武功練成仙了。
當然樓上為了定價爭論，亞馬遜也有自己流式計算基礎叫做AWS Kinesis，對應開源的Kafka；EMR具有了流式處理能力，對應Hadoop/MapReduce，最後儲存層面是S3。處理完的數據放到S3上是按照存量收費的，不用另開EMR機器進行儲存，所以價格怎麼算這個問題可以值得商榷的。1) 為什麼說是獨門武功？因為以上說的大數據倉儲、流式計算、實時SQL等功能在開放源代碼社區也已經實現了。比如現有的YARN構架（如下圖），已經可以在HDFS的基礎上實現以上所說所有功能。
在大數據圈子混的人肯定都聽說過了阿里巴巴的ODPS，當然據說有Storm的成分在裡面。阿里自己主導開發了這麼一套系統，開始都不被人看好，竟然沒有被撤掉完全上開源，而是繼續進步，後來竟然孵化成了數加，不能不讓人佩服領導層的堅持和決心。
在國內這幾家公有雲的，阿里雲應該是規模最大商業化做的最好的。希望阿里雲不要又做裁判又做運動員，還是要做好生態建設。像我們Sensors Data依賴於各個公有雲服務，還是希望和基礎平台一起成長的。
我們針對互聯網創業公司推出的Sensors Analytics，主要解決創業公司的用戶行為分析問題，如多維事件分析，漏斗轉化，留存分析等。我們為客戶提供私有化部署，不擁有用戶的任何數據，解決客戶的安全顧慮。有興趣的可以到http://sensorsdata.cn申請體驗。阿里這個官方紕漏的太邪乎，aws比它高5倍的成本的數據怎麼來的？用數加就要關聯阿里的odps，最低1500元每月起，而且流氓的只有包月和包年，尼瑪誰家的大數據批量任務需要7*24小時跑，不跑的時候還收錢，然後跟人家能按小時收費的去pk，太流氓了吧？
微服務是個很大的話題，關於微服務和單體服務的優缺點眾說紛紜。但不可否認的是：微服務對產品的快速迭代，小步快跑有著巨大的作用。移動互聯的時代，更要擁抱變化。因此，從我司的實際出發，如何基於有限的研發人手，落地微服務，這是從創業之初，就擺在我們面前的問題。
工欲善其事 必先利其器要搭建服務，首先要有伺服器，最好還有各類開箱即用的基礎服務。有限的人手，讓我們沒有多做猶豫就確定了「一切都放到雲上」的決策。
在《Netty 內存管理探險: PoolArena 分配之謎》中曾經提到過，我司重度使用阿里雲。是的，最終我們選擇的雲供應商是阿里雲。阿里雲中各種五花八門的產品和其購買選項會讓很多初識者眼花繚亂，無從下手。本文就來談談這方面的一點心得。
一. 阿里雲的正確打開方式
打開鏈接 www.aliyun.com，首先我們得註冊一個阿里雲賬號。對企業用戶來說，應儘快申報企業實名認證。只有企業實名認證賬號才能進行對公賬號轉賬充值，開具增值稅發票等企業專用功能。實名認證入口位於「賬號管理」中：
阿里雲企業實名認證
接下來，得根據產品的目標人群選定一個主要的產品地域。幾乎所有的阿里雲產品都會要求用戶選擇所在地域，這也很好理解，雲產品也實際落地在阿里雲維護的某個物理機房中，就會有地域屬性。同一個地域內的阿里雲產品的互通可以近似理解為內網訪問，而跨地域的阿里雲產品互通就得通過互聯網進行公網通信，其可靠性和實時性都會受到影響。另外，通過公網互通，一般來說，除產品本身的費用外，阿里雲還會收取相應的公網出站流量費用。
由於阿里雲目前尚不支持在產品購買後，遷移地域，因此，除非目的明確（例如異地互備），建議從屬於同一系統的阿里雲產品都購買在相同地域中。目前，阿里雲地域有：
阿里雲的產品地域
如果面向目標人群主要為國內用戶，可選擇的地域包括：華北1/2、華東1/2和華南1。根據筆者實測，這五個區域的國內南北互通和運營商互通沒有太大差異。而華東1的物理位置就在阿里雲的大本營: 杭州，不少阿里雲的新產品也會第一時間在華東1試運營，因此，建議優先選擇。
二. 雲伺服器: ECS
一般來說，首先需要採購的是雲伺服器(ECS)。在阿里雲的ECS購買界面中，用戶可根據CPU類型，CPU核數和內存的配比，公網帶寬，ECS綁定的雲盤大小靈活組合，但這樣的靈活性也帶來了令人眼花繚亂的定價。我們來一一分析：
2.1 CPU 類型及內存配比
目前阿里雲 ECS 的實例類型分為：系列I、系列II和系列III三大類，這三個系列的差異主要表現在CPU類型(支持指令集等)、對應採用的內存型號和是否I/O優化，用戶可根據實際運行應用的特性（IO密集型 或 計算密集型）來選擇。從筆者的實踐來看，即便是採用最低配置的系列I，也足以在 CentOS 6.5 / 7 上，基於 JDK8，運行常規的IO密集型 JVM 應用服務。在採用了微服務架構，單個服務的業務邏輯在基於非同步IO和非同步介面模式充分優化後，由複雜度的不同，單組後端服務能輕鬆支撐 1K~ 5K 甚至更高的並發。摘錄說明如下：
系列 II 較系列 I 進行了硬體升級，採用 Haswell CPU、DDR4 內存，並默認為 I/O 優化實例，同時增加了一些新的指令集，使整數和浮點運算的性能翻倍，整體計算能力更強。
系列 III 相對系列 I 和系列 II 進行了硬體升級，採用 Intel Broadwell CPU、DDR4 內存，並默認為 I/O 優化實例，高主頻和中主頻兩種 CPU 配合多種內存配比，可以提供給用戶更好的性能以及更多的選擇。
而是否I/O優化的差異主要和掛載的雲盤IOPS相關，具體為：
支持 I/O 優化的實例：
掛載 SSD雲盤或高效雲盤時能夠獲得雲盤的全部存儲性能，因為 I/O 優化為實例與雲盤之間提供更好的網路能力，可保證雲盤存儲性能的發揮。
不支持 I/O 優化的實例：
掛載 SSD雲盤時，通常最高可獲得 1000 左右的 IOPS 性能；掛載高效雲盤時，通常最高可獲得數百的 IOPS 性能
在實例的選擇界面，根據不同系列，CPU核數和內存大小有若干固定搭配提供。CPU核數和內存的配比有四種：1:1(1核配1G內存)、1:2(1核配2G內存)和1:4(1核配4G內存)和1:8(1核配8G內存)。在上述的三個系列中，最低配置都有1核1G，而目前最高配置，竟然能選擇到56核224G【注1】。如對實例有特殊需求(需要更多CPU核數或是更大的內存)，則可如下截圖所示填寫工單，提交阿里雲後台，由人工進行處理。
購買非標準實例 需要提交工單申請
申請非標準實例的工單樣例
如前文所述，後端服務大多數是IO密集型的，特別地，對於 JVM 應用而言，出現 OutOfMemory 異常的場景比起CPU居高不下要多得多（大多數系統負載異常升高也都直接或間接由於 OutOfMemory 引起的）。因此，我們在實踐中以選擇 2核16G 的內存型實例為主，下面以該配置為例，並固定幾個因素來比較三個系列實例的採購成本：
計費方式均為「按量付費」
帶寬計費模式為「固定帶寬」，並設置為0Mps；此時ECS只有內網IP，沒有公網IP，後文會提到此類內網ECS的優缺點和使用場景
只有一塊默認的40G系統盤，沒有額外的數據盤，且都採用該區域允許的最低配類型雲盤
如下表列出了在2核16G配置下，不同系列，不同區域實例的每小時費用：
實例類型華東1華東2華北1華北2華南1系列I(2核16G)￥1.707/時￥1.71/時N/A￥1.71/時￥1.71/時系列II(2核16G)￥1.75/時￥1.75/時￥1.75/時￥1.75/時￥1.75/時系列III(2核16G)￥1.83/時￥1.83/時￥1.83/時￥1.83/時￥1.83/時
ECS不同系列成本對比
表中數據均為本文成文時（2017.2）的數據，僅供參考
從上表可以看到，如我們所預期的，在內核個數和內存大小相同的前提下，系列III的成本最高，系列I的成本最低，而相同系列幾乎不存在地域差異。唯一的異常是在華東1中，系列I的每小時費用相比其它三個地域便宜0.003元，這是由於在華東1地域，系列I的存儲只能選擇普通雲盤，而其它區域的系列I只能選擇高效雲盤或性能更高也更貴的SSD雲盤。
注1：
按量計費方式下的實例最高配置目前為：4核16G
包年包月計費方式下的實例最高配置目前可達驚人的：56核224G；當然費用也驚人的貴！
2.2 計費方式：按量付費 vs 包年包月
阿里雲所有產品都支持的計費方式是：按量付費，這也是雲服務相比於傳統IDC的根本優勢之一。所謂打開水龍頭就用，那當然是用了多少資源付多少錢，這一計費方式對用戶來說最容易理解。另一方面，對於包括ECS在內的幾個核心產品，阿里雲還提供了包年包月的計費方式來鎖定長期用戶。具體來說，用戶可以一次性為今後一段時間的資源使用預先付費。相比於每小時結算一次的按量計費，如果使用時長相同，這筆預付費用會便宜不少。讓我們來具體算算有多划算。以系列I的2核16G的配置為例，地域為華東2，都按照使用時長為1年，不同計費方式下的1年成本對比如下：
系列I(2核16G)按量包月包1年包2年包3年計費單價￥1.71/時￥500.00/月￥5100/年￥8400/2年￥9000/3年計費周期數× 24 × 365× 12× 1÷ 2÷ 3總費用(元)14979.606000510042003000
一比嚇一跳啊！包月使用1年的費用僅僅是按量使用1年的40%。更不用提，目前阿里雲在大力做促銷的包2年、包3年的打折力度了。當然，包年包月的優惠付出的代價是鎖定了使用期限。
需要注意，包年包月ECS有5天內無理由退款的選項：在購買包年包月ECS後，發現配置有誤，或是地域選擇錯誤，或者任何其它原因，如距離購買生效時還未超過5天的，可以進行退款。但請注意，截止目前為止，該規定細則仍然是：每個用戶累積只有1次ECS 5天內無理由退款的機會，也就是只要該阿里雲賬號已經進行過一次成功的ECS退款操作，就不能再次退款了。因此，下單要慎重啊！
阿里雲 5天無理由退款規則
綜上，我們對選擇何種計費方式，可以歸納如下：
以試用、臨時使用為目的的ECS購買，無論是測試配置，測試地域，最好採用按量付費方式，最少只需要掏1小時的費用，只要記得試用完成後，立刻通過控制台釋放實例即可（不足一小時按照一小時計費）
以長期使用為目的，在ECS的配置和地域都已經完全明確的前提下，能包多長時間包多長時間，享受超值的打折優惠
2.3 網路和安全組
在購買ECS時，我們可以選擇使用何種網路類型，阿里雲提供了「經典網路」和「專用網路」兩種：
經典網路：內網IP地址由阿里雲統一分配，且不可更改，可方便的與用戶購買的其它實例或阿里雲產品進行同地域的內網互訪，適合對網路自定義及自主性管理要求適中的用戶
專用網路：是指邏輯隔離的私有網路，用戶可以自定義網路拓撲和 IP 地址，支持通過專線連接，網路可擴展性強。適合於對網路有個性化定製及高級定製需求的客戶
簡言之，「專用網路」給了有能力且有需求使用「虛擬交換機/路由器」來規劃定義私有網路用戶這樣一種可能性：在阿里雲的基礎網路內建立一個可以自定義的專有隔離網路，自定義這個專有網路的網路拓撲和 IP 地址。兩種網路類型的功能對比如下表：
功能點經典網路專有網路二層邏輯隔離不支持支持自定義私網網段不支持用戶自定義用戶自定義私網 IP 規劃經典網路內唯一專有網路內唯一，專有網路間可重複自建 VPN不支持支持私網互通賬號內相同地域內互通專有網路內互通，專有網路間隔離自建 NAT 網關不支持支持
經典網路 vs 專有網路
「專用網路」的一種應用場景是搭配高速通道組建混合雲，如下圖所示：
混合雲示意圖
使用「專用網路」(VPC)、ECS和其它雲產品搭建雲上業務系統，而出於數據保密性考慮，核心數據放置在雲下用戶的自建數據中心(IDC)，使用高速通道專線接入，實現雲上雲下數據互通，形成混合雲使用環境。
專用網路還有其它使用場景，參見文後所附參考資料(阿里云：VPC專用網路常用應用場景)，這裡不再贅述。
對於大多數用戶而言，「經典網路」已經足夠使用。而使用「安全組」防火牆可做到三層網路訪問控制，所以，如果要在經典網路中，進行簡單的訪問隔離，可使用創建多個「安全組」來實現，具體說明參見文後所附參考資料安全組使用FAQ。在小規模使用中，"偷懶"一點，全局使用一個默認安全組，通常也足夠了。
2.4 ECS綁定的存儲
無論選擇何種實例類型，小到1核1G，大到56核224G，ECS默認的系統盤大小均為40G，用戶可以調整系統盤最大到500G，或是購買額外的數據盤。增大系統盤或另購數據盤都會增加ECS的採購成本。從筆者的實踐來看，如果只是安裝後端服務，以及臨時保存運行日誌，默認的40G系統盤在安裝完系統後的剩餘空間已完全足夠。
- 問題1：要用雲盤長期保存文件（用戶上傳的圖片、音視頻）怎麼辦，而且文件的數量估計還挺多？
如業務中需要長期保存文件，則建議單獨採購阿里雲的OSS產品，使用其SDK二次開發來完成功能。從安全性、數據完整性以及結合使用阿里雲CDN的方便性看，OSS都提供了遠超雲盤文件系統的能力。本系列後續文章中會再做詳細介紹。 - 問題2：系統產生的運行日誌中有很多有用信息，想長期保存，以後估計還得做個分析，40G空間不夠咋辦？
後端服務運行產生的日誌類文件，如需要長期保存，建議結合使用阿里雲日誌服務和OSS、表格存儲、MaxCompute等存儲類服務，並配合 E-MapReduce、MaxCompute 進行離線日誌分析。
另外，如確需購買額外雲盤，也建議採購獨立型雲盤。其購買入口位於「雲伺服器ECS」-"磁碟"下，如截圖所示：
獨立雲盤購買入口
獨立型雲盤可以在不同的時間，掛載到相同地域的不同ECS實例上，這種雲盤的使用方式更為靈活和經濟。
2.5 帶寬方式
ECS在帶寬計費方式上也提供了兩種選擇 —— 「按固定帶寬」 和 「按使用流量」：
按固定帶寬的方式：
需指定公網出站的帶寬的大小，如 10Mbps，適用於業務場景對於網路帶寬要求比較穩定的客戶，費用較低
按使用流量的方式：
是按公網出站的實際發生的網路流量進行收費，適用於業務場景對網路帶寬需求變化較大的場景，如平時帶寬使用較低但間歇性的出現網路訪問高峰的場景；為了防止突然爆發的流量產生較高的費用，可以指定容許的最大網路帶寬進行限制
對於如何選定帶寬方式，我們可以從接入架構考慮。從我司的實踐來看，一個相對合理的生產系統接入架構是：將阿里雲負載均衡(SLB)前置於業務系統前。此時，由前端APP或WEB與後端服務交互產生的入站和出站公網流量，均在SLB上計費。一般情況下，SLB和後端ECS屬於同一地域，因此兩者通信走的是內網流量，不產生費用。
SLB 前置示意圖
該方式的優勢是巨大的，顯而易見，如果SLB後端對接多個運行相同功能服務的ECS，可滿足高可用和吞吐量水平擴容的要求。同時，由於ECS不直接暴露在公網，可避免一系列由ECS操作系統漏洞帶來的安全性問題。此時，作為後端服務的ECS甚至無需公網IP，也就可以配置為前文提及的「內網ECS」模式——將固定帶寬直接配置為 0Mbps。關於 SLB 的使用方式，在本系列的下一篇文章，還會詳細介紹。
是否可將所有ECS都配置為無公網IP的內網ECS呢？
從實際操作情況看，往往做不到，有如下幾個原因：
- 除使用阿里雲提供的ECS控制台外，一般還需要登錄到ECS上，通過圖形界面或命令行進行操作。即便是在全Linux組成的系統中，還是至少需要一台能通過公網訪問的伺服器，來作為登錄跳板機，使用 ssh 或類似方式，手動登錄到組內的任何一台ECS上
- 公網帶寬為0Mbps的ECS，除了公網不能直接到達外（不能直接入站），它本身也不能直接訪問公網（不能直接出站）。這一限制，通常不會帶來問題，因為所有的阿里雲產品，包括 RDS、OSS、雲資料庫 Redis，消息隊列等在內，都有內網地址，均能通過內網訪問或僅支持內網訪問。但如ECS上運行的後端服務需要訪問非阿里雲產品的公網服務，例如：第三方簡訊平台、百度系開放平台、騰訊系開放平台，則ECS必須能夠有公網的訪問能力。
綜上，如ECS僅作為運維跳板機使用，可確定帶寬計費方式必然是選擇「按使用流量」划算，大致估算運維操作中，可能的最大下載（對ECS來說是出站帶寬）需求，即可確定最大網路帶寬的數值。若是後端服務需要對公網進行訪問的，如果訪問操作較為均勻，建議採用「固定帶寬」方式；若訪問操作時機及所需帶寬隨機性較大，則還是採用「按使用流量」計費為妥。
另外，如需搭建內容下載型業務，從帶寬成本和體驗考慮，應優先考慮使用阿里雲CDN，而非直接通過ECS或SLB提供下載服務。
2.6 延伸問題：單台ECS運行多少服務實例合適
在微服務架構中，一個基本的事實是：相比於大單體，會存在多得多的獨立服務進程，或稱之為「服務實例」。那麼，到底該如何將這些服務實例分配到伺服器中去：是盡量在低配ECS上運行單實例，還是將更多的實例納入到CPU核數和內存都更多的高配ECS中去運行？為後面行文方便，我們將這一概念稱為：ECS/實例 配比策略，前者定義為：1:1配比，後者定義為：1:N配比。
讓我們來簡單測算下分別採用兩種不同的ECS/實例 配比策略的成本開銷。由於目前阿里雲中ECS的最低配實例就是1核1G內存的，我們假定單服務實例使用1G內存，一共有12個這樣的服務實例需要運行，在該假設情況下，成本對比為：
ECS/實例 配比策略低配ECS運行單實例(1:1)高配ECS運行多實例(1:N)單實例內存資源消耗1G1G整系統所需實例數1212單台ECS配置1核1G2核16G所需ECS數量121單ECS成本【注2】￥459.00/年￥5079.60/年購買ECS總成本(元)￥5508￥5079.60
ECS/實例配比策略比較(1)
從上表看，1:1配比相對於1:N配比策略，每年就要多花費428.4元。更進一步，由於微服務架構更鼓勵單服務實例專註於實現單個業務功能，因此，將單服務實例基於非同步IO和非同步介面模式充分優化後，內存消耗能降到更低。在 《Netty 內存管理探險: PoolArena 分配之謎》 一文中，就引用了我司在生產系統中的實際案例：xharbor （API 網關）可配置為 128M堆內存（Heap）加上 96M堆外直接內存（Direct）總計 使用 224M系統內存來運行。
目前，我司生產系統的不同類型服務實體已經多達30+，按照30種服務類型算，為確保高可用性，每種服務實體都至少運行兩個實例，因此總計有60個同時運行的實例，按照單個實例消耗 250M 內存來再次測算整個後端系統運行1年時間的所需的ECS成本，兩種配比策略對比如下：
ECS/實例 配比策略低配ECS運行單實例(1:1)高配ECS運行多實例(1:N)單實例內存資源消耗250M250M整系統所需實例數6060單台ECS配置1核1G2核16G所需ECS數量602【注3】單ECS成本【注2】￥459.00/年￥5079.60/年購買ECS總成本(元)￥27540￥10159.2
ECS/實例配比策略比較(2)
此時，1:N配比策略的成本僅為 1:1 配比成本的37%。很明顯，這是由於在1:1配比策略下，大量的系統內存資源被浪費了。在上面的兩次測算中，細心的讀者應該已經注意到，我們忽略了CPU資源的佔用差異，在第二次測算的1:N配比策略下，每個服務實例只能分攤到 1/15 核的CPU資源。但大多數情況下，後端服務由於是IO密集型服務，所佔用的CPU資源較低，一般不會成為系統瓶頸。另一方面，阿里雲及其合作夥伴提供了相當多的標準計算密集型服務，包括：圖像裁剪、識別，語音識別，視頻轉換，大數據分析等，其投入/產出成本相比於自行搭建更為低廉。如業務中用到上述功能，建議優先考慮花錢購買標準服務來解決問題。
相對於顯性的採購成本，隱性的ECS運維成本，往往更容易被決策者所忽略。更多的ECS數量意味著更多的運維行為和更多的系統級監控，也就意味著更多的人力成本投入。運維繫統的自動化程度越高，運維上的人力成本投入會越低，但這也同時帶來了較多的基礎研發投入。哪怕是有著阿里雲強大的產品控制台和OpenAPI作為基礎，從我司的實踐來看，這裡也是一個需要精兵強將投入的「艱巨戰場」。
當然1:N配比策略也有需要謹慎處理的不足之處：
- 由於計算資源沒有被隔離，存在由單個服務實例負載異常造成整台ECS緩慢的問題，這就需要更為實時和靈敏的業務監控系統來及時發現此類問題，給短期的手工解決贏得時間，給長期的自動化處理找到線索；
- 由於網路資源沒有隔離，多個服務實例的接入埠必須分離，最好是由操作系統自動分配（對於Socket編程來說，就是將綁定的埠值設置為0）。因此，即便是物理位置相同的服務實例，它的每次運行，服務埠都會不同，這也是微服務架構中需要解決的核心問題之一：服務發現。
- 同樣由於系統/網路資源沒有隔離，單個服務實例的網路入站或出站流量過大，也會影響同ECS上的其它實例正常提供服務，還有諸如TCP連接數佔用過多，系統文件句柄佔用過多等問題。這就需要在微服務的統一開發框架中提前埋入相關監控點，並配合業務指標監控系統及時排查、準確定位發生異常的業務模塊。
綜上，借用《人月神話》中的一句名言：「No Silver Bullet 沒有銀彈」。在實踐中，我們往往根據微服務中不同功能實例的特性，混合使用1:1和1:N這兩種配比策略：對於業務負載較小的服務實例，在確保高可用性的前提下（相同功能服務的多個實例部署在不同ECS上），盡量合用單台高配ECS；而對於業務負載繁重或是業務負載變化較大的服務實例，可以部署在單台匹配負載需求的ECS上，確保其承載能力，同時也隔離其負載的劇烈變化。
說句題外話，讓技術人員能根據系統的「個性特點」來調整部署方式，用較小的投入，獲得最大的產出，這不正是研發團隊應該追求的技術成就感嗎？
注2：ECS採用系列I，非I/O優化實例，且帶寬配置為 0Mbps
注3：同類型服務的兩個實例各自運行在不同的ECS上，互為熱備，來確保高可用性；此時，每個高配ECS運行30個實例，共計需要 0.25G × 30 = 7.5G 內存，除保留給操作系統2G的運行內存外，實際還有6.5G的內存資源可運行更多的服務實例
2.7 最後一個問題：ECS購買後的配置變更
給各位耐心讀到此處的讀者吃個定心丸。ECS購買後，還可以有限的變更配置。參照阿里雲相關文檔總結如下：
按量付費ECS不支持變更配置。這個能理解，如果配置不合適，直接釋放，重新購買即可；
包年包月支持有限度的配置變更，具體如下：除獨享型實例外，對實例規格可隨時進行升級，包括 CPU、內存、基礎帶寬進行升級。升級實例規格後需要在控制台重啟實例；
不能隨時降配，但可以續費降配。降配後的新配置會在新的續費周期內生效。當前剩餘服務期限內配置不會發生改變；
提交續費降配操作後，當前剩餘服務期限內將不再支持升級和降配功能；
升降配的時候，實例規格族不能互換，只能選擇同一規格族中的相關規格；
升降配前後，公網和內網的 IP 地址不會改變。
為大家簡單的說了一下，哈哈，口乾舌燥，其實關可以於報告，大家想獲取更多更詳細的可以私聊我，當然感興趣的小夥伴還可以關注一下我們CloudIn雲英 - 專業的雲主機，雲伺服器，雲硬碟，雲安全等IaaS及PaaS服務提供商。
不是這個資料庫的好意思提阿，Hadoop/MapReduce是1PB級別的專門開個分類，只有一個帖子Presto是Facebook最新研發的數據查詢引擎，處理能力250PB是不是全世界最大的？
經測算，自建Hadoop集群的成本是數加的1.5倍，國外計算廠商AWS 的EMR成本更是數加的5倍。
我去，這個話是常亮說的么，要是常亮說的，常亮也太老實了，怎麼賣東西嘛，如果自己建hadoop的成本只是數加的1.5倍，人家還來個屁啊，應該算上運維成本，算上一堆亂七八糟的不可預見成本，怎麼也得說個10倍呀。
為啥要跟emr比，一下子不是把底褲露出來了么，您不是有一堆什麼分析型引擎，流計算引擎，機器學習引擎，這些高大上的玩意難道都是添頭么。再說emr賣的也不好，紅海里性價比才管用，現在大藍海性價比沒卵用。
對於數據民工其實用處也不大，你自己總不大會有事沒事去跑個幾十t的數據處理，一般要有用都是企業級的。用了下，現在只開放了數據開發、機器學習、BI報表，但我沒有一個用起來的。1. 文檔偏少2. bug很多，BI報表的bug尤其多，數據拖過來根本顯示不出來。3. 這三個東西沒有結合起來，各自為戰。4. 有些耦合莫名奇妙，BI數據源的設置居然要跑到數據開發中去。
阿里雲數加很牛，因為有阿里巴巴這個母體在背後輸出養料。我看了數加的產品，思路是阿里擅長的平台化的打法，類型很齊全，引擎類產品很多，通用性很強。但客戶要真正用起來，還需要有技術集成商協助搭建具體的解決方案。
不過數加再牛，大數據領域的創業公司依然有機會，市場不可能被一家公司通吃。每一個行業對大數據的需求千差萬別，阿里做不完也不需要做完，培養合作夥伴是正道。
據我所知，國內現在大數據創業很火，雖說資本寒冬了， 但企業級服務市場的投資持續走熱，這裡代表性的企業有百度元老任旭陽帶隊創業的海致BDP，有前LinkedIn明星人物張溪夢回國創業的GrowingIO等等。
兩家公司也各有特點：海致特別低調，但默默拿下了好幾千家客戶，據說通吃了整個二手車市場；張溪夢則特別高調活躍，自帶IP屬性，各種場合宣講技術，知乎上也時有露臉與網友切磋。
anyway，我們的眼睛真的不要光盯著巨頭，而要看看市場，看看客戶，機會就在眼前。呵呵，我是來刷臉的，大概一個月前有數據統計的需求，想找個能在線連資料庫，做分析出支持移動平台炫酷報表的平台，然後看到這個帖，然後想阿里，老牛逼了，肯定不錯。
註冊試用，直連MySQL，折騰半天，怎麼老是數據不對呢，某欄位下很多值都不全，還以為我方法不對，折騰兩三天。然後下載了T家的客戶端試用，一次導入成功。
當時在群里說了這個問題，還有人在那邊陰陽怪氣的說：「收費版不是沒有道理的，想要好東西就要花錢」。
我呸！
要麼就別出免費版，出了就要能用，連第一步數據導入值都導入不全，還做什麼大數據平台。
之後客服還聯繫過我說工程師會解決這個問題，說你這個問題確實也是第一次遇到！但至今似乎也沒什麼消息了。不過我反正也不用了。離獨立第三方切實可用還有距離，大多稱得上成功的案例還不是完全獨立自主實現的，阿里的同學請加油。
這個平台怎麼樣現在還不好說，不過看大會中阿里雲承諾永遠不碰用戶數據，這個要點贊。谷歌有「不作惡」，阿里雲有「立規矩」，國內的技術企業太缺少這類精神了。
作為odps的長期用戶:優點: 便宜，使用比較簡單，支持SQL和自定義函數。數據導入也方便。缺點: 坑多，很多SQL語法不支持。不穩定，經常出問題。
有啥厲害的，聽說在赤裸裸賣數據，開放介面讓各路電話銷售騷擾用戶，號稱外部人員只能撥打電話，看不到客戶電話號碼，所以自己騙自己不算違法倒賣用戶數據。阿里就只能搞這種生意啦？哈哈哈哈哈
推薦閱讀：
※如何破解雲棲大會妹子的Geek交友貼？
※阿里雲免費開通碼怎樣才能得到？
※萬網提供的雲伺服器和虛擬主機的區別是什麼？
※為什麼AWS無法在國內發展起來?阿里雲目前毫無疑問國內老大,AWS已經出新聞出售中國區設施了？