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

以下為現(xiàn)場速記。

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

易觀CTO (原萬達(dá)電商大數(shù)據(jù)總經(jīng)理) 郭煒

郭煒：我以前在萬達(dá)工作，各位今天在萬達(dá)登錄酒店WIFI的時候，我還很熟悉，因?yàn)閷拥臅r候是我在做的。后來在聯(lián)想做了大數(shù)據(jù)總監(jiān)，負(fù)責(zé)聯(lián)想全球的大數(shù)據(jù)平臺，現(xiàn)在加盟了易觀，負(fù)責(zé)易觀相關(guān)技術(shù)產(chǎn)品的工作。

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

如果真的要做公有云，在座的CIO一定要想這樣的幾個問題，一路走來，這幾個問題是需要大家考慮的。第一，你的業(yè)務(wù)是穩(wěn)定的還是變化的。其實(shí)如果你的業(yè)務(wù)是比較穩(wěn)定的，不是突增或者突漲或者業(yè)務(wù)規(guī)模不夠大的時候，其實(shí)你可以先不用云化。這里我舉一個業(yè)內(nèi)經(jīng)常用的例子，現(xiàn)在用云化最多的公司是游戲公司，為什么呢?因?yàn)樗呛退臉I(yè)務(wù)緊密相關(guān)的，大家知道一個游戲火爆起來以后，可能瞬間幾天或者幾周的注冊量一下子就上去了，如果用傳統(tǒng)業(yè)務(wù)支持的方法是沒法支持這樣的業(yè)務(wù)規(guī)模的。如果一個游戲沒有做好，可能幾周之內(nèi)就沒有人玩了，變化峰值是非?？焖俸蛣×业模杂螒蚬居迷剖亲钸m合的。但是同樣可能對于我們來講，有一些比較傳統(tǒng)的業(yè)務(wù)，可能業(yè)務(wù)量差不多，一定要強(qiáng)烈云化嗎?我個人覺得不一樣，要看業(yè)務(wù)規(guī)模的情況。

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

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

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

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

首先我們的數(shù)據(jù)量是非常大的，大家知道每次做云上的遷移，對于系統(tǒng)的產(chǎn)品和穩(wěn)定性來講，對于整個技術(shù)和產(chǎn)品團(tuán)隊(duì)都是非常大的挑戰(zhàn)。有幾個比較難的難點(diǎn)，第一是數(shù)據(jù)量大，日數(shù)據(jù)有10個T，歷史數(shù)據(jù)是BP的級別，每天光有數(shù)據(jù)量就是200多億條的數(shù)據(jù)，我必須要平滑的做遷移。第二是采集并發(fā)接口并發(fā)程度高，因?yàn)槊刻鞌?shù)據(jù)在不停的上傳下來，還有很多數(shù)據(jù)的流式計(jì)算，我要保證實(shí)時性。第三是我們的系統(tǒng)架構(gòu)要大改，原來的公有云是依賴組件，我們現(xiàn)在要做混合云的時候，線下的組件使我們自己做的，數(shù)據(jù)模型也會發(fā)生變化。其實(shí)我遇到最難的是最后一點(diǎn)，系統(tǒng)要并行，因?yàn)榇蠹抑廊绻ＷC一個業(yè)務(wù)的穩(wěn)定運(yùn)轉(zhuǎn)，它不可能先把前面的業(yè)務(wù)停兩天，我做兩天的割接，這是不可能的。我們必須要同時在運(yùn)行，運(yùn)行完之后再做相關(guān)的割接。這是我們做云遷移的時候遇到的比較大的挑戰(zhàn)。

這是早期的數(shù)據(jù)架構(gòu)，如果是中小型企業(yè)也可以參考這個架構(gòu)，最開始可能只有一兩個人、兩三個人做大數(shù)據(jù)的平臺，這樣的架構(gòu)所有的結(jié)構(gòu)都是在公有云上面的。我們采用了Facebook開源的查詢數(shù)據(jù)庫，好處是可以把這些做一個非?？斓年P(guān)聯(lián)，對于中小企業(yè)來講，一開始這樣的架構(gòu)是非常適合的，因?yàn)殚_發(fā)成本比較低，人員比較好招。這是最早的大數(shù)據(jù)架構(gòu)。

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

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

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

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

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

剛才說了幾個難點(diǎn)，第一個難點(diǎn)我們的數(shù)據(jù)量很大，怎么辦?我們現(xiàn)在采用的方式，其實(shí)當(dāng)時在呵遷移的時候，第一不是同步所有數(shù)據(jù)，因?yàn)槟銜l(fā)現(xiàn)，同步所有數(shù)據(jù)的成本和時間遠(yuǎn)遠(yuǎn)超過把這些數(shù)據(jù)拿過來重新計(jì)算一遍的時間，我們只遷移原有的數(shù)據(jù)，其它數(shù)據(jù)是同步以后重新計(jì)算一遍，遷移原始數(shù)據(jù)壓縮做同步。第二是數(shù)據(jù)大改，難點(diǎn)是并發(fā)比較高，因?yàn)檫@么高的并發(fā)，兩邊數(shù)據(jù)還要同時進(jìn)行，這個事不好做。第二個難點(diǎn)是無法切換，這么高的并發(fā)，兩邊同時并行在走，也比較困難。

為什么用NGINX不行?第一，因?yàn)檫@么多數(shù)據(jù)，你拷貝一份是非常難的。同時你的數(shù)據(jù)丟了，你也沒辦法驗(yàn)證這個數(shù)據(jù)到底丟還是沒有丟，因?yàn)槟愀静恢涝瓉淼臄?shù)據(jù)是怎樣的。第二，我們通過互聯(lián)網(wǎng)做小包轉(zhuǎn)發(fā)，但是效率非常低，幾乎沒有什么好的辦法能夠讓數(shù)據(jù)拷貝出來兩份，會丟數(shù)據(jù)。這是我們當(dāng)時在驗(yàn)證的一些坑。后來怎么辦呢?沒辦法，我們開發(fā)了一套程序，我們把兩個隊(duì)列之間做了一個程序，叫做“四分衛(wèi)”的程序，小包打包成一個大的文件，傳到我們的機(jī)房，再按順序做核查，最后再把數(shù)據(jù)導(dǎo)出來。最后我也把這個東西開源出來了，主要是用于大數(shù)據(jù)互聯(lián)網(wǎng)級別的傳輸，如果大家感興趣或者遇到這個場景的，可以到這里面下載我們的程序用就行了。

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

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

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

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

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

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

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