互聯(lián)網數(shù)據中心借鑒意義_20141211.pptx

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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