互聯(lián)網數(shù)據(jù)中心借鑒意義_20141211.pptx_第1頁
互聯(lián)網數(shù)據(jù)中心借鑒意義_20141211.pptx_第2頁
互聯(lián)網數(shù)據(jù)中心借鑒意義_20141211.pptx_第3頁
互聯(lián)網數(shù)據(jù)中心借鑒意義_20141211.pptx_第4頁
互聯(lián)網數(shù)據(jù)中心借鑒意義_20141211.pptx_第5頁
免費預覽已結束,剩余12頁可下載查看

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、BAT三大巨頭開發(fā)大數(shù)據(jù),大數(shù)據(jù) 分析處理,數(shù)據(jù)如同蘊藏能量的煤礦。大數(shù)據(jù)并不在“大”,而在于“有用”。價值含量、挖掘成本比數(shù)量更為重要。,百度,兩大類型數(shù)據(jù): 用戶搜索表征的需求數(shù)據(jù) 爬蟲和阿拉丁獲取的公共web數(shù)據(jù),含著數(shù)據(jù)出生且用于挖掘技術, 研究和實用結合!,BAT三大巨頭開發(fā)大數(shù)據(jù),大數(shù)據(jù) 分析處理,數(shù)據(jù)如同蘊藏能量的煤礦。大數(shù)據(jù)并不在“大”,而在于“有用”。價值含量、挖掘成本比數(shù)量更為重要。,百度,交易數(shù)據(jù)&信用數(shù)據(jù)更易變現(xiàn),挖掘商業(yè)價值 通過投資等方式掌握部分社交數(shù)據(jù)、移動數(shù)據(jù),如微博和高德,坐擁“金”數(shù)據(jù)! 嘗試做面向未來的數(shù)據(jù)集市,阿里,BAT三大巨頭開發(fā)大數(shù)據(jù),大數(shù)據(jù) 分析

2、處理,數(shù)據(jù)如同蘊藏能量的煤礦。大數(shù)據(jù)并不在“大”,而在于“有用”。價值含量、挖掘成本比數(shù)量更為重要。,百度,用戶關系數(shù)據(jù)和基于此產生的社交數(shù)據(jù) 可以分析人們的生活和行為,從里面挖掘出政治、社會、 文化、商業(yè)、健康等領域的信息,甚至預測未來。,數(shù)據(jù)為產品所用,自產自銷!,阿里,騰訊,騰訊數(shù)據(jù)平臺,案例一:騰訊數(shù)據(jù)平臺,CDG,IEG,MIG,OMG,SNG,TEG,WXG,在線消息,離線消息,DB-Binlog,TDBank-實時數(shù)據(jù)接入平臺,格式適配,數(shù)據(jù)傳輸,加密傳輸,消息緩存,緩存分發(fā),訂閱分發(fā),6000億 接入消息/天 150TB 接入數(shù)據(jù)量/天 10,000個 并發(fā)分揀業(yè)務接口 1-2

3、s 采集平均時延 99.999% 可用度,TRC-實時計算,實時計算,存儲引擎,1000億 支撐應用請求量/天 15,000億 多維度交叉計算量/天 10,000個 并發(fā)分揀業(yè)務接口 50ms 請求延遲/次 21億 應用引擎訪問數(shù)據(jù)次數(shù)/秒,TDW-分布式數(shù)據(jù)倉庫,查詢引擎,計算引擎,存儲引擎,6000臺 單集群服務器 140,000核 CPU 380TB 內存 72,000塊 磁盤 100PB 存儲容量 1,000,000+ Job數(shù)/天,TPR-精準推薦,實時精準推薦平臺,180+ 億 效果廣告精準推薦 量/天 2億+ 視頻精準推薦量/天 1億+ 新聞精準推薦量/天,TDBank構建數(shù)據(jù)源

4、和數(shù)據(jù)處理系統(tǒng)間的橋梁,將數(shù)據(jù)處理系統(tǒng)同數(shù)據(jù)源解耦,為離線計算TDW和在線計算TRC平臺提供數(shù)據(jù)支持。 通過不斷的改進,將以前Linux+HDFS的模式,轉變?yōu)榧?分布式消息隊列的模式,將以前一天才能處理的消息量縮短到2秒鐘! 提供數(shù)據(jù)主動訂閱模式,以及不同的數(shù)據(jù)分發(fā)支持。整個數(shù)據(jù)通路透明化,只需簡單配置,即可實現(xiàn)一點接入,整個大數(shù)據(jù)平臺可用。,案例一:騰訊數(shù)據(jù)平臺,CDG,IEG,MIG,OMG,SNG,TEG,WXG,在線消息,離線消息,DB-Binlog,TDBank-實時數(shù)據(jù)接入平臺,格式適配,數(shù)據(jù)傳輸,加密傳輸,消息緩存,緩存分發(fā),訂閱分發(fā),6000億 接入消息/天 150TB 接

5、入數(shù)據(jù)量/天 10,000個 并發(fā)分揀業(yè)務接口 1-2s 采集平均時延 99.999% 可用度,TRC-實時計算,實時計算,存儲引擎,1000億 支撐應用請求量/天 15,000億 多維度交叉計算量/天 10,000個 并發(fā)分揀業(yè)務接口 50ms 請求延遲/次 21億 應用引擎訪問數(shù)據(jù)次數(shù)/秒,TDW-分布式數(shù)據(jù)倉庫,查詢引擎,計算引擎,存儲引擎,6000臺 單集群服務器 140,000核 CPU 380TB 內存 72,000塊 磁盤 100PB 存儲容量 1,000,000+ Job數(shù)/天,TPR-精準推薦,實時精準推薦平臺,180+ 億 效果廣告精準推薦 量/天 2億+ 視頻精準推薦量/

6、天 1億+ 新聞精準推薦量/天,TRC:基于在線消息流的實時計算模型,對海量數(shù)據(jù)進行實時采集、流式計算、實時存儲、實時展示的全流程實時計算體系。 核心技術:Java for Storm、Storm on Gaia、PigLatin/SQL on Storm 應用場景:精準推薦、實時分析、實時監(jiān)控,案例一:騰訊數(shù)據(jù)平臺,CDG,IEG,MIG,OMG,SNG,TEG,WXG,在線消息,離線消息,DB-Binlog,TDBank-實時數(shù)據(jù)接入平臺,格式適配,數(shù)據(jù)傳輸,加密傳輸,消息緩存,緩存分發(fā),訂閱分發(fā),6000億 接入消息/天 150TB 接入數(shù)據(jù)量/天 10,000個 并發(fā)分揀業(yè)務接口 1-

7、2s 采集平均時延 99.999% 可用度,TRC-實時計算,實時計算,存儲引擎,1000億 支撐應用請求量/天 15,000億 多維度交叉計算量/天 10,000個 并發(fā)分揀業(yè)務接口 50ms 請求延遲/次 21億 應用引擎訪問數(shù)據(jù)次數(shù)/秒,TDW-分布式數(shù)據(jù)倉庫,查詢引擎,計算引擎,存儲引擎,6000臺 單集群服務器 140,000核 CPU 380TB 內存 72,000塊 磁盤 100PB 存儲容量 1,000,000+ Job數(shù)/天,TPR-精準推薦,實時精準推薦平臺,180+ 億 效果廣告精準推薦 量/天 2億+ 視頻精準推薦量/天 1億+ 新聞精準推薦量/天,TDW完成了對騰訊公

8、司內部幾乎全業(yè)務的覆蓋,成為騰訊最大的離線處理平臺。 基于開源軟件Hadoop和Hive進行構建,并且根據(jù)公司數(shù)據(jù)量大、計算復雜等特定情況進行了大量優(yōu)化和改造。 它支持百PB級數(shù)據(jù)的離線存儲和計算,為業(yè)務提供海量、高效、穩(wěn)定的大數(shù)據(jù)平臺支撐和決策支持。,案例一:騰訊數(shù)據(jù)平臺,CDG,IEG,MIG,OMG,SNG,TEG,WXG,在線消息,離線消息,DB-Binlog,TDBank-實時數(shù)據(jù)接入平臺,格式適配,數(shù)據(jù)傳輸,加密傳輸,消息緩存,緩存分發(fā),訂閱分發(fā),6000億 接入消息/天 150TB 接入數(shù)據(jù)量/天 10,000個 并發(fā)分揀業(yè)務接口 1-2s 采集平均時延 99.999% 可用度,

9、TRC-實時計算,實時計算,存儲引擎,1000億 支撐應用請求量/天 15,000億 多維度交叉計算量/天 10,000個 并發(fā)分揀業(yè)務接口 50ms 請求延遲/次 21億 應用引擎訪問數(shù)據(jù)次數(shù)/秒,TDW-分布式數(shù)據(jù)倉庫,查詢引擎,計算引擎,存儲引擎,6000臺 單集群服務器 140,000核 CPU 380TB 內存 72,000塊 磁盤 100PB 存儲容量 1,000,000+ Job數(shù)/天,TPR-精準推薦,實時精準推薦平臺,180+ 億 效果廣告精準推薦 量/天 2億+ 視頻精準推薦量/天 1億+ 新聞精準推薦量/天,以人為核心的數(shù)據(jù)挖掘,提供“海量、精準、實時”的個性化推薦服務。

10、 應用場景:用戶畫像的建立是精準推薦的基礎、以效果廣告為代表的準確營銷、以視頻推薦為代表的內容推薦、以電商推薦為代表的購物推薦,案例二:淘寶數(shù)據(jù)平臺,MyFox-分布式MySQL集群 海量數(shù)據(jù)分布式存儲、非實時寫入 提供全鏡像、路由字段、記錄條數(shù)、組合等分片規(guī)則 跨機房互備,Prom實時計算 用冗余避免網絡傳輸和隨機讀 實時計算分析 定制化的存儲,Glider高性能異構數(shù)據(jù)中間層 整合多種數(shù)據(jù) 底層架構對前端透明 水平可擴展性 內置二級緩存,關系型數(shù)據(jù)庫仍然是王道,NoSQL是SQL的有益補充,用中間層隔離前后端,緩存是系統(tǒng)化的工程,案例二:淘寶數(shù)據(jù)平臺,銀河-實時流處理平臺 基于Actor模

11、型的分布式流數(shù)據(jù)實時處理和計算框架 底層基于開源軟件AKKA實現(xiàn) 消息即數(shù)據(jù) 日處理3億數(shù)據(jù)量,運營商的數(shù)據(jù)源特點,運營商數(shù)據(jù)源表,互聯(lián)網企業(yè)的數(shù)據(jù)及數(shù)據(jù)處理以非結構化為主,數(shù)據(jù)結構:隨著流量經營以及與OTT業(yè)務的交叉經營等新型商業(yè)模式的成熟和發(fā)展,逐步會增加非結構化數(shù)據(jù)以及混合結構數(shù)據(jù)的比重。 使用模式: 目前電信運營商對數(shù)據(jù)的應用仍以精確性計算分析為主,隨著精細化營銷的深入,分眾營銷的實施,趨勢性計算分析逐步會得到應用和發(fā)展。,發(fā)展趨勢,而電信運營商的數(shù)據(jù)及數(shù)據(jù)處理仍然是以結構化為主;,運營商的大數(shù)據(jù)架構選擇分析,數(shù)據(jù)分析的發(fā)展線路有兩種: 傳統(tǒng)的BI為代表的發(fā)展線路 互聯(lián)網企業(yè)為代表的數(shù)

12、據(jù)分析發(fā)展線路,電信運營商在數(shù)據(jù)源、數(shù)據(jù)分布、數(shù)據(jù)分析等方面均有較高的要求,故大數(shù)據(jù)的技術架構選擇上必然面臨更多的約束條件,單一技術將無法兼顧對效率、精確性、數(shù)據(jù)量等諸多方面的限制。 數(shù)據(jù)量較小,訪問頻次較大,訪問實時性要求低 如:報表分析應用 原有的BI系統(tǒng)適用 數(shù)據(jù)量大,訪問頻次不高 如:話單查詢等應用 原有的BI技術已不能滿足需求 數(shù)據(jù)量大,訪問實時性要求高 如:精細化營銷和分眾業(yè)務推薦等應用 需要進行趨勢化分析,電信運營商的大數(shù)據(jù)平臺是一種混搭的架構模式,實現(xiàn)一個統(tǒng)一平臺,集中5大類數(shù)據(jù)。需要對MPP數(shù)據(jù)庫、Hadoop和流數(shù)據(jù)處理做深度融合,形成大數(shù)據(jù)整合架構,并針對特殊應用場景,選

13、擇內存數(shù)據(jù)庫、列存數(shù)據(jù)庫作為補充,滿足實時流式的數(shù)據(jù)服務和應用的觸發(fā)。,“SMP+MPP+Hadoop+內存數(shù)據(jù)庫、流處理”的混搭架構,不僅能夠適應大數(shù)據(jù)的“4V”特征,并且能滿足多樣化應用場景需求。,大數(shù)據(jù)整合服務平臺層:“SMP+MPP+Hadoop+流處理”的混搭結構 IaaS層(PB級計算):“內存+多核計算、計算與數(shù)據(jù)處理一體化、MPP/Hadoop+X86”的低成本海量分布結構 計算資源、存儲資源必須池化 兼并其他技術以降本增效,運營商如何選擇技術適用場景,互聯(lián)網啟發(fā)一:如何用大數(shù)據(jù),既然未來企業(yè)里面肯定會有多種數(shù)據(jù)源,多種數(shù)據(jù)庫結構,那么是否可以建立一個中間的數(shù)據(jù)服務層,把應用和

14、底層數(shù)據(jù)庫架構隔離開呢?,什么樣的數(shù)據(jù),用哪種方式存儲效率最高,處理起來最快就用哪種方式。 能直接在文件系統(tǒng)上做的就不放到數(shù)據(jù)庫里。 數(shù)據(jù)的分析也是如此,結構層次越少越好,數(shù)據(jù)訪問越直接越好,能用編程語言直接解決的問題就堅決不采用數(shù)據(jù)倉庫用SQL。 該用SQL解決的問題也不去為了統(tǒng)一接口而再去跑一遍Java或Python。 一切以高效直接為前提,充分貫徹“把支部建到連隊里”的核心思想,發(fā)揮小快靈的優(yōu)勢。,互聯(lián)網:簡潔、直接,以Hadoop舉例,很多互聯(lián)網或者發(fā)行版都開始嘗試放棄Map/Reduce直接對HDFS進行操作處理,其思想就是想更直接,更簡潔。 “建立一個數(shù)據(jù)服務層”還是傳統(tǒng)企業(yè)的舊思

15、路老方法,希望通過建立中間層減少開發(fā)移植難度,其實結果就是發(fā)揮不出大數(shù)據(jù)架構本身的性能和規(guī)模優(yōu)勢,限制住了技術架構本書身的發(fā)展空間。,中間服務層的限制性,對大數(shù)據(jù)應用最成熟的互聯(lián)網做法:,問題,借鑒,難度大,不現(xiàn)實,互聯(lián)網啟發(fā)二:架構6大理念,Google 系統(tǒng)架構可以大致分成三層: 產品應用層:搜索,廣告,電子郵件,地圖,視頻,聊天,博客 基礎設施層:GFS,MapReduce和BigTable 計算平臺層:分布在一堆不同的數(shù)據(jù)中心中一堆機器 擅長平臺的建構 自動自動還是自動,可擴展性系統(tǒng)之王,擴展需要多次的迭代 保持簡單:不重復設計一個方案 -優(yōu)化PHP,完成PHP到C+轉換 針對工作選正

16、確的工具,并接受所帶來的開銷 -選用LAMP,LAMP+Service,開放的力量,Cache!Cache!成功關鍵 GeoDNS-面向各個國家、各個地域 驚人的高效 -運營這樣的站點,WikiPedia 每年的開支是 200 萬美元,技術人員只有 6 個,驚人的高效。,使用SOA架構都是松耦合的,并且圍繞著服務建立。 根據(jù)場景在數(shù)據(jù)的一致性和數(shù)據(jù)的可用性之間做取舍 擁抱失敗 -建立一個自我修復、自我組織、無人值守類型的操作。 只用你需要的: -讓設計保持簡單,確定設計中沒有隱藏的需求及依賴性。 根據(jù)客戶的反饋來指定決策 擴展性即競爭優(yōu)勢 -快速推出新服務,松耦合架構,不難發(fā)現(xiàn),這些互聯(lián)網公司

17、的系統(tǒng)架構都有以下共同的6大理念 : 保持簡單隨著時間推移,復雜性會自然出現(xiàn)。 自動化一切包括災難恢復。 不斷迭代想擴展到更高水平?必須準備好忍痛棄用現(xiàn)在能工作的某個組件。 選擇合適的工具但也不怕自己動手打造。 使用緩存在適當?shù)牡胤健?根據(jù)場景,在數(shù)據(jù)的一致性和可用性之間做取舍。,互聯(lián)網啟發(fā)三:怎樣向大數(shù)據(jù)架構遷移,首先找個方案,把你準備分析處理的數(shù)據(jù)用新的辦法存起來,然后再試著在上面做些簡單的查詢,比較之類的應用,看看效果好不好 如果效果好了,那么再試著在這上面實現(xiàn)新的業(yè)務應用場景,解決一部分業(yè)務人員的某些實際需求;效果好的話再試著做第二個應用,第三個分析,慢慢的讓越來越多人看到這些新數(shù)據(jù)新

18、應用的價值。,一、先把大數(shù)據(jù)存起來,用起來,把舊的應用分析運行在新的大數(shù)據(jù)平臺上。把數(shù)據(jù)從原先的RDBMS數(shù)據(jù)源抽取到新的大數(shù)據(jù)平臺上,利用新的大數(shù)據(jù)分析方法實現(xiàn)傳統(tǒng)的業(yè)務分析邏輯。這么做有可能會分析更多的數(shù)據(jù)產生更好的分析結果,也有可能會發(fā)現(xiàn)效率還不如原先的RDBMS方案。 把大數(shù)據(jù)平臺上的數(shù)據(jù)抽取到舊有數(shù)據(jù)倉庫中分析展現(xiàn)。這個方向主要還是為了保證舊有用戶的SQL使用習慣,區(qū)別是抽入舊數(shù)據(jù)倉庫的不是外部表,而是經過清洗整理的有價值的數(shù)據(jù)。 通過這兩個方面的嘗試,基本就可以把哪些應用可以遷移,哪些不可以遷移搞清楚了。為下一步打下基礎。礎。,二、考慮將新的大數(shù)據(jù)平臺和原有數(shù)據(jù)平臺的互通,聯(lián)合問題。,整合數(shù)據(jù)源,把將會涉及到的各類型數(shù)據(jù)分類,用各自最合適的方法儲存起來整理好。 把應用、展現(xiàn)工具根據(jù)所涉及數(shù)據(jù)源的不同,應用場景的差異,和不同的數(shù)據(jù)存儲架構做耦合,定制化應用場景,使每個應用都可以充分利用到底層架構的性能和擴展能力。對于需要跨數(shù)據(jù)源的應用場景,選定中間處理層方案,保證中間處理層方案的定制化,不會因其存在影響底層架構的性能和上層分析應用的實現(xiàn)。 這種思路屬于互

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論