大資料真的是越來越火了，但凡什麼創業公司吹牛的時候就喜歡宣稱自己使用了大資料技術，使用了資料探勘、機器學習。外行人聽起來雲裡霧裡、不明覺厲，聽說某名校還專門成立了大資料專業。

大資料這名詞聽起來很高大上，但其實內裡簡單的不得了。什麼叫大資料呢？就是大量的資料。對的，就是這麼簡單。大量的資料就是大資料了。

大量的資料是從哪來的？

小明早晨起床，想起昨天答應女友要送她一個新的包包，可是小明對包包一竅不通，鬼知道女友喜歡什麼款式啊！只能上網去搜今年的流行包包，開啟百度，查到今年流行機車包（我瞎寫的，因為我也不懂包包），於是又趕快去淘寶上搜尋機車包，可是出來的樣式千奇百怪，最慘的是價格從幾十到幾千相去甚遠，小明徹底蒙了，要是買錯了可是要跪泡麵的啊！於是又趕快開啟微信，發了個朋友圈，問問朋友圈裡的同事們該送什麼包包給女友，順便還記得遮蔽了一下女朋友。同事小麗說要買MK的，小紅卻說要買巴黎世家的，小甜說……小明徹底暈菜，乾脆把這些牌子放到淘寶裡搜一搜，找了個最貴的買下來了，寄送地址填的是老婆的上班地址。畢竟要給老婆在同事們面前顯擺才是買包包的第一要務。

在上例中，小明使用了百度、淘寶和微信，分別在其中輸入了各種關鍵字。而這三大巨頭的後臺資料庫，也把小明的這一天的行為完全的記錄了下來。

以淘寶為例，小明今天的行為資料就長這樣：

－ 使用者小明，登入
－ 搜尋機車包
－ 點選下一頁
－ 關閉頁面

半小時後

－ 使用者小明，登入
－ 搜尋 MK 機車包
－ 按價格排序
－ 點開排名第一的商品
－ 加入購物車
－ 回到搜尋頁
－ 搜尋 巴黎世家 機車包
－ 按價格排序

……

－ 點選購買
－ 填寫寄送資訊（寄送資訊地點為 上海浦東）
－ 購買成功

每一個使用者的每時每秒的資料，都會被如實的記錄下來，以淘寶的註冊使用者數量和使用者粘性來判斷，估計每天的使用者行為資料就能上PB。注意，是每天。大量的資料就這樣產生了。

多大的量才能被叫做大量的資料呢？

其實這事因時而異。大資料名詞剛被提出的時候，如果沒記錯，大約是06年吧（家裡網路不好，上不去谷歌index，明日查明之後更新），那時候，總資料量上到百級GB，就可以說自己資料量很大了，現在呢，誰還沒有個TB級的硬碟呢。

大資料和普通資料的分水嶺在於它們不同的處理方式。普通資料通常使用結構化儲存，比如大家所熟知的 MySQL ，商用的 ORACLE 等，而大資料通常使用 Hadoop 家族產品及 Hadoop 周邊產品，比如 HDFS、Hbase 和 MongoDB 等等。通常，資料量小的時候適合使用 MySQL， 而資料量大了之後，適合使用 NoSQL 儲存（比如剛剛提到的Hbase 和 MongoDB），而不同的NoSQL儲存又有它們各自的擅長之處，以後會有詳細展開。

資料大和小？看你的處理方式啦！

大量的資料有什麼用呢？

大資料在網際網路的使用場景十分廣泛，比如使用者推薦。

以上文提到的小明的行為資料為例，如果有一天淘寶、百度和騰訊合併了，三家的資料放到了一塊，通過登入裝置和 IP 地址匹配到了小明在三家網站使用的不同賬號，發現了小明這一天的完整的心路歷程。唔，這是一個會給女友買昂貴禮物的好男人，打上“願意給女友花錢的好男人”標籤吧！

第二天，小明的女友搜尋了 lamer 眼霜。

第二天的晚些時候，小明開啟淘寶，突然彈出對話方塊“您的女友搜尋了 lamer 眼霜，就等著您買給她啦！”

你說小明是買還是不買呢……

在不遠的未來，你的電腦就會比你更懂你自己了！

處理大量資料和處理少量資料有什麼區別？

在計算機界，一直有個很有意思的比喻，我們通常會把程式設計比喻成蓋房子。

資料也可以這樣比喻。

處理一個 excel 的資料可以比喻成蓋狗窩，只要是個正常人，簡單學習一下，都能蓋出一個來。就好像你處理 excel ，可以寫巨集，可以用 pivot table ，也可以手算（畢竟一個 sheet 最多也就 6 萬多行資料嘛）。

處理關係型資料可以比喻成蓋個小別墅，麻煩了些，一個人是搞不定了，得有個團隊。不過有類似 MySQL 這類的通用框架，就好像別墅的牆板全都做好了，一個人也能借助工具拼裝一下把別墅蓋好呢！

處理非關係型資料（通常大資料才需要非關係型的結構）就好像蓋一棟大樓，打地基，搭混凝土框架，每一項都是專業人士的領域，需要的人手更多，需要的時間更長。不過呢，現在採用拼搭技術，7天也能蓋一棟大樓，因為各個牆面部件全部都在工廠做好了呢，而 Hadoop 及其各種周邊們，就是計算機領域的拼搭技術，它使得一個受過培訓的普通工程師，也能獨立搭建使用分散式系統，處理大量的非關係型資料。

本文只是一個序章，後續將會和《豆醬》合作，以漫畫的形式，展現大資料的各種神奇瑰麗。

打賞支援我寫出更多好文章，謝謝！

打賞作者