1、為什么用混合云?

目前大數(shù)據(jù)的高并發(fā)、高運維，特別跟大數(shù)據(jù)相關(guān)的應(yīng)用，我們在各種國內(nèi)公有云都試了一圈。易觀的數(shù)據(jù)量非常大，來自于我們現(xiàn)在手機端各種APP，嵌入易觀的SDK，設(shè)備數(shù)覆蓋了7.5億的設(shè)備月活1.5個億，現(xiàn)在日活基本上過千萬了。這些數(shù)據(jù)實時上傳到云端。上傳到云端的時候有一部分要做實時計算，有一部分做批量計算。

現(xiàn)在雖然不是QPS，我們其實是收數(shù)，平均現(xiàn)在80萬次每秒。如果峰值達到100萬次每秒，你會發(fā)現(xiàn)這個數(shù)據(jù)量非常大。我們在國內(nèi)各種公有云上面，遷移來遷移去遷移了一圈。

最后沒有辦法，我們發(fā)現(xiàn)在現(xiàn)在這個階段，在國內(nèi)整個環(huán)境里面，在做大數(shù)據(jù)的高性能、高并發(fā)、高IO計算的時候，我們用的混合云是唯一一個比較好的出路。

一方面用了底下大數(shù)據(jù)平臺，另一方面跟公有云打通，享受到公有云對我們的免維護，可以很快的延伸，加上相關(guān)的產(chǎn)品的好處。所以我們最終用混合云的架構(gòu)處理大數(shù)據(jù)。

2、混合云大數(shù)據(jù)遷移幾個難點：

這個時候面臨一個問題，怎么做數(shù)據(jù)遷移。這里面有幾個難點。我們現(xiàn)在設(shè)備數(shù)7.5億了，月活1.5億。過去易觀做分析報告，現(xiàn)在易觀的分析報告已經(jīng)不用過去的抽樣調(diào)查，而是加上了整個大數(shù)據(jù)易觀SDK采集的數(shù)據(jù)。易觀TOP500，移動排行榜都是基于SDK的數(shù)據(jù)算出來的，易觀監(jiān)管了66萬款A(yù)PP的情況，做出相關(guān)的分析報告，也是基于這些數(shù)據(jù)來做的。

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

第二，我們要做遷移，大數(shù)據(jù)遷移和普通的數(shù)據(jù)庫遷移有什么不一樣呢?因為過去數(shù)據(jù)庫遷移，在一個機房里面表對表，或者舊系統(tǒng)對新系統(tǒng)，我們數(shù)據(jù)量幾個T。過去的用戶相關(guān)資料，是用戶交易的東西。現(xiàn)在大數(shù)據(jù)遷移不一樣了，歷史的數(shù)據(jù)是PB級別的，把這個數(shù)據(jù)拿硬盤考出來是不太可能。怎么把這個PB級的數(shù)據(jù)做相關(guān)同步，從原來我們公有云上面遷到混合云上面，因為它不是一個IDC里邊跨機器的遷移，它是跨互聯(lián)網(wǎng)的遷移。準(zhǔn)確地講是從青島某一個公有云遷到了北京某一個混合云的機房，跨互聯(lián)網(wǎng)大數(shù)據(jù)的遷移過程。

第三，平均每秒鐘70到100萬次連接請求，如果兩個系統(tǒng)做并行的話，怎么辦?這個并發(fā)量這么大，怎么樣讓兩個系統(tǒng)在做并行的時候，同時收到這些數(shù)據(jù)，而不是說在一個機房里面通過光纖連過去?通過異地互聯(lián)網(wǎng)同時接收到大量數(shù)據(jù)的需求，當(dāng)同樣的需求數(shù)據(jù)最終達到生產(chǎn)環(huán)境的時候，公有云和混合云同時并行。但這樣做挑戰(zhàn)也非常大，因為它有非常大的請求量。

第四，數(shù)據(jù)流式計算，一些準(zhǔn)數(shù)據(jù)的，流式計算在做相關(guān)統(tǒng)計的任務(wù)，不能在遷的時候斷了。所以你得把它想象成平滑過渡的過程，把我們這個數(shù)據(jù)遷移做好。

第五，系統(tǒng)環(huán)境的改變，比如我們搭建了一套機器，線下集群用新的東西，原來在公有云應(yīng)用端的WEB服務(wù)器沒有變，底下大數(shù)據(jù)集群發(fā)生比較大的變化，同時它的模型也發(fā)生了一些變化。當(dāng)這些數(shù)據(jù)混在一起的時候，對我們這個挑戰(zhàn)就很大了。數(shù)據(jù)量超大，并發(fā)請求超大，業(yè)務(wù)并行難度很大，最終系統(tǒng)環(huán)境發(fā)生變化。

究竟怎么去遷，這個問題是我們一開始就要面臨的很大的挑戰(zhàn)。

3、早期的大數(shù)據(jù)架構(gòu)：

這個架構(gòu)其實是基于公有云，原來在公有云的一個架構(gòu)，用Redis收數(shù)。我們在公有云原來用的presto，用到挺極致的水平。現(xiàn)在presto很好的特性是跨庫查詢，跨HDFS，最后形成一個存儲鏈接。從云端下載相關(guān)查詢的時候直接下到presto里面，分散到HDFS、MySQL里面做相關(guān)的查詢工作。

最終就是Rabbit MQ，這里面會發(fā)現(xiàn)剛才提到性能的瓶頸，數(shù)據(jù)量大了以后，資源的隔離都會有一些問題。比如說，現(xiàn)在幾個集群幾十個結(jié)點，同時并行跑一個任務(wù)的時候，昨天跑的是40分鐘，今天同樣這個任務(wù)數(shù)據(jù)量差不多的時候，這個時間就無法預(yù)估了。

因為運行大批量高性能運算的時候，所有的這些都會放到CPU、磁盤上，會報警。這個時候?qū)性苼碇v顯得非常有挑戰(zhàn)性，做一個公有云，易觀只關(guān)注在公有云上面做，分析云這一塊只做分析，底下這一塊都不想做。

但是現(xiàn)在國內(nèi)這一塊還有點距離，沒有辦法變成了第二個架構(gòu)，變成了混合云架構(gòu)，放到Kafka里，這邊把它放到DFS里，那一部分放在Spark。

在上面通過直聯(lián)的方式，連到公有云上面，公有云就是我們所有的對外產(chǎn)品，大家看到的易觀方舟，所有互聯(lián)網(wǎng)產(chǎn)品都是基于這樣的架構(gòu)往上遷的，這是我們目標(biāo)的一個結(jié)構(gòu)。

4、目標(biāo)大數(shù)據(jù)結(jié)構(gòu)：

5、混合云大數(shù)據(jù)遷移方法：

第一，PB級的數(shù)據(jù)，因為要跨互聯(lián)網(wǎng)的，我們采用方法是原始數(shù)據(jù)壓縮同步。大家知道真正做大數(shù)據(jù)的時候分很多層，底層到中間的數(shù)據(jù)統(tǒng)一層，數(shù)據(jù)匯總層，數(shù)據(jù)的結(jié)果層，分好多層同步。

我們把原始的數(shù)據(jù)層，通過線下基層高性能的計算補這個數(shù)，往上追，通過互聯(lián)網(wǎng)一點一點傳。不論申請多大帶寬都會非常大，互聯(lián)網(wǎng)的帶寬一會兒多一會兒少，這個東西傳就會斷掉了。這個數(shù)據(jù)通過壓縮傳原始文件，重新做計算。

第二，做數(shù)據(jù)驗證。在不同層次里面設(shè)了一個指標(biāo)，做了相關(guān)核心條數(shù)、DAU、MAU，設(shè)了100個指標(biāo)核對每張表做的結(jié)果不一樣，無論做大數(shù)據(jù)遷移還是小數(shù)據(jù)遷移，這件事兒都得這么干。

難點來了，怎么去把這個接口，在大并發(fā)情況下，做到并行收數(shù)，不是線下收數(shù)。我們新的集群收數(shù)或者原來公有云收數(shù)，需要拷貝一份同樣大量數(shù)據(jù)轉(zhuǎn)發(fā)給原來的公有云上面，同時還要發(fā)給線下新的集群下面。把這兩件事兒同時并行接收，原來一份數(shù)據(jù)拷出一份做兩件事兒。

我們那時候遇到巨大的考量，這么大量的數(shù)據(jù)并發(fā)，怎么把它復(fù)制出一份，給它分成兩部分，同時兩個系統(tǒng)并行的時候來接受，這是我們開始遇到挺大的難點。

5.1為什么說NIGIX不行?

在這里面可以開發(fā)一個服務(wù)，用它自己的代碼，為什么不行呢?

我們的數(shù)據(jù)其實是百萬次的請求，真正的數(shù)據(jù)請求比這個量還要大。每次APP傳給我們數(shù)據(jù)的時候，都會回一條信息叫response。這個時候把本地緩存數(shù)據(jù)清空，如果沒有返回response信息的話，一直把數(shù)據(jù)緩存在SDK里面。有response，才會清空緩存。回到這個問題來講，NIGIX什么時候返回response，如果在這一層返回NIGIX，因為這并發(fā)量非常大，怎么確保同樣的數(shù)據(jù)在這臺NIGIX和這臺NIGIX對大量并發(fā)請求，同時能拿到這樣的數(shù)據(jù)呢?

如果拿不到會出現(xiàn)什么樣的問題，這部分?jǐn)?shù)據(jù)丟掉了。哪些數(shù)據(jù)保證我們原來混合云、公有云這兩端數(shù)據(jù)一模一樣呢?雖然它的轉(zhuǎn)發(fā)效率很高，并行度很高，對于這個環(huán)境來來講，沒法滿足我們的要求。

5.2 為什么Kafka不靠譜?

大家原來看到那個架構(gòu)里邊，我們把它升級變成Kafka。Kafka現(xiàn)在有一個工具叫mirror maker，運行大量數(shù)據(jù)的時候運轉(zhuǎn)不起來。在我們的并發(fā)量上，大概十幾分鐘就報各種各樣的錯。后來請教別人，人家說得用Scala把頭部和中部的原代碼改一下，但是開發(fā)人員對Scala不太熟，所以不太可行。Kafka不能直接從這邊把隊列放上去，這是原因之一。哪怕我們用了這個，把這個代碼重新改一遍。

為什么還不行呢?我們這些全都是小包兩條線通過互聯(lián)網(wǎng)傳的，一個地方在青島，一個地方在北京。大量傳輸?shù)木W(wǎng)絡(luò)無法滿足小包的轉(zhuǎn)發(fā)請求。我們后來自己還真寫了一個小的程序，利用Java多線程。同步的時候，要不這兒多，要不那兒多，而且這個積壓情況，每百萬次或者80萬次的請求，不是說只是滿足了五六十萬次，它是十倍的差距。

因為網(wǎng)絡(luò)帶寬，這種大量的小包請求非常敏感。所以造成我們在這兩邊的時候，差距特別大，一邊查，一邊速度消費很快完了，一邊積壓三個小時的數(shù)據(jù)五個小時的數(shù)據(jù)還沒有。每天的數(shù)據(jù)都增加，現(xiàn)在三個小時沒有傳過去，再過一天變成六個小時，怎么保證剛才說的流失計算和相關(guān)的同步，這件事兒也不靠譜。

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

6、怎么辦?

我們自己寫了工具，我們叫做KICKER AA。我如果大家做跨互聯(lián)網(wǎng)級別的或者類似做小包同步，基于Kafka同步的時候，可以用到我們相關(guān)的小工具，來感受感受我們用的目前的情況。后面講一個架構(gòu)，經(jīng)過剛才說的大的請求也好，數(shù)據(jù)量非常多也好，通過的TB級，它基本上是一個非常穩(wěn)定的架構(gòu)。

6.1 KICKER AA架構(gòu)介紹：

兩邊是兩個Kafka的隊列，一個是我們在原來公有云端，另一個是我們線下混合云端。中間有幾個部件，把里面消費原來相關(guān)的數(shù)據(jù)形成一些文件。因為我們現(xiàn)在發(fā)現(xiàn)通過小包的傳輸，特別大量百萬次的請求傳輸，無論通過NGIX還是通過Kafka也好，通過Java弄的小包也好，試了各種方法都不行。

所以我們干脆先落成文件，小的請求先壓縮，壓成一個中量型的文件，這樣看到幾個問題，你怎么樣保證這個文件傳輸中間不丟，出現(xiàn)了什么問題。中間我們有一些若干的步驟來做，中間其實就有一個我們做同步的傳輸，傳到這個文件的隊列里面，然后發(fā)過去。

我們沒有用大程序就可以轉(zhuǎn)起來，各種各樣并發(fā)的請求對Kafka的壓力，對文件傳輸?shù)膲毫?，因為只要一個點有問題，整個隊列全部出現(xiàn)問題，所以分了好幾塊。

6.1.1 CONSUMER 消費者：

用CONSUMER讀Kafka的數(shù)據(jù)，把它寫到文件里面，這里邊主要對網(wǎng)絡(luò)運營進行處理。所有通過互聯(lián)網(wǎng)傳輸?shù)?a href="http://www.getteks.net/search?q=大數(shù)據(jù)" class="link-bottom" target="_blank" rel="nofollow">大數(shù)據(jù)，最大的隱患就是互聯(lián)網(wǎng)。有的時候從北京到青島，我們購買的兩邊百兆，有時候10兆很難判斷什么時間出現(xiàn)了什么問題，如果出現(xiàn)梗塞怎么辦。

因為那邊是Kafka，我們就停止，要不數(shù)據(jù)越積越多，我們數(shù)據(jù)量很快就爆滿了，后面數(shù)據(jù)可能很快丟掉了，我們做了相應(yīng)擁塞的處理。我們調(diào)了比較好的文件，500兆的文件，十分鐘的時候能保證這個文件傳下來，做了一個測試，如果有問題就稍微的停一停。

6.1.2 SYNCHRONIZE TRANSMISSION 同步模塊：

File transfer就是做相關(guān)的傳輸，主要追加時間戳，如果消費端有問題，我們更新到臨時文件里面，中間其實做一些簡單的設(shè)置，傳輸?shù)臅r候不是光傳文件，因為傳文件的時候不知道什么時候傳完。我們加一些文件這樣線下知道這件事情做完了，把數(shù)據(jù)再傳到我們線下Kafka里面去。

6.1.3 FILEQUEUE 文件隊列服務(wù)：

在線下文件隊列，把剛才說的接收變成相關(guān)的數(shù)據(jù)文件，為消費者提供這樣的東西，處理多個消費者的請求。因為消費的時候，我們肯定不能通過這么大數(shù)據(jù)的并發(fā)，我們想在十分鐘到十五分鐘，從原來的公有云在混合云傳下來，進入消費狀態(tài)，讓整個數(shù)據(jù)流能轉(zhuǎn)起來。這件得通過多個消費者來做，一起并行跑起來。

其實一開始也遇到了一些問題，我們剛開始的時候發(fā)現(xiàn)消費者數(shù)量控制多少。這個其實是挺重要的，如果多的話，文件服務(wù)器受不了，Kafka受不了，最后調(diào)了比較合適的數(shù)據(jù)量，把多個消費者做相關(guān)的消費，才把文件并發(fā)問題給搞定。

6.1.4 PRODUCER 消費者：

把我們的消費通過多個線程放到Kafka里面去，只要進了線下的Kafka了，我們認(rèn)為這個事兒基本上沒有太大問題了，包括文件的管理細節(jié)。傳輸?shù)臅r候單個文件傳輸，不是并行文件傳輸。

我們強調(diào)帶寬的問題、穩(wěn)定性問題，但是每個文件傳輸速度非?？欤灰聛硪院髢蛇叺南M和生產(chǎn)，這兩邊全是并行，中間傳輸是文件傳輸，這樣最終達到的效果。整個傳輸剛才說到的數(shù)量，10到15分鐘，就完全可以同步到，從青島一直到北京，可以把整個數(shù)據(jù)并行起來，轉(zhuǎn)起來。

6.2 總結(jié)一下我們說的遷移步驟：

第一，大家先干，混合云搭建，為什么用混合云，剛才跟大家聊了一下，把基礎(chǔ)建設(shè)先做下來，然后做驗證，基礎(chǔ)設(shè)施，不要轉(zhuǎn)起來的時候出現(xiàn)一些問題。

第二，同步歷史數(shù)據(jù)，只要同步原始的歷史數(shù)據(jù)，這個時候其實背后就有一個開發(fā)工作，基于原始的歷史數(shù)據(jù)，怎么生成原來的生產(chǎn)的數(shù)據(jù)。之前想用老的數(shù)據(jù)過來追，隔天追，這樣肯定不行，PB級隔天追可能就死掉了，單獨研發(fā)一套MR的數(shù)據(jù)，把原始的文件分發(fā)到匯總層、指標(biāo)層等等這些數(shù)據(jù)都放上去，再做相關(guān)的數(shù)據(jù)比對，數(shù)據(jù)質(zhì)量的比對這些工作。

第三，并行驗證這一塊，說到并行程序的研發(fā)，經(jīng)過幾經(jīng)周轉(zhuǎn)，通過Kafka也好，NGIX也好，Java相關(guān)程序也好，試了各種方案以后，發(fā)現(xiàn)簡單的方法就是剛才說的這個情況，現(xiàn)在青島和北京兩個集群同時在轉(zhuǎn)。

第四，我的產(chǎn)品其實在兩邊也都在展示，用我們產(chǎn)品經(jīng)理、總監(jiān)能夠做到相關(guān)數(shù)據(jù)的核對比對，產(chǎn)品切換，數(shù)據(jù)兩端大數(shù)據(jù)接收的時候，已經(jīng)把它轉(zhuǎn)發(fā)成備份出來一模一樣的數(shù)據(jù)集群，對于新的產(chǎn)品集成來講非常容易。和原來的數(shù)據(jù)一模一樣，最終做切換的時候，大家只要把域名一改，這件事兒就搞定了。

第五，在這些風(fēng)險的情況下，我們可以把我們的風(fēng)險控制到最小，因為數(shù)據(jù)遷移當(dāng)中經(jīng)常遇到各種各樣的問題，遇到各種各樣的數(shù)據(jù)情況，我們怎么樣在大數(shù)據(jù)的情況下做一些大數(shù)據(jù)的治理，把它做質(zhì)量的優(yōu)化，這是以后的話題。

7、大數(shù)據(jù)遷移成果——易觀方舟：

因為易觀過去都是在做分析報告檢查，所以它把我們所有的移動客戶端分析報告做了分析模型，做了易觀方舟的東西，包括給移動開發(fā)者和相關(guān)的開發(fā)者提供大數(shù)據(jù)分析的云。

比如說，做運營分析，自己的月活、日活，做用戶畫像。應(yīng)用評級也是讓開發(fā)者來說，過去易觀都是做各種分析報告，其中一部分變成了能夠?qū)ｉT給開發(fā)者做分析的服務(wù)。

Q&A：

Q1：我簡單問一下，我來自大賣網(wǎng)，原數(shù)據(jù)剛才列過了，現(xiàn)在是自動化的嗎?因為數(shù)據(jù)量特別大，在做遷移的時候怎么去保證各層之間的關(guān)系?

A1：原數(shù)據(jù)剛才也提到了，它是易觀SDK在源源不斷的每個手機終端上面上傳數(shù)據(jù)，所以我們原數(shù)據(jù)沒有斷的原因就是通過程序，原來只是一個接收點，復(fù)制出來一個接收點，變成并行的接收點，原數(shù)據(jù)怎么沒有斷其實通過程序，兩邊同時收了這樣的一個數(shù)據(jù)在這里，而不是其中的一個點來收。

Q2：敏感數(shù)據(jù)或者說在傳輸過程中怎么控制它?

A2：其實原來SDK上傳的時候我們加密打包，在轉(zhuǎn)發(fā)的時候，原來那個包還沒有解開，還是密鑰的方式，原來在傳數(shù)據(jù)時候，我接收完的數(shù)據(jù)還沒有解開，從互聯(lián)網(wǎng)怎么傳到Kafka里面，從這個包傳到Kafka集群里，解密的都是在Kafka以后，在上層做的解密，原來SDK傳到云端接受器沒有發(fā)生變化，原來小包在傳，現(xiàn)在打成一個大文件，大文件里面還有小包的壓縮，再傳上來。

Q3：我是亞信數(shù)據(jù)的。如果是現(xiàn)在有一個企業(yè)里面有很多原始的數(shù)據(jù)，我想用易觀分析云，我把我的數(shù)據(jù)放上來以后，因為我會擔(dān)心數(shù)據(jù)是否能保密，怎么樣保證這個數(shù)據(jù)不會傳出去，因為你這個在公有云上。

A3：大家剛才也問到相關(guān)的問題，第一，我們剛才說的是混合云狀態(tài)，所有的數(shù)據(jù)在線下是自己獨立的物理集群;第二，現(xiàn)在我們目前對移動開發(fā)者的分析云的服務(wù)，企業(yè)這一級現(xiàn)在正在做，對于企業(yè)的敏感度怎么切分開，光從公有和私有云這件事兒，我的理解并不能夠保證企業(yè)自己安全性的問題，無論公有云還是私有云，在里面究竟怎么保證企業(yè)的安全性，它還是有問題的，因為整個來講還是公有云的，目前的一個方式逐步在做的是密鑰的方式，這個事情目前還在做的，我們給APP開發(fā)者做相關(guān)的服務(wù)。特別像傳統(tǒng)企業(yè)來講，我覺得市場的接受程度還是會有一段距離，傳統(tǒng)企業(yè)覺得針對公有云這件事情不是技術(shù)上的原因，而是他的理念和想法、市場接受程度有一個過程，這點還是需要等市場承受度再來做，我們面向移動互聯(lián)網(wǎng)這個行業(yè)。

Q4：現(xiàn)在貴陽市也在做政府的數(shù)據(jù)開放，貴陽用的是底層IaaS平臺是阿里云，政府還是擔(dān)心阿里云畢竟是商業(yè)公司，我了解情況，之前還有專線接到杭州為了方便，后來把專線掐掉了。我們國家對于大數(shù)據(jù)的法律跟不上，馬路非常擁堵，因為汽車發(fā)展太快了，我們也沒有看到有一些公司在法律數(shù)據(jù)方面能夠健全，政府也需要跟進的一方面內(nèi)容。

A4：非常同意你的觀點，因為對我們來說做大數(shù)據(jù)，大家都是做大的，原來老講一個字叫“道”，這個時候說不清道不明，得道多助，失道寡助，過了這個道的線，發(fā)現(xiàn)將來很多合作伙伴都不會幫助你，我們那時候原來在其他地方，有公司賣數(shù)據(jù)，你看把手機號給你，家庭住址，買什么東西什么都有，再也沒有給這個廠商合作過，過了這個線了，講道這個事在大數(shù)據(jù)環(huán)節(jié)里一定是要堅持的。

Q5：您好，是中國人壽的，因為我們過去也做過類似的數(shù)據(jù)遷移或者數(shù)據(jù)庫的轉(zhuǎn)換，非常痛苦，因為像我們這種傳統(tǒng)關(guān)系型數(shù)據(jù)庫，即使數(shù)據(jù)中心下載下來傳到北京，也是需要很長時間，非常理解您的痛苦。但是我也有一個問題，像您這么大的數(shù)據(jù)量，即使在帶寬非常寬的情況下，您遷移的時間用了多長?

A5：整個項目是三個半月。

Q6：從青島遷到北京?

A6：開展同步進行。

Q7：像這種情況，您當(dāng)時怎么沒有考慮，真的像最開始說的，直接把硬盤備份回來，坐飛機回來，這邊裝上都可以。

A7：數(shù)據(jù)同步這件事兒是其中的一步，因為我剛才提到，其實我們的數(shù)據(jù)格式也發(fā)生變化了，模型已經(jīng)變化了，哪怕我把原來的那個PB級數(shù)據(jù)考過來，中間也就是100個T原始數(shù)據(jù)一樣，再往上都不一樣了。

Q8：我們的數(shù)據(jù)結(jié)構(gòu)也變了?

A8：拿硬盤拷， 原來的數(shù)據(jù)在公有云上，公有云的硬盤是Openstack。

Q9：您的數(shù)據(jù)沒辦法備到某一臺機器上。

A9：雖然有很多臺機器，不知道這臺機器其實存在哪個物理機，有可能分散在三個物理機上。

Q10：您那個工具，最終來講應(yīng)該通過數(shù)據(jù)文件傳輸?shù)姆绞絺鞯奖本﹣淼模依斫獾氖荈TP也可以做這件事兒。

A10：我們也想過不靠譜， 協(xié)議可以FTP傳，文件序列、中間的容錯這些都不行，我忘了通過FTP還是通過什么傳了，這塊用哪個協(xié)議不重要，重要的在于咱們剛才的四層結(jié)構(gòu)，協(xié)議其實我覺得無所謂。

Q11：我剛才看您技術(shù)架構(gòu)里面有Spark里面，在您的技術(shù)架構(gòu)里面起什么作用?

A11：因為做數(shù)據(jù)來講，其實咱們會有底層的明細，有一些匯總，基于這些匯總，特別是易觀這種給分析師做一些的查詢，數(shù)據(jù)量非常大，如果做成在Hive上面查的話，特別慢，我們把這個數(shù)據(jù)已經(jīng)做成基本結(jié)構(gòu)化的數(shù)據(jù)了，它在做并行查詢的時候又有關(guān)聯(lián)，拿其他的工具現(xiàn)在目前看都不太方便。所以我們用的GP實現(xiàn)剛才說的這種查詢，包括產(chǎn)品里面的用戶畫像，自定義畫像這塊的查詢時限，通過GP來做的，通過Hive可能隔天了，或者反應(yīng)速度不會說分鐘級別了，我們原來也說怎么分鐘到秒，模糊計算的事兒，其他分享里面有時間再交流，那個方法再加速這個計算。

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