2017 CIOC全國CIO大會7月20日在青海·西寧盛大舉辦，來自全國的300余位CIO共聚一堂，最接地氣的觀點、最實用的實戰經驗、最前沿的技術、最新的產品在此匯聚，碰撞出屬于CIO的精彩火花。

以下為現場速記。

主持人：感謝唐總的分享!公有云的故事大家聽了不少，但是哪些應用適合上云，哪些不適合呢?上云后發現不適合遷移又會怎么樣呢?具有哪些坑呢?可能絕大部分的CIO還是不太了解，我們今天請到一位先行者--易觀CIO(原萬達電商大數據總經理)郭煒先生，給我們分享《大數據應用云遷移之戰》，大家掌聲有請!

易觀CTO (原萬達電商大數據總經理) 郭煒

郭煒：我以前在萬達工作，各位今天在萬達登錄酒店WIFI的時候，我還很熟悉，因為對接的時候是我在做的。后來在聯想做了大數據總監，負責聯想全球的大數據平臺，現在加盟了易觀，負責易觀相關技術產品的工作。

為什么我們要做云遷移?首先說明一個觀點，我是強烈的云的支持者，但是我今天跟大家講的是，在座的CIO一定不要為了云而云，所有的云的背后都是需要業務需求驅動來做的。我舉易觀的例子，其實易觀是一個在技術上非常激進的公司。在我加盟易觀之前，易觀所有的業務已經是全部云化的，而且是公有云化的。在中間隨著我們的業務發展，我們當時上公有云的時候，也上了公有云各種各樣的雷河、各種各樣的坑，后來我們才從公有云遷移到混合云。

如果真的要做公有云，在座的CIO一定要想這樣的幾個問題，一路走來，這幾個問題是需要大家考慮的。第一，你的業務是穩定的還是變化的。其實如果你的業務是比較穩定的，不是突增或者突漲或者業務規模不夠大的時候，其實你可以先不用云化。這里我舉一個業內經常用的例子，現在用云化最多的公司是游戲公司，為什么呢?因為他是和他的業務緊密相關的，大家知道一個游戲火爆起來以后，可能瞬間幾天或者幾周的注冊量一下子就上去了，如果用傳統業務支持的方法是沒法支持這樣的業務規模的。如果一個游戲沒有做好，可能幾周之內就沒有人玩了，變化峰值是非常快速和劇烈的，所以游戲公司用云是最適合的。但是同樣可能對于我們來講，有一些比較傳統的業務，可能業務量差不多，一定要強烈云化嗎?我個人覺得不一樣，要看業務規模的情況。

第二，企業的硬件規模以及核心業務，我們的核心業務是否真的要云化，中小型企業剛開始的時候可以不做運作。

第三，云的性能和服務器的性能，這一點是我們在數據量級達到右下角的數據量級的時候遇到的一個坑。我們的數據在云端一開始跑得挺好的，隨著數據量的增加，開銷逐漸增多，公有云無法滿足我們的性能，于是我們被迫從公有云上面遷移到混合云。

第四，人員的儲備和管理。從這一點來講，如果一個公司剛剛起步，還是小型企業的時候，其實大家可以考慮用公有云外包自己的一些云的服務，減輕自己人員的增加。如果從小型企業到中型企業的時候，這是一個十字路口，一方面要重新評估前面三個問題，我們究竟要做公有云還是要做混合云，這個是每個CIO自己要面臨決策的問題。如果要做公有云，可能后續我們的人員不會增加那么多，但是外面CTO的成本會更多一些。大家要算一筆賬，如果要做混合云的時候，我們要看自己的混合云是否適合自己的業務，這是我們為什么一開始從公有云遷移到混合云的背景。

從業務背景上來看，我們現在整個的數據量是非常大，這些數據來自于大家自己手中使用的手機，大家看到手機會使用各種各樣的APP，但是APP背后有一個東西叫SDK。我的SDK會嵌在各種各樣的APP背后，采集大家打開和關閉的信息，這樣的數據是非常龐大的。目前我大概每天的數據接近242億條，每天大概有5千萬的活躍用戶在我的大數據平臺上面，每個月會有4.4個億的用戶都會把他的數據傳到我的大數據平臺上面。所以我們遇到了一個很大的問題，就是原來的公有云的處理方式和并發效果沒有辦法處理我當前的情況。這就是我為什么要做一個云遷移的動作。怎么做云遷移呢?我后面給大家詳細的說一下云遷移怎么干。

首先我們的數據量是非常大的，大家知道每次做云上的遷移，對于系統的產品和穩定性來講，對于整個技術和產品團隊都是非常大的挑戰。有幾個比較難的難點，第一是數據量大，日數據有10個T，歷史數據是BP的級別，每天光有數據量就是200多億條的數據，我必須要平滑的做遷移。第二是采集并發接口并發程度高，因為每天數據在不停的上傳下來，還有很多數據的流式計算，我要保證實時性。第三是我們的系統架構要大改，原來的公有云是依賴組件，我們現在要做混合云的時候，線下的組件使我們自己做的，數據模型也會發生變化。其實我遇到最難的是最后一點，系統要并行，因為大家知道如果要保證一個業務的穩定運轉，它不可能先把前面的業務停兩天，我做兩天的割接，這是不可能的。我們必須要同時在運行，運行完之后再做相關的割接。這是我們做云遷移的時候遇到的比較大的挑戰。

這是早期的數據架構，如果是中小型企業也可以參考這個架構，最開始可能只有一兩個人、兩三個人做大數據的平臺，這樣的架構所有的結構都是在公有云上面的。我們采用了Facebook開源的查詢數據庫，好處是可以把這些做一個非常快的關聯，對于中小企業來講，一開始這樣的架構是非常適合的，因為開發成本比較低，人員比較好招。這是最早的大數據架構。

為什么要用混合云?一開始公有云的時候，我們遇到最大的瓶頸就在于我們的數據量大了以后，公有云的IO性能沒有辦法非常好的保證，同樣的東西在計算的時候，可能第一天是4小時，第二天就變成6小時或者8小時，這些問題都給我們的系統穩定性帶來問題。對于混合云來講，我們有這樣幾個考量會用到混合云。第一是混合云的彈性擴展，首先我用了公有云接收大數據，每天有200多億條的大數據在上傳，而且我們接入合作伙伴，就是APP，可能一個APP就是非常大的APP。一旦接入，可能我一天的數據又增了幾十億。如果我用傳統過去的方法再買機器或者擴帶寬，我是很難滿足業務部門的需求的。每隔幾個月或者一個月都有一個合作伙伴接進來，我們要彈性擴展接收數據，我們接收的性能是非常好的。

第二是安全防控也不用我太去操心，同時我們的產品端也在公有云上，就是最上面這一端。大家看到所有的互聯網產品、APP、網站都是通過公有云做的，好處是在于我的產品線增加的時候，我不用很快的還要申請一批機器，如果生產線敗了，我不要做各種遷移，直接從公有云把相關業務線關掉就可以了。同時它的安全性也是有所保障的，比如說最近我知道5、6月份有一批黑產在做各種各樣的攻擊，我相信各位都遇到了。如果我用公有云的方法，我就不用太大費周章的遷移。對于我來講，我可以用公有云的產品上的安全接收端的彈性，這就是公有云。

對于私有云來講，我們的大數據平臺是在線下自己的傳統機房實體機來做，有幾個好處，第一是性能比較好，不用跟別人分享相關的IO。第二技術迭代也比較迅速，現在數據量大以后，我們很多開源組件的更新速度遠高于現在市面上用的公有云的更新速度，我要很快的做相關的更新。第三是投入TCO可控，像我剛才講到的，我每年數據的增量是有預期的，不一定是要彈性的，是逐步遞增的過程。如果按三年或五年折舊，其實TCO還是比我購買公有云的服務的TCO更加劃算。對于這種比較穩定的服務器的投入成本，我就會用混合云的實體服務器來替代原來純云的服務器。剛才說的結構，其實也驗證了一年多，整個架構還是非常穩定的。

接著說為什么要做混合云，其實混合云的時候，真的說要做混合云也挺復雜的。當時我們在做混合云的時候，還沒有現在這么多人有混合云的解決方案，我們當時是自己組造了一套混合云。我們跟最大的兩家公有云廠商進行對接，我們有一個SDK機房，找到一個供應商，把大數據通過公有云連接到這兩個供應廠商里面。我們通過數據的同步，把每天大概十幾個T、幾億條數據，通過光纖的方式打到集群上面，再打到BCloud做公有云的服務。

剛才提到那是原來的一個大數據的結構，其實我們的目標大數據結構是這樣的。整個的大數據集群是中間這一塊，產品展現是上面這一塊，大數據接收也是在公有云上面。最底下就是大家使用的手機，無論是安卓手機、還是IOS手機、還是微信的小程序，都有一些SDK嵌入到里面，存到公有云上面。這些是我們的流轉平臺，包括分布式的隊列組件、實時隊列。再往上有幾塊，一個是分布式存儲查詢平臺，這個平臺的結構還是推薦給大家，用起來比較方便，也是開源的。再往下是相關的一些分布式的查詢平臺，包括訂閱，右邊是實時計算的一些東西。對于元數據的管理，數據口徑的管理、數據檢測、數據調度資源，中間這些所有的平臺都是在線下我們的SDK機房里面做相關處理的，再往上兩部分全都是在公有云上做的。

剛才說了幾個難點，第一個難點我們的數據量很大，怎么辦?我們現在采用的方式，其實當時在呵遷移的時候，第一不是同步所有數據，因為你會發現，同步所有數據的成本和時間遠遠超過把這些數據拿過來重新計算一遍的時間，我們只遷移原有的數據，其它數據是同步以后重新計算一遍，遷移原始數據壓縮做同步。第二是數據大改，難點是并發比較高，因為這么高的并發，兩邊數據還要同時進行，這個事不好做。第二個難點是無法切換，這么高的并發，兩邊同時并行在走，也比較困難。

為什么用NGINX不行?第一，因為這么多數據，你拷貝一份是非常難的。同時你的數據丟了，你也沒辦法驗證這個數據到底丟還是沒有丟，因為你根本不知道原來的數據是怎樣的。第二，我們通過互聯網做小包轉發，但是效率非常低，幾乎沒有什么好的辦法能夠讓數據拷貝出來兩份，會丟數據。這是我們當時在驗證的一些坑。后來怎么辦呢?沒辦法，我們開發了一套程序，我們把兩個隊列之間做了一個程序，叫做“四分衛”的程序，小包打包成一個大的文件，傳到我們的機房，再按順序做核查，最后再把數據導出來。最后我也把這個東西開源出來了，主要是用于大數據互聯網級別的傳輸，如果大家感興趣或者遇到這個場景的，可以到這里面下載我們的程序用就行了。

做完這件事還發現有新的挑戰，當我們的數據量級已經到百億級以上的時候，我們覺得過去數據接收的量變到質變，它是否及時處理這個事無關緊要。但是如果你的數據量級到達百億級以上的時候，你會發現它越來越接近并發的交易系統。為什么呢?這個我用了右邊這個圖，這個圖可能很多CIO知道，這個圖是去年美國在被病毒攻擊導致東部的很多互聯網全部斷掉的一個圖。這個圖代表什么呢?如果我們把像百億級別的數據很好的做出來，你很有可能會把自己公司的數據形成一個大的病毒，讓你自己公司無論是公有云還是私有云都沒有辦法處理。

當這個數據處理不好的時候，我們使用互聯網的帶寬會從1到2個GB變成10個GB以上，量級到了10GB以上，基本上跟病毒沒有什么區別了。這個時候，我們就要很快的處理相關的數據。我們對于大的數據流的東西，要疏導大于處理，當出現這種問題的時候，你處理是處理不完的，只是怎么去疏導它。關鍵兩個技術比較重要的地方，第一是要良性可擴展的網絡架構，第二是云+端的控制策略。我們通過混合云和多機房的方式把這個做起來，可以用公有云的方式解決網絡架構的問題。

第二個問題，云+端的控制，所有的數據采集和處理都要有這樣的幾層，一個是交互層，比如我今天早上看到鋼廠采集自己的傳感器數據的時候，這是有交付的。存在本地有一個小的數據庫，是嵌入式的數據庫。同時還有策略層、網絡層、協議層。云端策略就是你上傳的時間，如果你上傳不了，你還要有清洗的策略、分流的策略，比如直接讓我每天幾千萬的設備分散在比如200到400個不同域名，或者發現某一些設備出現問題的時候，我直接下一個指令，不上傳數據，保證云端的處理性能和處理速度。設備端就是IOT或者APP端，我們也有一些策略，如果A網站傳上去了，我們換下一個域名，我的數據就不傳了。更新策略是多長時間和云端通一次信，包括保活策略，就是活多長時間。我們整個云+端的策略設計來看，我們現在能看到數據端從秒到6個小時，你都可以去傳，告訴他說我什么時間多長的頻次把你的數據傳送上來，跟你的業務相關的東西保證不丟失，同時也能讓你處理得過來。

持續挑戰又來了，第二個挑戰，在做大數據的時候，我發現一個問題，大家都在想大數據可能會在哪個地方出現技術問題。很多人過去都想，可能是并行的數據計算或者數據的實時計算會出問題，反而在我們真正實踐問題當中不是的，最終出現的問題是用戶畫像，我現在要基于用戶畫像看到他的行為明細是什么。比如說舉個例子，我就想看到今天在青海早上9點到10點之間，我們在萬達酒店區域這些人最高頻使用的APP前10是什么，這樣的問題挺難回答的，因為他帶了很多標簽，通過標簽找行為明細，如果用傳統數據庫的方式是沒法做的。我現在又四千多個標簽，5.4個億的裝機量，APP58萬個，這樣你會一下子發現上億級的數據，查詢不過來。我們最終的解決方案是兩部分，第一個是用開源的方法，第二是用抽樣的方式，只要看最后的結果，我們大概抽樣10%多的用戶，最后發現準確率能達到90%多，通過這個方式來做。

后面還有更復雜的挑戰，前面是無序的查詢，后面還有有序的查詢，我們也會遇到各種各樣的挑戰，大家要讓自己的團隊不斷深耕。而且每個地方你還會遇到各種各樣的挑戰，比如說我們要在數據的傳輸端做事件防火墻技術、云端互動旋鈕技術、預計算技術，這些技術不是我們自己想出來的，而是業務走到這里，是業務驅動技術做出來的東西。回到剛才的整個架構，這是目前易觀的大數據平臺的組件架構，我想也可以和各位CIO分享，這個結構在每個公司里面還是一個比較通用的結構。如果對大數據比較感興趣或者跟數據相關的感興趣的，也可以隨時在現場跟我溝通。我剛才說的整個大數據平臺，現在存了18個億的手機終端數量，每個月大概有4.4億的活躍用戶，就是這個大數據平臺來支撐我們當前的數據的一些查詢和進展的。

簡單總結一下。整個大數據遷移分了幾部分，第一是基礎建設，想要做混合云的建設、混合云的驗證，要同步歷史原來的數據，通過MR研發與追數，要開發程序去追溯，追溯以后要做相關的比較和校準。之后要試運行，同時運行完以后是無縫切換的，只是改了一個IP，用戶是沒有體驗的，中間有很多數據治理的工作，其實這些都是每個企業在遷移過程中做的東西。

今天主要分享的就是這些，非常感謝各位!