網贏中國專注大數據營銷 [會員登錄][免費注冊][網贏中國下載]我要投稿|加入合伙人|設為首頁|收藏|RSS
網贏中國是大數據營銷代名詞。
大數據營銷
當前位置:網贏中國 > 行業資訊 > 解決方案 > 大數據營銷解決方案 > 5大架構:細數數據平臺的組成與擴展
5大架構:細數數據平臺的組成與擴展
編輯:溫情 發布時間: 2015-9-16 11:40:22    文章來源:網贏中國
大數據營銷

 蔡延亮,北京大學計算機碩士畢業,明略數據技術合伙人。專注于大數據解決方案的研發和實施,擁有豐富的大數據分析平臺建設實施經驗。熟悉商務智能(BI)系統的設計、架構和演進規劃,擅長其在電信運營商的應用;在數據ETL處理、模型設計、數據備份、生命周期管理、安全管理等領域有豐富的實踐經驗;熟悉數據挖掘、機器學習等分析算法和工程應用;熟悉軟件項目管理。

  導讀:One size does not fit all! 數據處理平臺已不集中于傳統關系型數據庫,各種其他平臺層出不窮,也各有其適用范圍。


  從哪些角度去理解各種數據處理平臺的設計思想及發展演進呢?下面我們從幾個角度討論一下:


  一、單機存儲引擎設計(數據的位置)


  從某種意義上說,當我們處理數據的時候,實際上是在管理數據的位置,管理數據在CPU的位置,數據相對其他數據的位置。CPU特別適合處理順序性操作數據指令,這樣他可以進行數據預取。但是隨機讀取操作使得預取功能幾乎失效,好多預取到緩存、前端總線的數據都是無效的。


  傳統意義上說,磁盤的存取性能要弱于內存,但是要分隨機存取及順序存取不同的場景下討論。在流式順序處理場景,磁盤及SSD的讀取速度已經超過內存隨機讀取速度。


  我們如何盡量實現數據的順序存取呢?讓我們設計一個很簡單的數據庫開始,存取一個文件。


  1、數據存儲和更新


  追加寫可以讓我們盡量保持順序存儲文件。但是當數據要進行更新的時候,有兩種選擇,一種是在數據原地進行更新操作,這樣我們就有了隨機IO操作。另一種是把更新都放到文件末尾,然后需要讀取更新數據的時候進行替換。


  2、數據讀取


  一下子讀取整個文件,也是很耗費時間的事情,例如數據庫中的全表掃描。當我們讀取文件中某一個字段時候,我們需要索引。索引的方式有多種,我們可以用一種簡單的固定數值大小的有序數組來做索引,數組里存的是當前數據在文件中的存儲偏移量。還有其他索引技術,如hash索引,位圖索引等。


  索引相當于在數據之上又加了一層樹狀結構,可以迅速的讀取數據。但是打破了我們前面講的數據的追加寫,這些數據都是根據索引隨機寫入的。在數據庫上建立索引的時候都會遇到這個問題,在傳統的機械式磁盤上,這個問題會造成1000倍的性能差異。


  有三種方法可以解決上述問題:


  1)把索引放到內存中,可以隨機存儲和讀取,把數據順序存儲到硬盤上。MongoDB,Cassandra都是采取這種方式。這種方式有一個弊端是存儲的數據量受限于內存的大小,數據量一大,索引也增大,數據就飽和了。


  2)第二種方式是把大的索引結構,拆成很多小的索引來存儲。在內存中批量進來的數據,當積累到一個預定的量,就排序然后順序寫到磁盤上,本身就是一個小的索引,數據存儲完,最后加一塊小的全局索引數據即可。這樣讀取數據的時候,要遍歷一些小的索引,會有隨機讀取。本質是用部分小的隨機讀換取了整體的數據順序存儲。我們通過在內存中保存一個元索引或者Bloom filter來實現處理那些小索引的低延遲。


  日志結構的歸并樹(log structed merge tree, 簡稱LSM tree)是一種典型的實現,有三個特征:


  a)一組小的、不變的索引集。


  b)只能追加寫 ,合并重復的文件。


  c)少量的內存索引消耗換來讀取的性能提升。這是一種寫優化索引結構。


  HBase、Cassandra、Bigtable都是通過這種比較小的內存開銷來實現讀取和存儲的平衡


  3)列式存儲或者面向列的存儲(暴力方式)。


  純列式存儲和谷歌bigtable那種列式存儲還是有所不同的,大家最好分開來看,雖然占用了同一個名字。列式存儲很好理解,就是把數據按照列順序存儲到文件中,讀取的時候只讀需要的列。列式存儲需要保持每一列數據都有相同的順序,即行N在每一列都有相同的偏移。這很重要,因為同一查詢中可能要返回多個列的數據,同時可能我們要對多列直接進行連接。每一列保持同樣的順序我們可以用非常簡單的循環實現上述操作,且都是高效的CPU和緩存操作。


  列式存儲的缺點是更新數據的時候需要更新每一個列文件中的相應數據,一個常用的方法就是類似LSM那種批量內存寫的方式。


  當查詢只是返回某幾列數據,列式存儲可以大規模減少磁盤IO。除此之外,列式存儲的數據往往屬于同一類型,可以進行高效的壓縮,一些低延遲,高壓縮率的掃描寬度、位填充算法都試用。即使對于未壓縮的數據流,同時可以進行針對其編碼格式的預取。


  列式存儲尤其適用于大表掃描,求均值、最大最小值、分組等聚合查詢場景。


  列式存儲天然的保持了一列中數據的順序性,方便兩列數據進行關聯,而heap-file index結構關聯時候,一份數據可以按順序讀取,則另一份數據就會有隨機讀取了。


  典型優勢總結:


  列式壓縮,低IO


  列中每行數據保持順序,可以按照行id進行關聯合并


  壓縮后的數據依然可以進行預取


  數據延遲序列化


  上面討論的數據順序存取的幾種方案,在很多數據處理平臺的最優技術方案中大都有參考。


  通過heap-file結構把索引存儲在內存,是很多NoSQL數據庫及一些關系型數據庫的首選,例如Riak,CouchBase和MongoDB,模型簡單并且運行良好。


  要處理更大量的數據,LSM技術應用更為廣泛,提供了同時滿足高效存儲和讀取效率的基于磁盤的存取結構。HBase、Cassandra、RocksDB, LevelDB,甚至MongoDB最新版也支持這種技術。


  列式存儲在MPP數據庫里面應用廣泛,例如RedShift、Vertica及hadoop上的Parquet等。這種結構適合需要大表掃描的數據處理問題,數據聚合類操作(最大最小值)更是他的主戰場。


  Kafka 通過追加式的文件或者預定義的offset集來存儲消息隊列。你來消費消息,或者重新消費消息都是很高效的順序IO操作。這和其他的消息中間件架構上有所不同,JMS和AMQP都需要上面提到過的額外的索引來管理選擇器和session信息。他們最終性能表現像一個數據庫而非文件。


  為滿足讀和寫不同業務場景的優化,以上這些技術多少都有某些方面的折中,或者把問題簡化,或者需要硬件支持,作為一種拓展的方法。


  二、分布式集群存儲設計(并行化)


  把數據放到分布式集群中運算,有兩點最為重要:分區(partition)和副本(replication)。


  分區又被稱為sharding,在隨機訪問和暴力掃描任務下都表現不錯。


  通過hash函數把數據分布到多個機器上,很像單機上使用的hashtable,只不過這兒每一個數據桶都被放到了不同的機器上。


  這樣可以通過hash函數直接去存儲數據的機器上把數據取出來,這種模式有很強的擴展性,也是唯一可以根據客戶端請求數線性擴展的模式。請求會被獨立分發到某一機器上單獨處理。


  我們通過分區可以實現批量任務的并行化,例如聚合函數或者更復雜的聚類或者其他機器學習算法,我們通過廣播的方式在所有機器上使任務同時執行。我們還可以運行分治策略來使得高計算的任務在一個更短的時間內解決。


  這種批處理系統在處理大型的計算問題時有不錯的效果,但只能提供有限并發,,因為執行任務時會非常消耗集群的資源。


  所以分區方式在兩個極端情況非常簡單:


  直接hash訪問


  廣播,然后分而治之。在這兩種情況之間還有中間地帶,那就是在NoSQL數據庫中常用的二級索引技術。


  二級索引是指不是構建在主鍵上的索引,意味著數據不會因為索引的值而進行分區。不能直接通過hash函數去路由到數據本身。我們必須把請求廣播到所有節點上,這樣會限制了并發性,每一個請求都會卷入所有的節點。


  因此好多基于key-value的數據庫拒絕引入二級索引,雖然它很有價值,例如Hbase和Voldemort。 也有些數據庫系統包含它了,因為它有用,例如Cassandra、MongoDB、Riak等。重要的是我們要理解好他的效益及他對并發性所造成的影響。


  解決上述并發性瓶頸的一個途徑是數據副本,例如異步從數據庫和Cassandra、MongoDB中的數據副本。


  實際上副本數據可以是透明的(只是數據恢復時候使用)、只讀的(增加讀的并發性),可讀寫的(增加分區容錯性)。這些選擇都會對系統的一致性造成影響,這是CAP理論中的一個研究課題(也許CAP理論不像你想象中的那么簡單)。


  這些對一致性的折中,給我們帶來一個值得思考的問題?一致性到底有什么用?


  實現一致性的代價非常昂貴。在數據庫中是用串行化來保證ACID的。他的基本保證是所有操作都是順序排列的。這樣實現起來的代價非常昂貴,所以好多關系型數據庫也不把他當成默認選項。


  所以說要想在包含分布式寫操作的系統上實現強一致性,如同墜入深淵。(補充說明,Consistency, 在ACID和CAP中同時出現,但是意義不一樣,我這兒說的是在CAP中的定義:所有的節點在同一時間看到的是同樣的數據)


  解決一致性問題的方案也很簡單,避免他。假如不能避免它把他隔離到盡可能少的寫入和盡可能少的機器上。


  避免一致性問題其實很簡單,尤其是你的數據是一串不再改變的事實描述。web日志就是一個很好的例子,不用擔心一致性問題,因為日志存下來后就是不變的事實描述。


  當然有些業務場景是必須要保證數據一致性的,例如銀行轉賬時候。有些業務場景感覺上是必須保持一致性的,但實際上不是,例如標記一個交易是否有潛在的欺詐,我們可以先把它更新到一個新的字段里面,另外再用一條單獨的記錄數據去關聯最開始的那個交易。


  所以對一個數據平臺來說有效的方式是去避免或者孤立需要一致性的請求,一種孤立的方法是采取單一寫入者的策略,Datamic就是典型的例子。另一種物理隔離的方法就是去區分請求中可變和不可變的字段,分別查詢。


  Bloom/CALM把這種理念走的更遠,默認的配置選項就是無序執行的策略,只有在必要的時候才啟用順序執行讀寫語句。


  前面是我們必須考慮的一些點,現在思考如何把這些設計組裝在一起做成一個數據處理平臺?




  三、架構


  1、命令查詢職責分離架構(CQRS)


  最常用的架構就是用傳統關系型數據庫存取數據,上層承接各種應用。這種架構會遇到一些瓶頸,比如當數據吞吐量大到一定程度,就會遇到消息傳遞、負載均衡、擴容、并發性能降低等問題。為保持ACID特性,擴容問題尤其嚴峻。


  一種解決方案是CQRS(Command Query Responsibility Segregation),命令查詢職責分離)架構,該模式從業務上分離修改 (Command,增,刪,改,會對系統狀態進行修改)和查詢(Query,查,不會對系統狀態進行修改)的行為。從而使得邏輯更加清晰,便于對不同部分進行針對性的優化。


  還有一種簡單的方式是把讀和寫的請求進行分離,寫數據側進行寫優化處理,類似于日志文件結構。讀數據側進行讀優化處理。比較代表性的實現如Oracle的GoldenGate和MongoDB的Replica Sets .




  還有一些數據庫,采用增加一層引擎的方式來實現上述思想。Druid就是一個很典型的例子,他是一個開源的、分布式的、實時的、列式存儲的分析引擎。列式存儲特別適合需要加載大的數據塊,且數據塊分到多個文件中的場景。Druid把一些近線實時數據放到寫優化的存儲中,然后隨著時間的推移逐步把這些數據遷移到讀優化的存儲中。當Druid接收到請求,會同時把請求轉發給讀、寫優化的存儲,然后把返回的查詢結果根據時間標記進行排序反饋給用戶。像Druid這 種類似的系統,通過一層抽象實現了CQRS的優點。




  2、操作/分析橋(Operational/Analytic Bridge)架構


  另一種相似的處理方式是操作/分析橋(Operational/Analytic Bridge),讀和寫優化視圖被事件流所區分,數據流的狀態是被永久保存的,所以異步視圖可以通過后來的更新被重組或增強。


  這樣前端模塊可以提供同步的讀和寫,這樣可以簡單高效的讀取剛被寫入的數據,或者保持復雜的ACID事物管理。


  后端模塊利用異步性、狀態不變性、去擴展離線處理進程,具體方式可以采用副本、異化、或者完全使用不同的存儲引擎。信息橋,連接前端與后端,允許上層應用使用訪問數據處理平臺的數據。


  這種模試比較適合中級數量的部署,尤其是至少包含部分的、不可


  避免的動態視圖請求。




  3、批處理架構(Hadoop)


  如果我們的數據是一次寫入,多次讀,不在改變的場景,上面可以部署各種復雜的分析型應用。采取批處理模式的hadoop無疑是這種平臺最廣用和出色的代表了。


  Hadoop平臺提供快速的讀寫訪問,廉價的存儲,批處理流程,高吞吐信息流,和其他抽取、分析、處理數據的工具。


  批處理平臺可以主動拉取或者被推進來多種數據源的數據,將其存儲進HDFS,后續可以處理成多種優化的數據格式。數據可以被壓縮,清洗,去結構化,聚合,處理為一種讀優化的格式例如Parquet,或者直接被加載到數據服務層或者數據集市。通過這些過程,數據可以被查詢或者處理。


  這種結構在大批量的、數據不再改變的場景表現良好,一般可以到100TB以上,這種結構的進化是緩慢的,數據處理速度一般也是以小時為單位的。




  4、lambda架構


  有時候我們并不想等待小時后才得到結果,這是該架構的一個缺陷。一種解決方法就是加一個流處理層,就是常說的lambda架構。


  lambda架構在批處理的架構上增加了一個流處理層,如同在一個擁擠城鎮新建一條高架橋。流處理層可以用主流的Storm或者Samza實現。lambda架構的本質是可以快速的返回一個近似的結果,精確的結果在后續返回。


  所以流處理旁路提供一個流處理窗口期內最好的結果,可以先被上層應用所使用,后續批處理流程計算出精確結果在覆蓋掉前面的近似結果。這種架構是對精準度和反饋時間做了一個聰明的平衡,作為后續發展,Spark平臺同時提供了批處理和流處理模塊(雖然流處理實際上市用微型批處理來實現的)。這種架構也可以滿足 100TB以上數據的處理。


  這種架構的另一種代表叫kappa架構,但是本文作者沒看中那種架構,覺得叫kappa屬于吃飽了撐的。




  5、流式處理架構


  不像是批處理架構,把數據存儲到HDFS上,然后在上面執行各種跑批任務。流處理架構把數據存儲到可擴展的消息或者日志隊列,例如kafka,這樣數據就可以被實時的處理成三級視圖、索引, 被數據服務層或者數據集市供上層應用使用。


  這和去掉批處理層的lambda架構很相似,在消息層可以存儲處理海量的數據,有足夠強大的流處理引擎可以hold住這些數據處理進程。


  流處理結構可以用來解決“應用集成”問題,這是個頭疼復雜的問題,IT傳統大佬:Oracle,Tibco,Informatica都曾經試圖想解決,一些部分結果是有用的,但不是真的解決,始終在尋找一套真正可用的解決方案。


  流式處理平臺提供了一種解決該問題的可能性,他繼承了O/A橋平臺的優點:多樣化的異步存儲形式和重新計算視圖的能力,把一致性請求給隔離。系統保存的數據是日志的話,很天然的擁有不變性。Kafka可以保存高容量和吞吐量的歷史記錄,意味著可以重新計算數據狀態,而不是持續的設置檢查點。


  類似流處理架構的工具還有Goldengate,用來向大型數據倉庫同步數據,不過他在數據副本層缺乏高吞吐量支持,在數據模型管理層過于復雜。




  四、小結:


  我們開始于數據的位置,用來讀寫數據的順序地址,從而說明了我們用到組件對該問題的折衷。我們討論了對一些組件的拓展,通過分區和副本構建分布式的數據處理平臺。最后我們闡述了觀點:盡量在數據處理平臺中把一致性的請求隔離。


  數據處理平臺自身也是一個動態調整變化的平臺,依據業務需求,會把寫優化轉為讀優化,把強一致性依賴轉為開放的流式、異步、不變的狀態。


  有些東西我們必須留在思想中,順序的結構化模式是一種,時序、分布式、異步是另一種。


  我們要堅信:經過認真的解決,這些問題都是可控的。


  附(知識補充):


  簡單介紹一下heap-file結構(和鏈表結構很相似):


  支持追加數據(append)


  支持大規模順序掃描


  不支持隨機訪問




  下面是Heap file自有的一些特性:


  數據保存在二級存儲體(disk)中:Heapfile主要被設計用來高效存儲大數據量,數據量的大小只受存儲體容量限制;


  Heapfile可以跨越多個磁盤空間或機器:heapfile可以用大地址結構去標識多個磁盤,甚至于多個網絡;


  數據被組織成頁;


  頁可以部分為空(并不要求每個page必須裝滿);


  頁面可以被分割在某個存儲體的不同的物理區域,也可以分布在不同的存儲體上,甚至是不同的網絡節點中。我們可以簡單假設每一個page都有一個唯一的地址標識符PageAddress,并且操作系統可以根據PageAddress為我們定位該Page。


 


  一般情況下,使用page在其所在文件中的偏移量就可以表示了。


大數據營銷
編輯推薦
圖片行業資訊
  • 雷軍隔空喊話董明珠:格力 小米歡迎你
  • 楊元慶:Moto在華上市一周預定量超100萬
  • 小米洪鋒談O2O布局:做商城不做具體服務
  • 蓋茨向不知名實體捐贈15億美元微軟股票 持股降至3%
  • 劉強東:允許我獲取數據 冰箱免費送給你
營銷資訊搜索
大數據營銷
推薦工具
    熱點關注
    大數據營銷
    大數據營銷
    大數據營銷
    大數據營銷
     

    大數據營銷之企業名錄

    網絡營銷之郵件營銷

    大數據營銷之搜索采集系列

    大數據營銷之QQ號采集

    大數據營銷之QQ精準營銷

    大數據營銷之QQ消息群發

    大數據營銷之空間助手

    大數據營銷之QQ聯盟

    大數據營銷之QQ群助手
     
    設為首頁 | 營銷資訊 | 營銷學院 | 營銷寶典 | 本站動態 | 關于網贏中國 | 網站地圖 | 網站RSS | 友情鏈接
    本站網絡實名:網贏中國  國際域名:www.fdtzms.live  版權所有 2004-2015  深圳愛網贏科技有限公司
    郵箱:[email protected] 電話:+86-755-26010839(十八線) 傳真:+86-755-26010838
    在線咨詢:點擊這里給我發消息 點擊這里給我發消息 點擊這里給我發消息  點擊這里給我發消息  點擊這里給我發消息

    深圳網絡警
    察報警平臺
    公共信息安
    全網絡監察
    經營性網站
    備案信息
    不良信息
    舉報中心
    中國文明網
    傳播文明
    分享
    拳皇98怎么玩