Google大数据技术架构探秘
Google是大數(shù)據(jù)時代的奠基者,其大數(shù)據(jù)技術(shù)架構(gòu)一直是互聯(lián)網(wǎng)公司爭相學(xué)習(xí)和 研究的重點,也是行業(yè)大數(shù)據(jù)技術(shù)架構(gòu)的標桿和示范。
1、谷歌的數(shù)據(jù)中心
谷歌已經(jīng)建立了世界上最快、最強大、最高質(zhì)量的數(shù)據(jù)中心,它的8個主要數(shù)據(jù)中心都遠離其位于加州山景城的總部,分別位于美國南卡羅來納州的伯克利郡,愛荷華州的康瑟爾布拉夫斯,喬治亞州的道格拉斯郡,俄克拉荷馬州的梅斯郡,北卡羅來納州的勒努瓦,俄勒岡州的達爾斯;另外2個在美國境外,分別是芬蘭的哈米納和比利時的圣吉斯蘭。此外,谷歌公司還在中國香港和中國臺灣,以及新加坡和智利建立了數(shù)據(jù)中心。
2、谷歌新一代搜索引擎平臺和大數(shù)據(jù)分析核心技術(shù)
Google是GFS MapReduce BigTable的締造者,但Google 新一代搜索引擎平臺正逐步用更強計算能力的系統(tǒng)來替換原有系統(tǒng),新一代搜索引擎平臺有幾個核心技術(shù)系統(tǒng):
一是用基于Percolator的增量處理索引系統(tǒng)來取代MapReduce批處理索引系統(tǒng),這個索引系統(tǒng)被稱作Caffeine,它比MapReduce批處理索引系統(tǒng)搜索更快。
二是專為BigTable設(shè)計的分布式存儲Colossus,也被稱為GFS2(二代Google文件系統(tǒng)),它專為建立Caffeine搜索索引系統(tǒng)而用。
三是列存儲數(shù)據(jù)庫BigTable,但為了更好地支持大數(shù)據(jù)集的互動分析,Google推出了Dremel和PowerDrill。Dremel被設(shè)計用來管理非常大量的大數(shù)據(jù)集(指數(shù)據(jù)集的數(shù)量和每數(shù)據(jù)集的規(guī)模都大),而PowerDrill則設(shè)計用來分析少量的大數(shù)據(jù)集(指數(shù)據(jù)集的規(guī)模大,但數(shù)據(jù)集的數(shù)量不多)時提供更強大的分析性能。
四是為Google Instant提供服務(wù)的實時搜索引擎存儲和分析架構(gòu)。
五是Pregel,這是谷歌更快捷的網(wǎng)絡(luò)和圖算法。
在谷歌新一代搜索引擎平臺上,每月40億小時的視頻,4.25億Gmail用戶,150,000,000 GB Web索引,卻能實現(xiàn)0.25秒搜索出結(jié)果。
3、谷歌基礎(chǔ)云服務(wù)
基于Colossus,谷歌為用戶提供計算、存儲和應(yīng)用的云服務(wù)。計算服務(wù)包括計算的引擎(ComputeEngine)和應(yīng)用APP的引擎(AppEngine);存儲服務(wù)包括云存儲(CloudStorge)、云SQL(CLoudSQL)、云數(shù)據(jù)存儲(Cloud DataStore)、永久磁盤等服務(wù);云應(yīng)用服務(wù)包括BigQuery、云終端(Cloud Endpoints)、緩沖、隊列等。
4、谷歌的大數(shù)據(jù)智能應(yīng)用服務(wù)
Google提供的大數(shù)據(jù)分析智能應(yīng)用包括客戶情緒分析、交易風(fēng)險(欺詐分析)、產(chǎn)品推薦、消息路由、診斷、客戶流失預(yù)測、法律文案分類、電子郵件內(nèi)容過濾、政治傾向預(yù)測、物種鑒定等多個方面。據(jù)稱,大數(shù)據(jù)已經(jīng)給Google每天帶來2300萬美元的收入。例如,一些典型應(yīng)用如下:
(1)基于Map Reduce,Google的傳統(tǒng)應(yīng)用包括數(shù)據(jù)存儲、數(shù)據(jù)分析、日志分析、搜索質(zhì)量以及其他數(shù)據(jù)分析應(yīng)用。
(2)基于Dremel系統(tǒng), Google推出其強大的數(shù)據(jù)分析軟件和服務(wù) — BigQuery,它也是Google自己使用的互聯(lián)網(wǎng)檢索服務(wù)的一部分。Google已經(jīng)開始銷售在線數(shù)據(jù)分析服務(wù),試圖與市場上類似亞馬遜網(wǎng)絡(luò)服務(wù)(Amazon Web Services)這樣的企業(yè)云計算服務(wù)競爭。這個服務(wù),能幫助企業(yè)用戶在數(shù)秒內(nèi)完成萬億字節(jié)的掃描。
(3)基于搜索統(tǒng)計算法,Google推出搜索引擎的輸寫糾錯、統(tǒng)計型機器翻譯等服務(wù)。
(4)Google的趨勢圖應(yīng)用。通過用戶對于搜索詞的關(guān)注度,很快的理解社會上的熱點是什么。對廣告主來說,它的商業(yè)價值就是很快的知道現(xiàn)在用戶在關(guān)心什么,他們應(yīng)該在什么地方投入一個廣告。據(jù)此,Google公司也開發(fā)了一些大數(shù)據(jù)產(chǎn)品,如“Brand Lift in Adwords”、“Active GRP”等,以幫助廣告客戶分析和評估其廣告活動的效率。
(5)Google Instant。輸入關(guān)鍵詞的過程,Google Instant 會邊打邊預(yù)測可能的搜索結(jié)果。
谷歌的大數(shù)據(jù)平臺架構(gòu)仍在演進中,追去的目標是更大數(shù)據(jù)集、更快、更準確的分析和計算。這將進一步引領(lǐng)大數(shù)據(jù)技術(shù)發(fā)展的方向。
Bingdata優(yōu)網(wǎng)助幫匯聚多平臺采集的海量數(shù)據(jù),通過大數(shù)據(jù)技術(shù)的分析及預(yù)測能力為企業(yè)提供智能化的數(shù)據(jù)分析、運營優(yōu)化、投放決策、精準營銷、競品分析等整合營銷服務(wù)。
北京優(yōu)網(wǎng)助幫信息技術(shù)有限公司(簡稱優(yōu)網(wǎng)助幫)是以大數(shù)據(jù)為基礎(chǔ),并智能應(yīng)用于整合營銷的大數(shù)據(jù)公司,隸屬于亨通集團。Bingdata是其旗下品牌。優(yōu)網(wǎng)助幫團隊主要來自阿里、騰訊、百度、金山、搜狐及移動、電信、聯(lián)通、華為、愛立信等著名企業(yè)的技術(shù)大咖,兼有互聯(lián)網(wǎng)與通信運營商兩種基因,為大數(shù)據(jù)的算法分析提供強大的技術(shù)支撐
一、大數(shù)據(jù)平臺
大數(shù)據(jù)在工作中的應(yīng)用有三種:
- 與業(yè)務(wù)相關(guān),比如用戶畫像、風(fēng)險控制等;
- 與決策相關(guān),數(shù)據(jù)科學(xué)的領(lǐng)域,了解統(tǒng)計學(xué)、算法,這是數(shù)據(jù)科學(xué)家的范疇;
- 與工程相關(guān),如何實施、如何實現(xiàn)、解決什么業(yè)務(wù)問題,這是數(shù)據(jù)工程師的工作。
數(shù)據(jù)工程師在業(yè)務(wù)和數(shù)據(jù)科學(xué)家之間搭建起實踐的橋梁。本文要分享的大數(shù)據(jù)平臺架構(gòu)技術(shù)選型及場景運用偏向于工程方面。
如圖所示,大數(shù)據(jù)平臺第一個要素就是數(shù)據(jù)源,我們要處理的數(shù)據(jù)源往往是在業(yè)務(wù)系統(tǒng)上,數(shù)據(jù)分析的時候可能不會直接對業(yè)務(wù)的數(shù)據(jù)源進行處理,而是先經(jīng)過數(shù)據(jù)采集、數(shù)據(jù)存儲,之后才是數(shù)據(jù)分析和數(shù)據(jù)處理。
從整個大的生態(tài)圈可以看出,要完成數(shù)據(jù)工程需要大量的資源;數(shù)據(jù)量很大需要集群;要控制和協(xié)調(diào)這些資源需要監(jiān)控和協(xié)調(diào)分派;面對大規(guī)模的數(shù)據(jù)怎樣部署更方便更容易;還牽扯到日志、安全、還可能要和云端結(jié)合起來,這些都是大數(shù)據(jù)圈的邊緣,同樣都很重要。
二、數(shù)據(jù)源的特點
數(shù)據(jù)源的特點決定數(shù)據(jù)采集與數(shù)據(jù)存儲的技術(shù)選型,我根據(jù)數(shù)據(jù)源的特點將其分為四大類:
- 第一類:從來源來看分為內(nèi)部數(shù)據(jù)和外部數(shù)據(jù);
- 第二類:從結(jié)構(gòu)來看分為非結(jié)構(gòu)化數(shù)據(jù)和結(jié)構(gòu)化數(shù)據(jù);
- 第三類:從可變性來看分為不可變可添加數(shù)據(jù)和可修改刪除數(shù)據(jù);
- 第四類,從規(guī)模來看分為大量數(shù)據(jù)和小量數(shù)據(jù)。
內(nèi)部數(shù)據(jù)
來自企業(yè)內(nèi)部系統(tǒng),可以采用主動寫入技術(shù)(push),從而保證變更數(shù)據(jù)及時被采集。
外部數(shù)據(jù)
企業(yè)要做大數(shù)據(jù)的話肯定不會只局限于企業(yè)內(nèi)部的數(shù)據(jù),比如銀行做征信,就不能只看銀行系統(tǒng)里的交易數(shù)據(jù)和用戶信息,還要到互聯(lián)網(wǎng)上去拉取外部數(shù)據(jù)。
外部數(shù)據(jù)分為兩類:
- 一類是要獲取的外部數(shù)據(jù)本身提供API,可以調(diào)用API獲取,比如微信;
- 另一類是數(shù)據(jù)本身不提供API,需要通過爬蟲爬取過來。
這兩類數(shù)據(jù)都不是我們可控制的,需要我們?nèi)カ@得,它的結(jié)構(gòu)也可能跟我們企業(yè)內(nèi)部數(shù)據(jù)的結(jié)構(gòu)不一樣,還需要進行轉(zhuǎn)換,爬蟲爬取的數(shù)據(jù)結(jié)構(gòu)更亂,因此大數(shù)據(jù)平臺里需要做ETL,由ETL進行數(shù)據(jù)提取、轉(zhuǎn)換、加載,清洗、去重、去噪,這個過程比較麻煩。爬蟲爬過來的數(shù)據(jù)往往是非結(jié)構(gòu)性的、文檔型的數(shù)據(jù),還有視頻、音頻,這就更麻煩了。
結(jié)構(gòu)化數(shù)據(jù) & 非結(jié)構(gòu)化數(shù)據(jù)
結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)在存儲時的選型完全不同,非結(jié)構(gòu)化數(shù)據(jù)偏向于文件,或者選擇NoSQL數(shù)據(jù)庫;考慮到事務(wù)的一致性,我們也可能選擇傳統(tǒng)的數(shù)據(jù)庫。
不變可添加數(shù)據(jù)
如果數(shù)據(jù)源的數(shù)據(jù)是不變的,或者只允許添加(通常,數(shù)據(jù)分析的事實表,例如銀行交易記錄等都不允許修改或刪除),則采集會變得非常容易,同步時只需要考慮最簡單的增量同步策略,維持數(shù)據(jù)的一致性也相對變得容易。
對于大數(shù)據(jù)分析來說,我們每天在處理的數(shù)據(jù)大部分是不可變更的。正如Datomic數(shù)據(jù)庫的設(shè)計哲學(xué)就是數(shù)據(jù)為事實(fact),它是不可變的,即數(shù)據(jù)是曾經(jīng)發(fā)生的事實,事實是不可以被篡改的,哪怕改一個地址,從設(shè)計的角度來說也不是改動一個地址,而是新增了一個地址。交易也是如此。
可修改可刪除數(shù)據(jù)
銀行的交易記錄、保險單的交易記錄,互聯(lián)網(wǎng)的訪客訪問記錄、下單記錄等都是不可變的。但是數(shù)據(jù)源的數(shù)據(jù)有些可能會修改或刪除,尤其是許多維表經(jīng)常需要變動。要對這樣的數(shù)據(jù)進行分析處理,最簡單的辦法就是采用直連形式,但直連可能會影響數(shù)據(jù)分析的效率與性能,且多數(shù)數(shù)據(jù)模型與結(jié)構(gòu)可能不符合業(yè)務(wù)人員進行數(shù)據(jù)分析的業(yè)務(wù)訴求。如果采用數(shù)據(jù)采集的方式,就要考慮同步問題。
大數(shù)據(jù)量
針對大數(shù)據(jù)量,如果屬于高延遲的業(yè)務(wù),可以采用batch的處理方式,實時分析則需要使用流式處理,將兩者結(jié)合就是Lambda架構(gòu),即有實時處理、又能滿足一定的大數(shù)據(jù)量,這是現(xiàn)在比較流行的大數(shù)據(jù)處理方式。
三、數(shù)據(jù)存儲的技術(shù)選型
大數(shù)據(jù)平臺特征:相同的業(yè)務(wù)數(shù)據(jù)會以多種不同的表現(xiàn)形式,存儲在不同類型的數(shù)據(jù)庫中,形成一種poly-db的數(shù)據(jù)冗余生態(tài)。
先把數(shù)據(jù)源進行分類,然后根據(jù)其特點判斷用什么方式采集,采集之后要進行存儲。數(shù)據(jù)存儲的技術(shù)選型依據(jù)有三點:
- 第一點取決于數(shù)據(jù)源的類型和采集方式。比如非結(jié)構(gòu)化的數(shù)據(jù)不可能拿一個關(guān)系數(shù)據(jù)庫去存儲。采集方式如果是流失處理,那么傳過來放到Kafka是最好的方式。
- 第二點取決于采集之后數(shù)據(jù)的格式和規(guī)模。比如數(shù)據(jù)格式是文檔型的,能選的存儲方式就是文檔型數(shù)據(jù)庫,例如MongoDB;采集后的數(shù)據(jù)是結(jié)構(gòu)化的,則可以考慮關(guān)系型數(shù)據(jù)庫;如果數(shù)據(jù)量達到很大規(guī)模,首選放到HDFS里。
- 第三點是分析數(shù)據(jù)的應(yīng)用場景。根據(jù)數(shù)據(jù)的應(yīng)用場景來判定存儲技術(shù)選型。
場景一:輿情分析
做輿情分析的時候客戶要求所有數(shù)據(jù)存放兩年,一天600多萬,兩年就是700多天×600多萬,幾十億的數(shù)據(jù)。而且爬蟲爬過來的數(shù)據(jù)是輿情,做了分詞之后得到的可能是大段的網(wǎng)友評論,客戶要求對輿情進行查詢,做全文本搜索,并要求響應(yīng)時間控制在10s以內(nèi)。
我們后來選擇用ES,在單機上做了一個簡單的測試,大概三億多條數(shù)據(jù),用最壞的查詢條件進行搜索,保證這個搜索是全表搜索(基于Lucence創(chuàng)建了索引,使得這種搜索更高效),整個查詢時間能控制在幾秒以內(nèi)。
如圖所示,爬蟲將數(shù)據(jù)爬到Kafka里,在里面做流處理,去重去噪做語音分析,寫到ElasticSearch里。我們做大數(shù)據(jù)的一個特點是多數(shù)據(jù)庫,會根據(jù)不同的場景選擇不同的數(shù)據(jù)庫,所以會產(chǎn)生大量的冗余。
場景二:商業(yè)智能產(chǎn)品
BI產(chǎn)品主要針對數(shù)據(jù)集進行的數(shù)據(jù)分析以聚合運算為主,比如求合、求平均數(shù)、求同比、求環(huán)比、求其他的平方差或之類的標準方差。我們既要滿足大數(shù)據(jù)量的水平可伸縮,又要滿足高性能的聚合運算。選擇Parquet列式存儲,可以同時滿足這兩個需求。
場景三:Airbnb的大數(shù)據(jù)平臺
Airbnb的大數(shù)據(jù)來自兩塊:一是本身的業(yè)務(wù)數(shù)據(jù),二是大量的事件。數(shù)據(jù)源不同,采集方式也不一樣。日志數(shù)據(jù)通過發(fā)送Kafka事件,而線上數(shù)據(jù)則通過Sqoop同步。數(shù)據(jù)存儲選擇HDFS集群,然后通過Presto對Hive表執(zhí)行即席查詢。S3是一個獨立的存儲系統(tǒng)。
四、數(shù)據(jù)處理
數(shù)據(jù)處理分為三大類:
- 第一類是從業(yè)務(wù)的角度,細分為查詢檢索、數(shù)據(jù)挖掘、統(tǒng)計分析、深度分析,其中深度分析分為機器學(xué)習(xí)和神經(jīng)網(wǎng)絡(luò)。
- 第二類是從技術(shù)的角度,細分為Batch、SQL、流式處理、machine learning、Deep learning。
- 第三類是編程模型,細分為離線編程模型、內(nèi)存編程模型、實時編程模型。
結(jié)合前文講述的數(shù)據(jù)源特點、分類、采集方式、存儲選型、數(shù)據(jù)分析、數(shù)據(jù)處理,我在這里給出一個總體的大數(shù)據(jù)平臺的架構(gòu)。值得注意的是,架構(gòu)圖中去掉了監(jiān)控、資源協(xié)調(diào)、安全日志等。
左側(cè)是數(shù)據(jù)源,有實時流的數(shù)據(jù)(可能是結(jié)構(gòu)化、非結(jié)構(gòu)化,但其特點是實時的),有離線數(shù)據(jù),離線數(shù)據(jù)一般采用的多為ETL的工具,常見的做法是在大數(shù)據(jù)平臺里使用Sqoop或Flume去同步數(shù)據(jù),或調(diào)一些NIO的框架去讀取加載,然后寫到HDFS里面,當(dāng)然也有一些特別的技術(shù)存儲的類型,比如HAWQ就是一個支持分布式、支持事務(wù)一致性的開源數(shù)據(jù)庫。
從業(yè)務(wù)場景來看,如果我們做統(tǒng)計分析,就可以使用SQL或MapReduce或streaming或Spark。如果做查詢檢索,同步寫到HDFS的同時還要考慮寫到ES里。如果做數(shù)據(jù)分析,可以建一個Cube,然后再進入OLAP的場景。
這個圖基本上把所有的內(nèi)容都涵蓋了,從場景的角度來分析倒推,用什么樣的數(shù)據(jù)源、采用什么樣的采集方式、存儲成什么樣子,能滿足離線、內(nèi)存、實時、流的各種模型,都能從圖中得到解答.
大數(shù)據(jù)時代的數(shù)據(jù)中心平臺架構(gòu)圖
總結(jié)
以上是生活随笔為你收集整理的Google大数据技术架构探秘的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 5G时代谁的天下???
- 下一篇: 主流大数据平台及解决方案对比