最早提出“大數據”時代到來的是全球知名咨詢公司麥肯錫，大數據是當前很熱的一個詞。這幾年來，雲計算、繼而大數據，成了整個社會的熱點，大數據究竟是什麼東西?有哪些相關技術?對普通人的生活會有怎樣的影響?我們來一步步弄清這些問題。

在講什麼是大數據之前，我們首先需要厘清數據的基本概念。

數據是可以獲取和存儲的信息，直觀而言，表達某種客觀事實的數值是最容易被人們識别的數據(因為那是“數”)。但實際上，人類的一切語言文字、圖形圖畫、音像記錄，所有感官可以察覺的事物，隻要能被記下來，能夠查詢到，就都是數據(data)。

随着互聯網快速發展、智能手機以及“可佩帶”計算設備的出現，我們的行為、位置，甚至身體生理數據等每一點變化都成為了可被記錄和分析的數據。這些新技術推動着大數據時代的來臨，各行各業每天都在産生數量巨大的數據碎片，數據計量單位已從 Byte、KB、MB、GB、TB 發展到 PB、EB、ZB、YB 甚至 BB 來衡量。

1Byte = 8bit 1K(千)= 1024Byte 1MB（兆)=1024K 1G(吉) = 1024M

1T(太)=1024G 1P(拍)=1024T 1E(艾)=1024P 1Z(澤)=1024E

1Y (堯)=1024Z 1B(布)=1024Y 1N(諾)=1024B 1D(刀)=1024N

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

數據分析的前提是有數據，數據存儲的目的是支撐數據分析。究竟怎麼去存儲龐大的數據量，是開展數據分析的企業在當下面臨的一個問題。傳統的數據存儲模式存儲容量是有大小限制或者空間局限限制的，怎麼去設計出一個可以支撐大量數據的存儲方案是開展數據分析的首要前提。

當解決了海量數據的存儲問題，接下來面臨的海量數據的計算問題也是比較讓人頭疼，因為企業不僅追求可以計算，還會追求計算的速度、效率。

以目前互聯網行業産生的數據量級别，要處理這些數據，就需要一個更好、更便捷的分析計算方式了。傳統的顯然力不從心了，而且效率也會非常低下。這正是傳統數據分析領域面臨的另一個挑戰，如何讓去分析、計算。這個時候就需要有新的技術去解決這些問題，這個技術就是大數據。

大數據主要解決的問題: 海量數據的存儲和海量數據的計算問題

​

大數據的特點可以使用 5 個字來概括:大、多、值、快、信

大 數據的采集，計算，存儲量都非常的龐大。是數據體量巨大(Volume)。截至目前，人類生産的所有印刷材料的數據量是 200PB(1PB=1024TB)，而曆史上全人類說過的所有的話的數據量大約是 5EB(1EB=1024PB)。當前，典型個人計算機硬盤的容量為 TB 量級，而一些大企業的數據量已經接近 EB 量級。

多 種類和來源多樣化。種類有：結構化、半結構化和非結構化數據等，常見的來源有：網絡日志、音頻、視頻、圖片等等。

值 大數據價值密度相對較低。如随着物聯網的廣泛應用，信息感知無處不在，信息海量，但價值密度較低，存在大量不相關信息。因此需要對未來趨勢與模式作可預測分析，利用機器學習、人工智能等進行深度複雜分析。而如何通過強大的機器算法更迅速地完成數據的價值提煉，是大數據時代亟待解決的難題。

快 數據增長速度快，處理速度也快，獲取數據的速度也要快。這是大數據區分于傳統數據挖掘的最顯著特征。根據 IDC 的“數字宇宙”的報告，到 2020 年，全球數據使用量将達到 35.2ZB。在如此海量的數據面前，處理數據的效率就是企業的生命。

信 數據的準确性和可信賴度，即數據的質量。

精準廣告位，通過對用戶的浏覽行為，點擊行為等進行大數據采集，分析，挖掘用戶的二層三層喜歡，擴大産出。

猜你喜歡，通過對受衆人群機型大數據分析，結合對應算法，對受衆喜歡的進行交互推薦。

理财投資，通過對個人的信用評估，風險承擔能力評估，集合衆多理财産品、推薦響應的投資理财産品。

目前，交通的大數據應用主要在兩個方面:一方面通過對車流量等海量數據的收集，估算，預測該路段一定時間内的車流量情況，給用戶提供便利，合理進行道路規劃；另一方面可以利用大數據來實現即時信号燈調度，提高已有線路通行能力。

智慧營業廳，通過對用戶當前的行為習慣、偏好，節假日的相應數據變化，調節自身業務結構，做到按需分配。

人臉識别，通過人臉識别，--匹配，存儲用戶數據，結合人工智能，分析及甄别用戶行為，預防犯罪行為發生

智慧醫療，通過對海量病例大數據的存儲，匹配、檢索、結合用戶的飲食、行為等習慣，搭建智慧醫療體系。

FRA 通過大數據解決方案得出司機工作表現的若幹預測模型，解決了事故發生率和人員流動等人事部門的問題。

典型的大數據分析包含以下幾個步驟：

明确數據分析目的以及确定分析思路，是确保數據分析過程有效進行的先決條件，它可以為數據的收集、處理及分析提供清晰的指引方向。

目的是整個分析流程的起點。目的不明确則會導緻方向性的錯誤。即思考:為什麼要開展數據分析，通過這次數據分析要解決什麼問題？

當明确目的後，就要校理分析思路，并搭建分析框架，把分析目的分解成若幹個不同的分析要點，即如何具體開展數據分析，需要從哪幾個角度進行分析，采用哪些分析指标。隻有明确了分析目的，分析框架才能跟着确定下來，最後還要确保分析框架的體系化，使分析更具有說服力。

體系化也就是邏輯化，簡單來說就是先分析什麼，後分析什麼，使得各個分析點之間具有邏輯聯系。避免不知從哪方面入手以及分析的内容和指标被質疑是否合理、完整。所以體系化就是為了讓你的分析框架具有說服力。

要想使分析框架體系化，就需要一些營銷、管理等理論為指導，結合着實際的業務情況進行構建，這樣才能保證分析維度的完整性，分析結果的有效性以及正确性。比如以用戶行為理論為指導，搭建的互聯網網站分析指标框架如下：

把跟數據分析相關的營銷、管理等理論統稱為數據分析方法論。比如用戶行為理論、PEST 分析法、5W2H 分析法等等，詳細請查閱附件資料。

數據收集是按照确定的數據分析框架，收集相關數據的過程，它為數據分析提供了素材和依據。這裡所說的數據包括第一手數據與第二手數據，第一手數據主要指可直接獲取的數據，第二手數據主要指經過加工整理後得到的數據。一般數據來源主要有以下幾種方式：

數據庫：每個公司都有自己的業務數據庫，存放從公司成立以來産生的相關業務數據。這個業務數據庫就是一個龐大的數據資源，需要有效地利用起來。

公開出版物：可以用于收集數據的公開出版物包括《中國統計年鑒》《中國社會統計年鑒》《中國人口統計年鑒》《世界經濟年鑒》《世界發展報告》等統計年鑒或報告。

互聯網：随着互聯網的發展，網絡上發布的數據越來越多，特别是搜索引擎可以幫助我們快速找到所需要的數據，例如國家及地方統計局網站、行業組織網站、政府機構網站、傳播媒體網站、大型綜合門戶網站等上面都可能有我們需要的數據。

市場調查：進行數據分析時，需要了解用戶的想法與需求，但是通過以上三種方式獲得此類數據會比較困難，因此可以嘗試使用市場調查的方法收集用戶的想法和需求數據。

數據處理是指對收集到的數據進行加工整理，形成适合數據分析的樣式，它是數據分析前必不可少的階段。數據處理的基本目的是從大量的、雜亂無章、難以理解的數據中，抽取并推導出對解決問題有價值、有意義的數據。

數據處理主要包括數據清洗、數據轉化、數據提取、數據計算等處理方法。一般拿到手的數據都需要進行一定的處理才能用于後續的數據分析工作，即使再“幹淨”’的原始數據也需要先進行一定的處理才能使用。

數據處理是數據分析的基礎。通過數據處理，将收集到的原始數據轉換為可以分析的形式，并且保證數據的一緻性和有效性。

數據分析是指用适當的分析方法及工具，對處理過的數據進行分析，提取有價值的信息，形成有效結論的過程。由于數據分析多是通過軟件來完成的，這就要求數據分析師不僅要掌握各種數據分析方法，還要熟悉數據分析軟件的操作。

數據挖掘其實是一種高級的數據分析方法，就是從大量的數據中挖掘出有用的信息，它是根據用戶的特定要求，從浩如煙海的數據中找出所需的信息，以滿足用戶的特定需求。數據挖掘技術是人們長期對數據庫技術進行研究和開發的結果。一般來說，數據挖掘側重解決四類數據分析問題:分類、聚類、關聯和預測，重點在尋找模式和規律。數據分析與數據挖掘的本質是一樣的，都是從數據裡面發現關于業務的知識。

一般情況下，數據是通過表格和圖形的方式來呈現的，我們常說用圖表說話就是這個意思。常用的數據圖表包括餅圖、柱形圖、條形圖、折線圖、散點圖、雷達圖等，當然可以對這些圖表進一步整理加工，使之變為我們所需要的圖形，例如金字塔圖、矩陣圖、漏鬥圖等。

大多數情況下，人們更願意接受圖形這種數據展現方式，因為它能更加有效、直觀地傳遞出分析所要表達的觀點。記位，一般情況不，能用圖說明問題的就不用表格，能用表格說明問題的就不要用文字。

數據分析報告其實是對整個數據分析過程的一個總結與呈現。通過報告，把數據分析的起因、過程、結果及建議完整地呈現出來，供決策者參考。

一份好的數據分析報告，首先需要有一個好的分析框架，并且圖文并茂，層次明晰，能夠讓閱讀者一目了然。結構清晰、主次分明可以使閱讀者正确理解報告内容;圖文并茂，可以令數據更加生動活潑 ,提供視覺沖擊力，有助于閱讀者更形象、直觀地看清楚問題和結論，從而産生思考。

另外，數據分析報告需要有明确的結論，沒有明确結論的分析稱不上分析，同時也失去了報告的意義，因為我們最初就是為尋找或者求證一個結論才進行分析的，所以千萬不要舍本求末。

最後，好的分析報告一定要有建議或解決方案。作為決策者，需要的不僅僅是找出問題，更重要的是建議或解決方案，以便他們做決策時作參考。所以，數據分析師不僅需要掌握數據分析方法，而且還要了解和熟悉業務，這樣才能根據發現的業務問題，提出具有可行性的建議或解決方案。

無論是我們在學校剛開始學編程，還是在剛參加工作開始處理實際問題，寫出來的程序都是很簡單的。因為面對的問題很簡單。以處理數據為例，可能隻是把一個幾十 K 的文件解析下，然後生成一個詞頻分析的報告。很簡單的程序，十幾行甚至幾行就搞定了。

直到有一天，給你扔過來 1000 個文件，有些還特别大，好幾百 M 了。你用之前的程序一跑，發現跑的時間有點長。于是想要去優化下。1000 個文件，互相還沒業務聯系，用多線程呀，一個線程處理一個文件，結果再彙總就搞定了。如果多線程效果不夠好，比如像 Python 的多線程，沒法利用多核的威力，那就用多進程。

無論是線程、進程，本質上，目的都是為了計算的并行化，解決的是算的慢的問題。而如果計算量足夠大，就算榨幹了機器的計算能力，也算不過來，咋辦？

一台機器不夠，那就多搞幾台機器嘛。所以就從多線程/進程的計算并行化，進化到計算的分布式化（當然，分布式一定程度上也是并行化）。

另一方面，如果處理的數據有 10T，而你手上的機器隻有 500G 的硬盤，怎麼辦？

一種辦法是縱向擴展，搞一台幾十 T 硬盤的機器；另一種是橫向擴展，多搞幾台機器，分散着放。前者很容易到瓶頸，畢竟數據無限，而一台機器的容量有限，所以在大數據量的情況下，隻能選後者。把數據分散到多台機器，本質上解決的是存不下的問題。

同時，剛才提到計算分布式化後，總不能所以程序都去同一台機器讀數據吧，這樣效率必然會受到單台機器性能的拖累，比如磁盤 IO、網絡帶寬等，也就逼着數據存儲也要分散到各個機器去了。基于這兩個原因，數據存儲也分布式起來了。

分布式系統是一個硬件或軟件組件分布在不同的網絡計算機上，彼此之間僅僅通過消息傳遞進行通信和協調的系統。簡單來說就是一群獨立計算機集合共同對外提供服務，但是對于系統的用戶來說，就像是一台計算機在提供服務一樣。

分布式意味着可以采用更多的普通計算機（相對于昂貴的大型機）組成分布式集群對外提供服務。計算機越多，CPU、内存、存儲資源等也就越多，能夠處理的并發訪問量也就越大。

從分布式系統的概念中我們知道，各個主機之間通信和協調主要通過網絡進行，所以，分布式系統中的計算機在空間上幾乎沒有任何限制，這些計算機可能被放在不同的機櫃上，也可能被部署在不同的機房中，還可能在不同的城市中，對于大型的網站甚至可能分布在不同的國家和地區。

小明的公司有 3 個系統：系統 A，系統 B 和系統 C，這三個系統所做的業務不同，被部署在 3 個獨立的機器上運行，他們之間互相調用（當然是跨域網絡的），通力合作完成公司的業務流程。

将不同的業務分部在不同的地方，就構成了一個分布式的系統，現在問題來了，系統 A 是整個分布式系統的臉面，用戶直接訪問，用戶訪問量大的時候要麼是速度巨慢，要麼直接挂掉，怎麼辦？

由于系統 A 隻有一份，所以會引起單點失敗。

小明的公司不差錢，就多買幾台機器吧， 小明把系統 A 一下子部署了好幾份（例如下圖的 3 個服務器），每一份都是系統 A 的一個實例，對外提供同樣的服務，這樣，就不怕其中一個壞掉了，還有另外兩個呢。

這三個服務器的系統就組成了一個集群。

可是對用戶來說，一下子出現這麼多系統 A，每個系統的 IP 地址都不一樣，到底訪問哪一個呢？

如果所有人都訪問服務器 1.1，那服務器 1.1 會被累死，剩下兩個閑死，成了浪費錢的擺設。

小明要盡可能的讓 3 個機器上的系統 A 工作均衡一些，比如有 3 萬個請求，那就讓 3 個服務器各處理 1 萬個（理想情況），這叫負載均衡

很明顯，這個負載均衡的工作最好獨立出來，放到獨立的服務器上（例如 nginx）：

後來小明發現，這個負載均衡的服務器雖然工作内容簡單，就是拿到請求，分發請求，但是它還是有可能挂掉，單點失敗還是會出現。沒辦法，隻好把負載均衡也搞成一個集群，這個集群和系統 A 的集群有兩點不同：

1.我們可以用某種辦法，讓這個機器對外隻提供一個 IP 地址，也就是用戶看到的好像隻有一個機器。

2.同一時刻，我們隻讓一個負載均衡的機器工作，另外一個原地待命，如果工作的那個挂掉了，待命的那個就頂上去。

如果 3 個系統 A 的實例還是滿足不了大量請求，例如雙十一，可以申請增加服務器，雙十一過後，新增的服務器閑置，成了擺設，于是小明決定嘗試雲計算，在雲端可以輕松的創建，删除虛拟的服務器，那樣就可以輕松的随着用戶的請求動圖的增減服務器了。

上面的系統看起來很美好，但是做了一個不切實際的假設：所有的服務都是無狀态的，換句話說，假設用戶的兩次請求直接是沒有關聯的。但是現實是，大部分服務都是有狀态的，例如購物車。

用戶訪問系統，在服務器上創建了一個購物車，并向其中加了幾個商品，然後服務器 1.1 挂掉了，用戶後續訪問就找不到服務器 1.1 了，這時候就要做失效轉移，讓另外幾個服務器去接管，去處理用戶的請求。

可是問題來了，在服務器 1.2,1.3 上有用戶的購物車嗎？如果沒有，用戶就會抱怨，我剛創建的購物車哪裡去了？還有更嚴重的，假設用戶登錄過得信息保存到了該服務器 1.1 上登錄的，用戶登錄過的信息保存到了該服務器的 session 中，現在這個服務器挂了，用的 session 就不見了，會把用戶踢到了登錄界面，讓用戶再次登錄！

處理不好狀态的問題，集群的威力就大打折扣，無法完成真正的失效轉移，甚至無法使用。

怎麼辦？

一種辦法是把狀态信息在集群的各個服務器之間複制，讓集群的各個服務器達成一緻。

還有一種辦法， 就是把幾種狀态信息存儲在一個地方，讓集群服務器的各個服務器都能訪問到。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!