數字化、線上化、智慧化驅動數字中國

本次雲棲大會的主題是驅動數字中國，以阿里集團和阿里雲的先進技術幫助中國更多的中小企業實現數字化轉型，或者更好的利用資料、技術來提高自身的產能和行業競爭力。而傳統企業的數字化轉型的必經路線是：數字化 -> 線上化 -> 智慧化，根據這個主題，我們來看本次雲棲大會的議程，這些議程基本可以劃分為數字化、線上化、智慧化三個方面：

• 數字化相關的專場有：企業數字化轉型峰會、雲徙營銷數字化專場。
• 線上化方面，各容器專場、各資料庫專場、智慧運維專場都是為線上化提供經驗和技術支援的。
• 智慧化相關的場次最多，有物聯網、人工智慧、機器學習相關的專場。大資料和計算能力是智慧化的基礎設施，大資料方面的專場有：大資料計算專場、資料中臺專場、Flink專場等等，另外從行業應用來看，還有智慧城市、智慧物流、智慧交通等專場。

結合大會議程及四天的現場參會見聞，有以下兩個大的方面的感受：

強大的智慧化基礎設施

大資料和計算能力是智慧化的基礎設施，在這方面，阿里雲做了大量工作：

• 硬體方面有異構計算、神龍伺服器等技術，並且把通過阿里雲這個能力開放出去了，各內部BU或者外部客戶，提交的大資料計算任務，根據你的任務特性，最終可以跑在這些不同的硬體平臺上。當然最牛的還有平頭哥，也計劃通過阿里雲的計算平臺向外提供服務，值得期待。
• 軟體方面有：MaxCompute、Flink，PAI等，提供批處理、流處理、資料的機器學習功能，滿足各種大資料計算的業務場景需求。

雲仍然以IaaS和PaaS為主，基本上還看不到SaaS

• 比較多的議題還是ECS、虛擬化技術、容器專場。
• Serverless函式計算算是一個Saas領域的一個探索，但還不能等同於SaaS。
• 大資料計算平臺，也更像是向廣大的使用者開放了計算能力方面的FaaS。
• 電商平臺專場提到的電商能力SDK有SaaS這個趨勢，但是還處於內部探索、建設階段，還沒有形成雲上的能力，不過阿里有這個計劃在未來將這塊能力開放出去。

個人參會場次的簡要總結

由於分身乏術，只能選擇參加一些場次，作為高德的技術同學，我的參會場次選擇是：

下面對我參會了的場次做個簡要的總結。

Flink專場

Flink主要適用於流式資料處理，在阿里的應用場景很多，舉幾個例子：

• 雙11大屏的實時成交額；
• 搜尋的資料同步，沒有庫存了的商品使用流式資料同步到搜尋
• 業務監控報警，從日誌流式資料中監控搜尋無結果率

Flink最早是在2009年就有了，但是到2014年正式提交到Apache後開始流行起來，主要用在流式資料處理場景，以cluster或者standalone的方式部署，目前Flink是一個流式計算的Framework。未來Flink開源社群有計劃：除了現有的Framework方式以外，Flink也可以作為一個Library的方式提供給各業務應用。

阿里在Flink開原始碼基礎之上，形成了自己的Blink專案，同時也將部分功能回饋給了Flink社群。主要貢獻有：

• 提供了Flink的SQL功能；
• 批流統一
• 效能優化，Blink的效能提升了十倍，主要做了序列化改進、一些運算元的改進、資源優化、優化器優化、JVM動態程式碼載入優化等。
• 穩定性提升，failover改進，實現了檔案粒度的任務重試機制。

Flink的原理在本專場裡沒有太多介紹，其和其他大資料產品體系其實是非常類似的。可以參考一個比較好的對比文章。

另外我想說的是類似於在Blink這種在開源基礎上優化的方式是很值得推薦的一種方式，這也是利用Java生態體系的一個天然優勢，深入理解一些開源產品這也是我們的工程師們在進階道路上的一個必須要求。

大資料計算專場

MaxCompute核心功能擴充套件

從ODPS到MaxCompute，核心功能擴充套件了不少，使用過MaxCompute的應該都有一些感受，我們感受到的幾個主要的新擴充套件功能有：

• 引入Tensorflow科學計算功能；
• 外表功能，支援oss外部表;
• sql功能增強，支援user defined type，支援java list型別，甚至支援java程式碼型別；
• User defined jion，允許使用者自定義表的連線過程。

MaxCompute輔助功能擴充套件

• 自動優化功能，基於對資料和歷史執行情況的分析，MaxCompute做自適應優化。例如通過自動分析後，自動在某些業務表上建立Hash cluster索引。這個功能非常有用，能節省費用並能加快速度。自動優化功能的主要分析點有：

  • 發現數據之間的關聯關係
  • 找到重複子樹，讓計算結果重用
  • 尋找最優資料加工路徑
  • 冷熱資料識別和管理
• Data Studio功能增強，圖形化sql，輸入提示，錯誤提示。

之所以我將上述這些功能擴充套件歸納為輔助功能擴充套件，是因為我認為如果沒有這些功能，MaxCompute的核心功能不受影響，但是有了這些，讓這個產品更好用了，而很多時候產品的成敗，對使用者是否好用，產品的輔助功能對產品的成功性影響甚至要超過50%。對於我們的開發同學，也要思考這個問題，在做好產品的核心功能之外，是不是也可以考慮一些“輔助功能”呢，可能很多時候，輔助功能花費的人力較少一些，但是效果比核心功能改進還大，RIO很高。

統一計算平臺

會上提到的統一計算平臺這個概念，我覺得是個非常好的想法，這個統一計算平臺，指的是統一MaxCompute，Flink，PAI。為什麼能統一或者說為什麼應該統一，因為他們本質上都是一個有著大量伺服器資源的平臺，其本質是將這些伺服器資源共享出來供大家使用，按使用收費。不管是開源的Flink還是我們自己的MaxCompute，其技術架構非常的類似，本質上都要解決兩個問題，一是要解決排程問題，如何管理好這些大量機器，更有效率的排程。二是要解決Shuffle及任務分片的問題。當然這裡兩個問題也不簡單，要不然我們的MaxCompute進化史也不會是一部血淚史。

此外其實我們現在的大規模分散式線上架構也和離線大資料計算架構也類似，本質也是一個資源管控、註冊排程問題，所以其實線上和離線的伺服器也是能統一管控的，通過統一管控，進一步提高能效，因為線上業務一般是白天高峰，離線業務一般是晚上高峰。實際集團已經這麼做了，通過這個技術為集團提高了能效，同時間接降低了資料計算的成本。

人工智慧峰會

人工智慧實驗室釋出的幾款產品可以考慮體驗一下，天貓精靈2.0看起來不錯，簡單的語言就可以隨心操控連線上天貓精靈的一切裝置，高大上，值得擁有~_~
個人感覺人工智慧其實還有很長的路要走，目前都還需要大量的人工訓練，有多少智慧就有多少人工，其本質仍然還是暴力計算能力。有很多挑戰性問題待解決，可能需要我們的孩子們繼續研究人工智慧~_~。不過就算是現階段的人工智慧技術已經很有價值了，已經能大大的提高生產力了，例如語言識別、智慧客服、汽車保險的自動定損、無感刷臉支付等等場景，我們可以稱之為“狹義人工智慧”，“狹義人工智慧”的應用場景還能夠更多更廣泛。未來隨著“廣義人工智慧”技術的發展，可能會給人們的日常生活帶來更多的便利。

自動駕駛車路協同專場

自動駕駛是智慧化方面的典型應用場景，也是非常有挑戰的應用場景。以前以為自動駕駛就只是在車上下功夫，此次參會聽到的新思路是車路協同，在路網上部署感測器，解決死角的問題，並且這些感測器通過共用統一的協議可以被路上的所有智慧汽車使用，降低車上的感測器數量，降低智慧汽車的成本，車路協調的方式可以有效的提升自動駕駛的準確率。

高德專場

地圖行業是一個技術很有挑戰性的行業，涉及到數字化、線上化、智慧化的所有方面。地圖的基礎資料採集是數字化；如何支援億級DAU是對線上化的挑戰；智慧化方面的應用也很多：例如如何利用智慧化提高地圖資料採集生產的效率，如何自動識別路牌等等，地圖領域存在不少的智慧化應用場景。

基於機器學習的路徑規劃

本次會上聽到了一個比較有意思的智慧化應用場景：我們開啟地圖看到的交通狀況，都是當時實時的交通狀況，通常路線規劃也是基於當時的交通狀況來給出的，可能有些同學（尤其是北京的同學）有過這種經驗：出發前明明規劃了一條不擁堵的路線，可是按這條路線開著開著就發現堵起來了。這是因為求路的時候只是考慮了當時實時的交通路況，沒有考慮到一段時間之後的路況（實際路是有關聯的，路況會聯動變化）。在本次雲棲大會的高德專場上，清華大學的教授帶來的專題《基於深度學習的大規模城市路網旅行時間預測》，就是為了回答T+N時刻的交通路況問題的。和其他的機器學習場景類似，問題的複雜性高，T+N時刻的交通狀況預測問題的複雜性也很高，主要挑戰有：

• 交通狀態的變化呈現非線性特徵；
• 路網空間關聯性複雜；
• 交通狀態受天氣、時段、周次影響；
• T+n預測，隨著N增大，多步預測誤差累計增大；

預測未來的交通訊息複雜度高，基於未來的交通訊息來規劃路線複雜度就更高了，雖然這個問題的複雜性很高，高德地圖在2017年就已實現了TDR（Time dependent routing）路徑規劃演算法來解決上述類似問題，並且還在持續的優化這個演算法，幫助使用者躲避未來的擁堵（限行、禁行），致力於給使用者提供最優的導航路徑規劃體驗。

高精地圖

高精地圖是自動駕駛的必不可少的基礎設施，自動駕駛離不開高精地圖 + 高精定位 + 高精終端。高精地圖的首要要求是高精定位，有了高精定位，地圖採集才能精確到釐米級，高精定位用的是由千尋提供的高精定位服務。千尋的高精定位服務是通過衛星 + 基站的交叉定位方式來最終實現高精定位的。

未來一切專而精的能力都是以雲服務的方式來提供。高精定位服務就是一個很好的佐證。高精定位服務需求量大，特別適合放到天然具備彈效能力的雲端，作為一個SaaS服務。同樣，高精地圖未來也比較適合以SaaS的方式提供服務。

電商平臺專場

因為我本人以前的工作經歷（噹噹、京東），所以選擇了電商平臺專場。
如前文所述，電商能力SDK有非常大的SaaS潛力。這是一個非常複雜的事情，業務上沒有先例可參考，在如何提供SaaS服務這個主題上，建議可以參考參考Salesforce

severless儲存專場

我在團隊內部和大家討論過AWS的 Lambda（函式式計算，FaaS產品）的可能實現方式（雖然我們Snowman技術小團隊主要是做業務的，不是做雲或者中介軟體的，但是YY猜測一下技術實現也是有裨益的~_~），其中有一個問題是：FaaS的負載升高情況下的自動擴容是如何實現的？猜測有兩種可能的方式：一是程式碼的熱載入，二是啟動容器的方式，在上傳Func的時候就製作好容器映象。當時我們覺得可能是前一種方式（雖然這種方式有很多問題要解決，比如多種開發語言的問題）；因為後一種方式，容器啟動太慢，根本無法滿足FaaS對20ms啟動的效能要求。本次Severless專場也有一個阿里雲函式式計算專題，給出的答案是後一種方式：啟動容器的方式。

不過阿里雲用了個改進的方法來解決這個延時問題：容器預啟動。具體來說是：根據負載預測來提前啟動容器，多啟動出來的容器不收取使用者的費用。雖然有點資源浪費的問題，但是延遲問題、使用者體驗問題解決了。當然做好這個的前提是要求準確的負載預測。阿里雲的Bazaar平臺來解決了這個問題（我認為在負載暴增的極端場景下，這種方式可能會有點問題）。

資料中臺專場

資料中臺專場是將集團的資料中臺建設經驗，OneData理念共享給阿里雲的外部客戶，讓他們少走彎路。Dataphin是一個集成了集團OneData理念的產品，再加上Quick BI產品，幫助客戶快速在阿里雲上搭建自己的數倉，快速挖掘資料資產的價值。

現場展廳

最後發兩張本次2018杭州雲棲大會展廳圖片，給沒有去現場的同學感受一下高大上（抱歉沒帶攝影師，大家湊合看~_~）

贊整個大會的組織，很成功，從會場返回的班車上遇到資料庫專場的組織MM，瞭解到他們為了這個會議做了大量的幕後工作，真的是很辛苦，給他們點贊！

以上僅是個人的一個參會總結，不代表任何官方渠道，一家之言，不當或者謬誤之處，歡迎拍磚~_~