這篇文章來自一個公司内部的分享，是自己所服務的業務中資料平台的發展曆程，已經講了有幾個月了，最近打算挑幾個點拿出來用文章的形式寫出來。是自己進入公司以來參與過或者接觸過的資料型項目的情況。基本包含了業務資料分析的整個流程。這篇文章純文字描述，沒有任何圖呵呵。是以看我需要耐心。
目前很多資料分析後的結果，展示的形式很多，有各種圖形以及報表，最早的應該是簡單的幾條資料，然後搞個web頁面，展示一下資料。早期可能資料量也不大，随便搞個資料庫，然後sql搞一下，資料報表就出來了。但是資料量大起來怎麼分析呢？資料分析完了怎麼做傳輸呢？這麼大的資料量怎麼做到實時呢？分析的結果資料如果不是很大還行，如果分析的結果資料還是很大改怎麼辦呢？這些問題在這篇文章中都能找到答案，下面各個擊破。
這個标題感覺有點廢話，不過要做飯需要食材一樣。有些資料時業務積累的，像交易訂單的資料，每一筆交易都會有一筆訂單，之後再對訂單資料作分析。但是有些場景下，資料沒法考業務積累，需要依賴于外部，這個時候外部如果有現成的資料最好了，直接join過來，但是有時候是需要自己擷取的，例如搞個爬蟲爬取網頁的資料，有時候單台機器搞爬蟲可能還爬不完，這個時候可能就開始考慮單機多線程爬取或者分布式多線程爬取資料，中間涉及到一個步驟，就是線上的業務資料，需要每天晚上導入到離線的系統中，之後才可以進行分析。
先将資料量小的情況下，可能一個複雜的sql就可以搞出來，之後搞個web伺服器，頁面請求的時候，執行這個sql，然後展示資料，好了，一個最簡單的資料分析，嚴格意義上講是統計的分析。這種情況下，分析的資料源小，分析的腳本就是線上執行的sql，分析的結果不用傳輸，結果的展示就在頁面上，整個流程一條龍。
這個時候，資料量已經大的無法用線上執行sql的形式進行統計分析了。這個時候順應時代的東西産生了（當然還有其他的，我就知道這個呵呵），資料離線資料工具hadoop出來了。這個時候，你的資料以檔案的形式存在，可能各個屬性是逗号分隔的，資料條數有十幾個億。這時候你可能需要建構一個hadoop叢集，然後把自己的檔案導入到叢集上面去，上了叢集之後，檔案就是hdfs的格式了，然後如果要做統計分析，需要寫mapreduce程式，所謂的mapreduce程式，就是實作map和reduce的接口，按照自己的業務邏輯寫分析流程，之後把程式打成jar包上傳到叢集，之後開始執行。分析後的結果還是檔案的形式産生。
這個确實是，mapreduce的程式，本身的可測性沒有執行一個簡單的單元測試來的爽，是以效率确實不高。這個時候，hive出現了，hive是一個資料倉庫分析的語言，文法類似于資料庫的sql，但是有幾個地方是不同的。有了hive之後，資料分析就好之前寫sql一樣了，按照邏輯編寫hive sql，然後控制台執行。可能最大的感覺是，資料庫的sql很快就能有結果，但是hive的，即使很小的一個資料分析，也需要幾分鐘時間。建構hive，需要在hadoop的叢集上，原理很簡單，就是把檔案建構成表的形式（有一個資料庫或者記憶體資料庫維護表的schema資訊），之後送出寫好的hive sql的時候，hadoop叢集裡面的程式把hive腳本轉換成對應的mapreduce程式執行。這個時候，做離線的資料分析簡單寫腳本就行了，不用再搞java代碼，然後上傳執行了。
這個時候分析的結果有了，可能是一個很寬很長的excel表格，需要導入到線上的資料庫中，可能你想到了，如果我的資料庫是mysql，我直接執行load 指令就搞進去了，哪有那麼麻煩。但是資料源可能有多了，mysql/oracle/hbase/hdfs 按照笛卡爾積的形式，這樣搞要搞死程式員了。這個時候datax（已經開源）出現了，能夠實作異構資料源的導入和導出，采用插件的形式設計，能夠支援未來的資料源。如果需要導資料，配置一下datax的xml檔案或者在web頁面上點選下就可以實作了。
要建構實時的分析系統，其實在結果資料出來之前，架構和離線是截然不同的。資料時流動的，如果在大并發海量資料流動過程中，進行自己的業務分析呢？這裡其實說簡單也簡單，說複雜也複雜。目前我接觸過的，方案是這樣的，業務資料在寫入資料庫的時候，這裡的資料庫mysql，在資料庫的機器上安裝一個程式，類似jms的系統，用于監聽binlog的變更，收到日志資訊，将日志資訊轉換為具體的資料，然後以消息的形式發送出來。這個時候實作了解耦，這樣的處理并不影響正常的業務流程。這個時候需要有個storm叢集，storm叢集幹啥事情呢？就一件事情，分析資料，這個叢集來接收剛才提到的jms系統發送出來的消息，然後按照指定的規則進行邏輯合并等計算，把計算的結果儲存在資料庫中，這樣的話，流動的資料就可以過一遍篩子了。
一般的結果資料，資料量沒有那麼大，也就幾十萬的樣子，這樣的資料級别，對于mysql這樣的資料庫沒有任何壓力，但是這個資料量如果增加到千萬或者億級别，同時有複雜的sql查詢，這個時候mysql肯定就扛不住了。這個時候，可能需要建構索引（例如通過lucene來對于要檢索的字段添加索引），或者用分布式的記憶體伺服器來完成查詢。總之，兩套思路，一個是用檔案索引的形式，說白來就是空間換時間，另外一種是用記憶體，就是用更快的存儲來抗請求。
其實目前大家的思維定勢，往往第一個選擇就是oracle或者mysql，其實完全可以根據場景來進行選擇，mysql和oracle是傳統的關系型資料庫，目前nosql類的資料庫也很多，例如hbase就是其中一個重要的代表。如果資料離散分布比較強，且根據特定的key來查詢，這個時候hbase其實是一個不錯的選擇。
上面的分析大都是統計次元的，其實最簡單的描述就是求和或者平均值等，這個時候問題來了，大資料量的空間資料如何分析呢？對于我們電子商務而言，空間資料可能就是海量的收貨位址資料了。需要做分析，第一步就是先要把經緯度添加到資料中（如果添加經緯度，這個可以搞http的請求來通過地圖服務提供商來或者，或者是根據測繪公司的基礎資料來進行文本切割分析），之後空間資料是二維的，但是我們常見的代數是一維的，這個時候一個重要的算法出現了，geohash算法，一種将經緯度資料轉換為一個可比較，可排序的字元串的算法。然後，這樣就可以再空間距離方面進行分析了，例如遠近，例如方圓周邊等資料的分析。
上述的分析，大多數是統計分析，這個時候如果想高一點進階的，例如添加一個算法，咋搞呢？其他複雜的算法我沒咋接觸過。将拿一個我練過手的算法來講吧。邏輯回歸，如果樣本資料量不是很大，可以采用weka來做了個回歸，獲得一個表達式，然後線上上系統中應用這個表達式，這種類似的表達式擷取對于實時性要求不是很高，是以公式每天跑一次就行了。如果資料量比較大，單機的weka無法滿足需求了，可以将weka的jar包內建在系統中分析，當然也可以通過hadoop中的mahout來進行離線分析，擷取這個表達式。
其實搞過一段時間hadoop的人肯定有一點不爽，就是離線分析的速度太慢了，可能需要等很久，這個時候spark出現了，他和hadoop類似，不過由于是記憶體中計算，是以速度快了很多，底層可以介入hdfs的檔案系統，具體我沒有使用過，但是公司内部一個團隊目前已經用spark來進行分析了。
有了這些工具就是搞大資料了？答案肯定不是，這個僅僅是工具罷了。真正搞大資料的可能在于思維的變化，用資料來思考，用資料來做決定。目前的無線和大資料啥關系？我覺得無線的終端是資料的來源和消費端，中間需要大資料的分析，兩者密不可分啊。
至此，我的疑問ok了，這些問題摸索差不多用了兩年左右的時間，最終擷取的，可能就是大資料分析的解決方案了。
<b>原文釋出時間為：2013-11-25</b>
<b></b>
<b>本文來自雲栖社群合作夥伴“大資料文摘”，了解相關資訊可以關注“bigdatadigest”微信公衆号</b>