所在公司為交通行業,需要記錄和查詢日常城市過車記錄,一般情況下,抓拍機獲取過車信息經介面給到資料庫,記錄存到資料庫,實際的過車圖片等內容放到存儲單元裡面,後面的查詢就類似與翻看字典,資料庫是目錄,存儲就好比實際的頁數,這樣的模型可以理解。過車數據量猛增以後,傳統的查字典速度太慢,效率不行,需要解決這一問題,就上大數據,那麼大數據是如何做到的呢?網上看了很多也沒能理解到位啊,哪位大神可以解惑啊


謝邀!

希望能通過一個通俗易懂的例子給大家講清楚大數據分散式計算技術。大數據技術雖然包含存儲、計算和分析等一系列龐雜的技術,但分散式計算一直是其核心,想要了解大數據技術,不妨從 MapReduce 分散式計算模型開始。

本文是一篇科普性質的文章,希望能通過一個通俗易懂的例子給大家講清楚大數據分散式計算技術。

大數據技術雖然包含存儲、計算和分析等一系列龐雜的技術,但分散式計算一直是其核心,想要了解大數據技術,不妨從 MapReduce 分散式計算模型開始。該理論模型並不是什麼新理念,早在 2004 年就被 Google 發布,經過十多年的發展,儼然已經成為了當前大數據生態的基石,可謂大數據技術之道,在於 MapReduce。傳統計算技術在進入到分散式計算技術這個概念之前,我們先回顧一下傳統計算技術。為了使計算機領域的相關概念能夠生動形象深入淺出,我將計算機類比為人:

在這張圖中我們建立了計算機基本元件的類比關係,並不嚴謹但足以說明問題。有了這個類比關係,我們可以把計算機領域的問題轉換為我們熟悉的人類領域的問題。從現在開始,每個人,比如你自己就是一台計算機,我們代稱為「人型計算機」,你擁有基本的計算機元件,上帝是個程序員,可以編寫程序——一系列設定好的指令,讓你完成一些計算任務。下面我們要用一個簡單的案例,分析「人型計算機」是如何利用傳統計算技術解決實際問題的。在開始之前,要增加一些限定,如同正常計算機的內存是有上限的,我們的「人型計算機」也存在記憶力的上限。這裡我們假設一個「人型計算機」最多可以同時在「內存」中記住 4 種信息,例如:蘋果、梨等四種水果的個數:

看起來這台「人型計算機」的性能比較差,不過好在我們需要處理的問題也不複雜。有幾十張不包含大王和小王的撲克牌,這些牌的花色和大小均不確定(並不一定能湊成一副牌),如何給一台「人型計算機」設計一個程序,統計各個花色的撲克牌數量?

你的答案可能脫口而出:對於「人型計算機」而言,直接在大腦中記住每個花色的個數,一張一張地取撲克牌計數,處理完所有的撲克牌之後報 4 個花色的個數就行。答案完全正確,正常計算機最簡單的計算模式就是這樣的,內存中記錄統計結果,隨著輸入設備不斷讀取數據,更新內存中的統計結果,最後從輸出設備展示結果:

接下來問題的難度要升級了,統計這些撲克牌中 A~K 共 13 種牌面每種牌面的個數。我們的「程序」該如何升級?

我們察覺到,如果仍然沿用之前的解決思路,「人型計算機」的「內存」已經不夠用了,因為其存儲上限為 4 種信息,無法存儲 A~K 這 13 種牌面信息。聯繫一下現實生活中的場景,當我們發現自己無法記住很多信息時,會用賬本來輔助記憶。對於計算機來說是一樣的,內存不足就使用磁碟來存放信息,這時候,賬本就可以類比於一個存放於「磁碟」的 Excel 文檔:

那麼統計牌面這個問題的解決思路就有了:每取一張撲克牌,在賬本中更新相應牌型的統計個數,數完所有的撲克牌之後直接報出結果。

單個計算機的傳統計算模式就是這樣,可以簡單概括為按照一定統一規則對輸入數據進行加減乘除等數學運算,然後輸出結果的過程,這中間產生的數據會存儲在內存或硬碟中。在上面的案例中,撲克牌是「人型計算機」的「輸入數據「,相當於計算機二進位世界中可以被識別的數字和文本。統計的撲克牌個數是「輸出結果「,相當於你可以在電腦屏幕上看到的信息。實際上,憑藉內存、硬碟和 CPU 等基本組件,單個計算機(不只包括個人電腦,智能手機也算)已經可以完成我們上網聽歌看電影等日常基本需求中所涉及到的計算。只要計算不超出 CPU 的極限(譬如圍棋人機對戰之類的)是妥妥沒問題的,而且我們還有優化內存、優化硬碟等多種手段來增強單個計算機的計算能力,從而滿足人民群眾日益增長的物質與文化生活的需要。好了,背景知識已經足夠了,讓我們進入正題。

大數據分散式計算

首先,什麼是分散式計算?簡單點理解就是將大量的數據分割成多個小塊,由多台計算機分工計算,然後將結果匯總。這些執行分散式計算的計算機叫做集群,我們仍然延續前文中人和計算機的類比,那麼集群就是一個團隊,單兵作戰的時代已經過去,團隊合作才是王道:

為什麼需要分散式計算?因為「大數據」來了,單個計算機不夠用了,即數據量遠遠超出單個計算機的處理能力範圍。有時候是單位時間內的數據量大,比如在 12306 網上買票,每秒可能有數以萬計的訪問;也有可能是數據總量大,比如百度搜索引擎,要在伺服器上檢索數億的中文網頁信息。實現分散式計算的方案有很多,在大數據技術出現之前就已經有科研人員在研究,但一直沒有被廣泛應用。直到 2004 年 Google 公布了 MapReduce 之後才大熱了起來。大數據技術、分散式計算和 MapReduce 的關係可以用下圖來描述,MapReduce 是分散式計算在大數據領域的應用:

MapReduce 模型是經過商業實踐的成熟的分散式計算框架,與 Google 的分散式文件系統 GFS、分散式數據存儲系統 BigTable 一起,號稱 Google 的大數據「三寶」,為大數據技術的發展提供了堅實的理論基礎。但遺憾的是,谷歌並沒有向外界公布自己的商業產品,而真正讓大數據技術大踏步前進的是按照 Google 理論實現的開源免費產品 Hadoop,目前已經形成了以 Hadoop 為核心的大數據技術生態圈。

讓我們回到數撲克牌這個例子中,大數據時代的撲克牌問題是什麼樣子的?
  • 輸入數據的規模增加:撲克牌暴增到數萬張。
  • 中間運算數據的規模增加:問題又升級了,我們需要統計 52 種牌型每種牌型出現的次數。
  • 處理時間有限制:我們希望能儘快得到統計結果。

怎麼樣,有沒有感覺到大數據撲面而來?要知道我們「人型計算機」的「內存「和「硬碟」是有容量限制的,52 種牌型的信息已經超出了單台計算機的處理能力。當然這裡會有人提出質疑,認為擴充內存或者磁碟容量就可以解決這個問題,52 種牌型完全不需要分散式計算。那大家考慮一下假如這堆牌中有幾百種、甚至幾千種牌型呢?

所以 52 種牌是為了符合現實中的情況,讓大家領會到單個計算機已經無法同時處理這麼多數據了,我們需要多台計算機一起協作,是時候放出 MapReduce 這個大招了。我個人在查閱一些資料、進行一些實踐以後,認為 MapReduce 的技術可以簡單地用四字訣來總結:分、變、洗、合,它們分別代表「切分」、「變換」、「洗牌」、「合併」四個步驟。

下面來看如何用四字訣解決大數據撲克牌問題。切分把輸入數據切分成多份既然單個「人型計算機」無法完全處理完所有的撲克,那麼我們就把撲克牌隨機分成多份,每份撲克牌由一個「人型計算機」來處理,個數不超過單個計算機的處理上限,而且盡量讓每份的數量比較平均。

這裡我們要講一下角色分工的問題,多台計算機合作,肯定要有角色分工,我們可以把負責數據切分的「人型計算機」理解為「指揮官」,「指揮官」一般只有一個(在實際中可能有多個),統籌調度之類的工作都歸他管。負責執行具體運算任務的「人型計算機」則是「計算兵」,「計算兵」按照承擔的任務不同分為「變計算兵」和「合計算兵」,前者負責第二步「變換」,後者負責最後一步「合併」。

「計算兵」的總數當然是多多益善,但「變計算兵」和「合計算兵」各自所佔的比例並不固定,可以根據數據的多少和運算的效率進行調整。當兵力不夠的時候,一個計算兵有可能承擔兩種角色,「指揮官」同時也有可能擔任「計算兵」,因為在實際情況中一台計算機可以有多個進程承擔多個任務,即理論上講一個計算機可以分飾多角。「指揮官」在切分撲克牌之前,會先分配好「變計算兵」和「合計算兵」的數量,然後根據「變計算兵」的數量把撲克拆分成相應的份數,將每份撲克分給一個「變計算兵」,然後進入下一步。

變換把每條輸入數據做映射變換(也就是 MapReduce 中的 Map)每一個「變計算兵」都要對自己分得的每一張撲克牌按照相同的規則做變換,使得後續的步驟中可以對變換後的結果做處理。這種變換可以是加減乘除等數學運算,也可以是對輸入數據的結構的轉換。例如對於我們這個撲克牌問題來講,目的是為了計數,所以可以將撲克牌轉換為一種計算機更容易處理的數值結構:將每張撲克牌上貼一張小便簽,這條小便簽上寫明了其個數為 1。

我們把這種貼了標籤的撲克牌叫做變種撲克牌。當在後續的步驟中統計牌型個數時,只需要把每個標籤上的數字加起來就可以。有的朋友肯定會好奇為什麼不讓每個「計算兵」直接統計各自的所有牌型的撲克的個數,這是因為這種「映射變換」運算的本質在於將每張撲克牌都進行同一種相同規則的變換,統計個數的工作要留在最後一步完成。嚴格的流水化操作,會讓整體的效率更高,而且變換的規則要根據具體問題來制定,更容易適配不同種類的計算。洗牌把變換後的數據按照一定規則分組變換的運算完成之後,每個「變計算兵」要將各自的變種撲克牌按照牌型分成多個小份,每個小份要最終被一個指定的「合計算兵」進行結果合併統計。這個過程就是「洗牌」,是「變計算兵」將變換後的撲克牌按照規則分組並分配給指定的「合計算兵」的過程。

洗牌分兩個階段,第一階段是每個「變計算兵」將變種撲克牌按照一定的規則分類,分類的規則取決於每個「合計算兵」的統計範圍,分類的個數取決於「合計算兵」的個數。如上圖所示,假設有 3 個「合計算兵」分別負責不同範圍的牌型的統計,那麼「變計算兵」需要根據每個「合計算兵」負責的牌型將自己的變種撲克牌分成 3 個小份,每份交給對應的「合計算兵」。洗牌的第二階段,「合計算兵」在指揮官的指揮下,去各個「變計算兵」的手中獲取屬於他自己的那一份變種撲克牌,從而使得牌型相同的撲克牌只會在一個「合計算兵」的手上。洗牌的意義在於使相同牌型的變種撲克牌匯聚在了一起,以便於統計。

合併將洗牌後的數據進行統計合併(也就是 MapReduce 中的 Reduce)「合計算兵」將手中的變種撲克牌按照相同的計算規則依次進行合併,計算規則也需要根據具體問題來制定,在這裡是對撲克牌上標籤的數值直接累加,統計出最終的結果。

然後所有的「合計算兵」把自己的計算結果上交給「指揮官」,「指揮官」匯總後公布最終統計的結果。

總結以上,「分變洗合」四字訣介紹完畢,完整過程如下:

分散式處理技術在邏輯上並不複雜,但在具體的實現過程中會有很多複雜的過程,譬如「指揮官」如何協調調度所有的「運算兵」,「運算兵」之間如何通信等等。但對於使用 MapReduce 來完成計算任務的程序員來講,這些複雜的過程是透明的。分散式計算框架會自己去處理這些問題,程序員只需要定義兩種計算規則:
  • 第二步中變換的規則。
  • 第四步中合併的規則。

正所謂大道至簡,萬變不離其宗,理解了 MapReduce 就理解了大數據分散式處理技術,而理解大數據分散式處理技術,也就理解了大數據技術的核心。


  大數據(big data),指無法在一定時間範圍內用常規軟體工具進行捕捉、管理和處理的數據集合,是需要新處理模式才能具有更強的決策力、洞察發現力和流程優化能力的海量、高增長率和多樣化的信息資產。

  大數據需要特殊的技術,以有效地處理大量的容忍經過時間內的數據。適用於大數據的技術,包括大規模並行處理(MPP)資料庫、數據挖掘、分散式文件系統、分散式資料庫、雲計算平台、互聯網和可擴展的存儲系統。


這個問題場景,之前也遇到過。當時主要是通過不同的組件來實現大流量數據的實時處理。

大數據的做法就是分散式計算,或者是流式計算,通過這種方式來提高響應效率。


謝邀!

大數據(big?data),或稱巨量資料,指的是所涉及的資料量規模巨大到無法透過目前主流軟體工具,在合理時間內達到擷取、管理、處理、並整理成為幫助企業經營決策更積極目的的資訊。在北京理工大學大數據搜索與挖掘實驗室張華平博士看來:大數據可以認為是指從客觀存在的全量超大規模、多源異構、實時變化的微觀數據中,利用自然語言處理、信息檢索、機器學習等技術抽取知識,轉化為智慧的方法學。也可以理解為運用計算機技術整合已有資源。

根據樓主遇到的問題我來分享一個案例,來理解大數據挖掘:

某大廈電力數據挖掘

得到的數據情況為:238個房間每一天的用電數據,總共是三百多天,期間工作日是256天,計算其單日用電量。基於這個數據傳統的數據聚合、數據基本分類、數據統計曲線等簡單工作便略去了。

這裡涉及到的一項工作便是計算空置率,空置率的計算對經濟預測,尤其是微觀經濟的洞察和宏觀經濟的研判具有很強的現實意義。可以看到,這裡空置房間的標準是經過大量數據計算出來的。其實在二三線城市不錯的寫字樓,其空置率也達到了32%。除此之外,還可以精確預測每個房間的總體用電情況,由此來推導房間中辦公的人數。

以上是對大數據的簡單介紹,希望可以幫助到您,為您推薦一本北京理工大學大數據搜索與挖掘實驗室張華平博士著作的書籍《大數據搜索與挖掘》,裡面介紹的非常全面,同時也可以下載一下張華平博士研發的NLPIR大數據語義智能分析平台(http://ictclas.nlpir.org),進行實際數據分析,幫助您解決數據挖掘上面的問題。


謝邀。說說自己的看法。

首先你這個問題是要解決一個業務需求問題。你先把業務需求等相關場景想明白,不要一上來就大數據。

在我看來抓拍機是一個重點,抓拍機是有固定位置的,無論是在路邊,還是在桿塔上,其高度、清晰度等都是有一定的。這是在當初架設的時候就應該有調試確定的。這就決定了它能抓拍到的東西是啥。交通管理行業說到底管的是車牌。如果車輛沒有車牌你就無從管。也很難追查。因此這裡關鍵就是識別車牌。而識別車牌是圖像識別技術的工作。也就是說一旦識別出並掌握了這個信息,相關的時間地點等都不是問題,從而找到涉事的相關車輛人員信息易如反掌。進而想分析什麼都是手到擒來。所以你這個系統的關鍵不是一上來就搞什麼大數據,而是先要搞圖像識別,一旦做好這個那就算用普通的數據統計分析,也輕鬆可以搞定你這個業務需求。

可懂我的意思了?你自己再核計核計吧!


我們來舉個例子,飯館裡會和面的,叫做面案。宣傳隊裡面,用白面來做漿糊的,其實也是和面,是宣傳員。那麼,和面的到底是面案還是宣傳員呢?用白面的,到底是宣傳隊還是飯館呢。不是用了hadoop,spark,hive等就是大數據了,大數據是一個理念。

你真的是搞大數據的嗎?(1)

讓數據能賺錢


題主的問題本身就已經很好的詮釋了大數據的前生今世,也很好的定義了大數據的實質。

事實上截至到今天為止 (2019年4月), 資料庫(關係型資料庫,非關係型資料庫) 仍然是大多數環境下、大數據背景下的核心解決方案。無論如何理解大數據,核心目的就是要查詢快!

假如我告訴你,隨著硬體技術、存儲技術的發展(如量子計算),PB 級別的數據都秒查,還有人關心什麼大數據小數據和解決方案嗎?所以說現在所有的方案都是基於硬體還沒nb到那種程度說的。

作為一個技術人員,我用幾句簡單的技術術語來幫助理解大數據:大資料庫,把表(欄位,記錄)分開放 (表可以是傳統資料庫表,或者直接文件CSV,JSON等),使用類似傳統的SQL 語句來查詢 (HIVE,HBASE,SPARK), 如果不會SQL 就用其他語言如 R,Python 來查詢。

無論什麼大網站小網站,核心是分布計算(也就是怎麼通過現有的硬體軟體怎麼化整為零),而不是什麼大數據本身。


其實我就是想表達從數據量小,用傳統的方式處理和數據量大了後,用大數據來處理,兩者的架構有什麼區別;或者說以前的數據量很小,用傳統方式,那麼數據量大了以後,需要建新基於大數據的存儲資料庫,老的資料庫就不用或者什麼的,我的表述也可能有些問題吧


推薦閱讀:
相关文章