2016年混合云成為最熱門的IT流行語之一。什么是混合云?混合云能否保證云服務(wù)安全又有效?

近日，2016全球軟件開發(fā)大會(huì)在北京國際會(huì)議中心舉行，易觀CTO郭煒發(fā)表了主題為《混合云大數(shù)據(jù)遷移實(shí)踐》的演講，分享了他在易觀使用混合云的經(jīng)驗(yàn)和感受。

以下是演講全文：

為什么使用混合云?

非常高興和各位分享混合云的大數(shù)據(jù)遷移，這里邊提到兩個(gè)事，一個(gè)是混合云，一個(gè)是大數(shù)據(jù)遷移。

為什么用混合云?易觀的數(shù)據(jù)量非常大，來自于手機(jī)端APP，嵌入易觀的SDK，設(shè)備數(shù)覆蓋了7.5億，月活1.5個(gè)億，日活基本上過千萬了，這些數(shù)據(jù)實(shí)時(shí)上傳到云端，有一部分要做實(shí)時(shí)計(jì)算，有一部分做批量計(jì)算，現(xiàn)在對我來講挺大量的請求。

其實(shí)我們在國內(nèi)各種公有云上面，遷移了一圈，最后沒有辦法，我們發(fā)現(xiàn)現(xiàn)在國內(nèi)整個(gè)環(huán)境里面，在做大數(shù)據(jù)的高性能、高并發(fā)、高IO計(jì)算的時(shí)候，混合云是唯一一個(gè)比較好的出路，一方面用了底下大數(shù)據(jù)平臺，另一方面跟公有云打通，既享受到公有云對我們的免維護(hù)，可以很快的延伸，加上相關(guān)的產(chǎn)品，這樣有一些好處。所以我們把公有云做好了，用混合云的架構(gòu)處理我們大數(shù)據(jù)。

大數(shù)據(jù)遷移幾個(gè)難點(diǎn)

這個(gè)時(shí)候面臨一個(gè)問題，我們怎么把這個(gè)數(shù)據(jù)遷下來的?這里面其實(shí)有這樣幾個(gè)難點(diǎn)。

第一，大數(shù)據(jù)遷移和普通的數(shù)據(jù)庫遷移不一樣，歷史的數(shù)據(jù)是PB級別的。因?yàn)檫^去數(shù)據(jù)庫遷移，在一個(gè)機(jī)房里面表對表，或者舊系統(tǒng)對新系統(tǒng)，數(shù)據(jù)量幾個(gè)T，現(xiàn)在大數(shù)據(jù)遷移不一樣了，歷史的數(shù)據(jù)是PB級別的，不能把這個(gè)數(shù)拿硬盤拷出來，這件事不太可能。

第二，這些數(shù)據(jù)不停運(yùn)轉(zhuǎn)，日處理已經(jīng)超過10個(gè)T了，怎么保證這兩個(gè)東西不要斷線，不要影響整個(gè)生產(chǎn)環(huán)境的變遷?

第三，平均每秒鐘70到100萬次連接請求，如果兩個(gè)系統(tǒng)做并行，怎么辦?

并發(fā)量這么大，怎么讓兩個(gè)系統(tǒng)在做并行的時(shí)候，同時(shí)收到這些跨互聯(lián)網(wǎng)的數(shù)據(jù)，而不是在一個(gè)機(jī)房里通過光纖連過去?我是通過異地互聯(lián)網(wǎng)同時(shí)接收到大量數(shù)據(jù)的需求，公有云和混合云同時(shí)并行，這件事兒挑戰(zhàn)也非常大，因?yàn)樗蟹浅４蟮恼埱罅俊?/p>

第四，數(shù)據(jù)流式計(jì)算，遷的時(shí)候不能斷了，斷了以后用戶反饋非常差，就會(huì)有一些問題。所以你得把它想象成平滑過渡的過程，把我們這個(gè)數(shù)據(jù)遷移做好。

數(shù)據(jù)量這么大，怎么遷移?

中間怎么遷呢?剛才說了幾個(gè)難點(diǎn)，怎么搞定的?

第一，原始數(shù)據(jù)壓縮同步。因?yàn)槲沂且缁ヂ?lián)網(wǎng)的，不能跑人家機(jī)房里拷，大家知道真正做大數(shù)據(jù)的時(shí)候分很多層同步，底層到中間的數(shù)據(jù)統(tǒng)一層，數(shù)據(jù)匯總層，數(shù)據(jù)的結(jié)果層，我們把原始的數(shù)據(jù)層，通過線下基層高性能的計(jì)算補(bǔ)這個(gè)數(shù)，往上追，這個(gè)時(shí)間通過互聯(lián)網(wǎng)一點(diǎn)一點(diǎn)傳，不論申請多大帶寬都會(huì)非常大，互聯(lián)網(wǎng)的帶寬一會(huì)兒多一會(huì)兒少，這個(gè)東西傳就會(huì)斷掉，這個(gè)數(shù)據(jù)通過壓縮傳原始文件，重新做計(jì)算。

第二，數(shù)據(jù)驗(yàn)證。我們在不同層次里面設(shè)了一個(gè)指標(biāo)，做了相關(guān)核心條數(shù)、DAU、MAU，設(shè)了100個(gè)指標(biāo)核對每張表做的結(jié)果不一樣，無論做大數(shù)據(jù)遷移還是小數(shù)據(jù)遷移，這件事兒都得這么干。難點(diǎn)來了，我怎么去把這個(gè)接口，這樣大的并發(fā)，它是要做并行，我需要拷貝一份同樣大量數(shù)據(jù)轉(zhuǎn)發(fā)給原來的公有云上面，同時(shí)還要發(fā)給線下新的集群下面，把這兩件事兒同時(shí)并行接收，原來一份數(shù)據(jù)拷出一份做兩件事兒，我們那時(shí)候遇到巨大的考量，這么大量的數(shù)據(jù)并發(fā)，怎么把它復(fù)制出一份，給它分成兩部分，同時(shí)兩個(gè)系統(tǒng)并行的時(shí)候來接受，這是我們剛開始遇到挺大的難點(diǎn)。

為什么說NGINX不行?

在這里面可以開發(fā)一個(gè)服務(wù)，用它自己的代碼，為什么不行，其實(shí)它的性能非常高，完全能滿足剛才的并發(fā)請求量。我們的數(shù)據(jù)其實(shí)是百萬次的請求，真正的數(shù)據(jù)請求比這個(gè)量還要大，每次APP傳給我們數(shù)據(jù)的時(shí)候，都會(huì)回一條信息叫response，這個(gè)時(shí)候把本地緩存數(shù)據(jù)清空，如果沒有返回response信息的話，一直把數(shù)據(jù)緩存在他的SDK里面。我在什么地方，有一個(gè)像簡單的response，傳到云端，云端NGINX反饋給response，會(huì)清空緩存。回到這個(gè)問題來講，NGINX什么時(shí)候返回response，如果在這一層返回NGINX，因?yàn)檫@并發(fā)量非常大，怎么確保同樣的數(shù)據(jù)在這臺NGINX和這臺NGINX對大量并發(fā)請求，同時(shí)能拿到這樣的數(shù)據(jù)呢?

如果拿不到出現(xiàn)什么樣的問題，我這部數(shù)據(jù)丟掉了，無論公有云端還是混合云端，這邊的數(shù)據(jù)他這邊給SDK說，這件事情我們收到了，那邊數(shù)據(jù)回再傳了，轉(zhuǎn)發(fā)給這邊的時(shí)候，由于量非常大，不是哪個(gè)需求都可以獲得滿足的，這個(gè)請求發(fā)現(xiàn)這個(gè)事兒不行，出現(xiàn)問題了，他把這個(gè)東西知道了，回不到這邊了，這邊反饋說已經(jīng)做完了，這條數(shù)據(jù)丟掉了，同理這邊也是，哪些數(shù)據(jù)保證我們原來混合云、公有云這兩端數(shù)據(jù)一模一樣呢?所以這個(gè)數(shù)據(jù)怎么保證在并行期間，這兩個(gè)事情能對上，所以NGINX，雖然說它的轉(zhuǎn)發(fā)效率很高，并行度很高，對于這個(gè)環(huán)境來來講，沒法滿足我們的要求。

為什么Kafka不靠譜?

大家原來看到那個(gè)架構(gòu)里邊，我們把它升級變成Kafka，這邊底下有Kafka，Kafka現(xiàn)在有一個(gè)工具叫mirror maker，首先說它這個(gè)工具，這個(gè)工具挺坑的，運(yùn)行大量數(shù)據(jù)的時(shí)候根本不行，轉(zhuǎn)不起來，它會(huì)到大概我們的并發(fā)量，大概十幾分鐘就報(bào)各種各樣的錯(cuò)，每次都是如此。后來發(fā)現(xiàn)需要用Scala把頭部和中部的原代碼改一下，我的兄弟們對Scala又不太熟，干這件事兒看來不行，Kafka直接從這邊把隊(duì)列放上去，這件事兒是不靈的，這是原因之一。哪怕我們用了這個(gè)，把這個(gè)代碼重新改一遍。

為什么還不行呢?我們這些全都是小包兩條線通過互聯(lián)網(wǎng)傳的，一個(gè)地方在青島，一個(gè)地方在北京，大量傳輸?shù)木W(wǎng)絡(luò)無法滿足小包的轉(zhuǎn)發(fā)請求。我們后來自己還真寫了一個(gè)小的程序，利用Java多線程，你會(huì)發(fā)現(xiàn)大家同步的時(shí)候，要不這兒多，要不這兒多，而且這個(gè)積壓情況，每百萬次或者80萬次的請求，不是說我只是滿足了五六十萬次，它是十倍的差距，因?yàn)榫W(wǎng)絡(luò)帶寬，這種大量的小包請求非常敏感。所以造成我們在這兩邊的時(shí)候，差距特別大，一邊查，一邊速度消費(fèi)很快完了，一邊積壓三個(gè)小時(shí)的數(shù)據(jù)五個(gè)小時(shí)的數(shù)據(jù)還沒有，每天的數(shù)據(jù)都增加，現(xiàn)在三個(gè)小時(shí)沒有傳過去，再過一天變成六個(gè)小時(shí)，怎么保證剛才說的流失計(jì)算和相關(guān)的同步，這件事兒也不靠譜。

當(dāng)然也有人問，這個(gè)架構(gòu)不好，干嗎單獨(dú)設(shè)一個(gè)第三方接這個(gè)數(shù)據(jù)呢?現(xiàn)在換這個(gè)數(shù)據(jù)，這樣的模式不好嗎?我現(xiàn)在就是直接通過接收端搞一個(gè)，最后我去做相關(guān)的Kafka的時(shí)候，從這邊接收完了之后放下來，結(jié)果還是一樣的，你會(huì)看到我的這個(gè)互聯(lián)網(wǎng)傳下來的時(shí)候，在里邊積壓了大量的數(shù)據(jù)，根本消費(fèi)不完，一天過去以后，這兒數(shù)據(jù)都處理完了，這邊積壓了半天數(shù)據(jù)根本沒刷下來，這么大量小包并發(fā)傳的話一定有這個(gè)問題。

第三，自創(chuàng)工具KICKER AA。

我們自己寫了工具，我們叫做KICKER AA。我后面講一個(gè)非常穩(wěn)定的架構(gòu)。兩邊是兩個(gè)Kafka的隊(duì)列，這是我們在原來公有云端，這是我們線下混合云端，中間有幾個(gè)部件，把里面消費(fèi)原來相關(guān)的數(shù)據(jù)形成一些文件。因?yàn)槲覀儸F(xiàn)在發(fā)現(xiàn)通過小包的傳輸，特別大量百萬次的請求傳輸，不靠譜，所以我們干脆先落成文件，小的請求先壓縮，壓成一個(gè)中量型的文件。

這時(shí)候有幾個(gè)問題，怎么保證文件傳輸中間不丟。我們做同步的傳輸，特點(diǎn)就是數(shù)據(jù)特別大，怎么保持穩(wěn)定?所以我們采取的策略最簡、最優(yōu)，我們沒有用大程序就可以轉(zhuǎn)起來，各種各樣并發(fā)的請求對Kafka的壓力，對文件傳輸?shù)膲毫?，只要有一個(gè)點(diǎn)有問題，整個(gè)隊(duì)列全部出現(xiàn)問題，所以分了好幾塊。

我們先說說Consumer，干一件事兒讀Kafka的數(shù)據(jù)，把它寫到文件里面，這里邊主要對網(wǎng)絡(luò)運(yùn)營進(jìn)行處理，所有通過互聯(lián)網(wǎng)傳輸?shù)?a href="http://www.getteks.net/search?q=大數(shù)據(jù)" class="link-bottom" target="_blank" rel="nofollow">大數(shù)據(jù)，最大的隱患就是不知道這網(wǎng)什么時(shí)候好、什么時(shí)候壞。

第二個(gè)，F(xiàn)ile transfer就是做相關(guān)的傳輸，主要追加時(shí)間戳，如果消費(fèi)端有問題，我們更新到臨時(shí)文件里面，中間其實(shí)做一些簡單的設(shè)置，傳輸?shù)臅r(shí)候不是光傳文件，因?yàn)閭魑募臅r(shí)候不知道什么時(shí)候傳完，我們加一些文件這樣線下知道這件事情做完了，把數(shù)據(jù)再傳到我們線下Kafka里面去。在線下文件隊(duì)列，把剛才說的接收變成相關(guān)的數(shù)據(jù)文件，為消費(fèi)者提供這樣的東西，處理多個(gè)消費(fèi)者的請求，剛才我們說，因?yàn)檫@個(gè)消費(fèi)的時(shí)候，肯定不能通過這么大數(shù)據(jù)的并發(fā)，我們想在十分鐘到十五分鐘，從原來的公有云在混合云傳下來，進(jìn)入消費(fèi)狀態(tài)，讓整個(gè)數(shù)據(jù)流能轉(zhuǎn)起來，這件事得通過多個(gè)消費(fèi)者干，一起并行跑起來。其實(shí)一開始也遇到了一些問題，我們剛開始的時(shí)候發(fā)現(xiàn)消費(fèi)者數(shù)量控制多少，這個(gè)事兒其實(shí)是挺重要的事，如果多的話，文件服務(wù)器受不了，最后調(diào)了比較合適的數(shù)據(jù)量，把多個(gè)消費(fèi)者做相關(guān)的消費(fèi)，把文件并發(fā)給搞定。

后面解決問題，就是把消費(fèi)通過多個(gè)線程放到Kafka里面去，只要進(jìn)了線下的Kafka了，我們認(rèn)為這個(gè)事兒基本上沒有太大問題了，包括文件的管理細(xì)節(jié)，其實(shí)我們都是在這里面來做，我們傳輸?shù)臅r(shí)候單個(gè)文件傳輸，不是并行文件傳輸，我們強(qiáng)調(diào)帶寬的問題、穩(wěn)定性問題，但是每個(gè)文件傳輸速度非?？?，只要下來以后兩邊的消費(fèi)和生產(chǎn)，這兩邊全是并行，中間傳輸是文件傳輸，這樣最終達(dá)到的效果，整個(gè)傳輸剛才說的數(shù)量10到15分鐘，完全可以同步到，從公有云，從青島一直到北京，把整個(gè)數(shù)據(jù)并行起來，轉(zhuǎn)起來。

大數(shù)據(jù)遷移的“果實(shí)”——易觀方舟

我們看看最終遷了什么東西下來?因?yàn)橐子^過去都是在做分析報(bào)告檢查，所以它把我們所有的移動(dòng)客戶端分析報(bào)告做了分析模型，做了易觀方舟的東西，它的基本功能是免費(fèi)的，是專門給開發(fā)者提供大數(shù)據(jù)分析的云服務(wù)。比如運(yùn)營分析功能，會(huì)告訴你，你產(chǎn)品的月活、日活、用戶畫像怎么樣。應(yīng)用評級會(huì)告訴你，你的APP用戶值不值錢，你的消費(fèi)價(jià)值值多少，媒體價(jià)值值多少，這些都是易觀背后給你背書的，當(dāng)然還有一些社區(qū)論壇的東西。

運(yùn)營分析、渠道分析、用戶分析、提高品牌影響力，都可以用易觀的東西。通過接入易觀方舟，能夠讓你和VC進(jìn)行對接，易觀過去做分析報(bào)告，VC看我們分析的行業(yè)報(bào)告，現(xiàn)在易觀通過一些程序化的方法，把它給你做起來。

我今天的分享這么多，技術(shù)問題大家可以隨時(shí)和我們來做一些相關(guān)的討論，現(xiàn)在易觀的口號叫做會(huì)玩兒的大數(shù)據(jù)公司，我們有很多的大數(shù)據(jù)，如果想玩大數(shù)據(jù)可以加入易觀，一起來玩易觀的大數(shù)據(jù)，看我們玩出什么新花樣。今天非常感謝各位。

注：本文由易觀投稿數(shù)據(jù)猿發(fā)布

來源：數(shù)據(jù)猿