從海量數據處理到大數據架構設計思想之-分而治之

本文主要從海量數據處理到大數據解決方案的架構設計，討論其共通的一些解決思路、設計思想 -- 分而治之。

其實生活中這樣的例子無處不在，例如讓你抗一袋沙子，我一次抗不動，那么我拿個小桶，分開一桶一桶的搬，這其實就是分而治之的思路。具體映射到軟件行業可以繼續往下看。

海量數據處理的分而治之

所謂海量數據處理，其實很簡單，海量，海量，何謂海量，就是數據量太大，所以導致要么是無法在較短時間內迅速解決，要么是數據太大，導致無法一次性裝入內存。

那解決辦法呢?針對空間，無非就一個辦法：大而化小：分而治之/hash映射，你不是說規模太大嘛，那簡單啊，就把規模大化為規模小的，各個擊破不就完了嘛。

例如：海量日志數據，提取出某日訪問百度次數最多的那個IP

把整個大文件映射為1000個小文件，再找出每個小文中出現頻率最大的IP（可以采用Hash_map進行頻率統計，然后再找出頻率最大的幾個）及相應的頻率。然后再在這1000個最大的IP中，找出那個頻率最大的IP，即為所求。

大數據框架設計的分而治之

在大數據框架設計的過程中，框架開發者都會考慮框架的運行環境問題：單機模式，集群模式。

通俗點來講，單機就是處理裝載數據的機器有限(只要考慮cpu，內存，硬盤的數據交互)，而集群，服務器有多臺，適合分布式處理，并行計算(更多考慮節點和節點間的數據交互)。

另外還會考慮文件的存儲問題，怎樣的存儲結構才能讓我們更快，更高效的定位到數據的存放位置，且能夠保證數據的不丟失。

以hdfs為例，文件存儲以塊的形勢存儲，用戶寫入一個大于設置的塊大小的大文件時，大文件分拆成小文件（按照128m為一個塊劃分），存儲到不同的集群節點中，并加以冗余。

無論文件由大到小進行拆分處理，處理從單節點執行到多節點執行，其實都是一個分而治之的思想

在大數據框架功能設計上，分而治之也是無處不在的。

例如：當一份數據需要寫入到多個存儲系統中時，或許你會想到flume，通過flume的channel將數據分發到不同的sink，通過sink寫入到不同的存儲系統中去

kafka中的partition與consumer group：一個topic 可以配置幾個partition，produce發送的消息分發到不同的partition中，consumer接受數據的時候是按照group來接受，kafka確保每個partition只能同一個group中的同一個consumer消費，如果想要重復消費，那么需要其他的組來消費。

架構設計的分而治之

從數據端獲取數據，然后進行事實/離線計算，將計算結果持久化。

假如數據端無法提供數據直接寫入到kafka，那么又該如何對架構進行修改呢？

數據端最終數據會持久化到MySqlDB，那我們從DB端下手，將數據從DB端抽取出來存放到kafka集群中，進而執行接下來的計算工作。

從上圖可見，我們將數據讀取修改為從mysql binlog的方式去獲取數據，采用canal進行binlog日志的獲取以及解析。這其實也是一個拆分的思想，從原先的數據端到kafka，拆分成數據端-DB-canal-Kafka，過程雖然變長了，但是業務需求得以滿足.

在理想情況下，我們在不清楚業務系統需求的時候，設計出來的架構跟具體業務系統的架構是不吻合的。當業務系統無法提供你所要的需求的時候，從不同的層面去思考，將業務進行拆分，或許會給你不一樣的解決方案。

關注公眾號

架構設計 大數據

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。