1、做大數據過程中遇到的 13 個問題1、最早的數據分析可能就報表目前很多數據分析后的結果，展示的形式很多，有各種圖形以及報表，最早的應該是簡單的幾條數據，然后搞個web 頁面，展示一下數據。早期可能數據量也不大，隨便搞個數據庫，然后 SQL 搞一下，數據報表就出來了。但是數據量大起來怎么分析呢？數據分析完了怎么做傳輸呢？這么大的數據量怎么做到實時呢？分析的結果數據如果不是很大還行，如果分析的結果數據還是很大改怎么辦呢？這些問題在這篇文章中都能找到答案，下面各個擊破。 2 、要做數據分析，首先要有數據這個標題感覺有點廢話，不過要做飯需要食材一樣。有些數據時業務積累的，像交易訂單的數據，每一筆交易都

2、會有一筆訂單，之后再對訂單數據作分析。但是有些場景下，數據沒法考業務積累，需要依賴于外部，這個時候外部如果有現成的數據最好了，直接join 過來，但是有時候是需要自己獲取的，例如搞個爬蟲爬取網頁的數據，有時候單臺機器搞爬蟲可能還爬不完，這個時候可能就開始考慮單機多線程爬取或者分布式多線程爬取數據，中間涉及到一個步驟，就是在線的業務數據，需要每天晚上導入到離線的系統中，之后才可以進行分析。3、有了數據，咋分析呢？先將數據量小的情況下，可能一個復雜的 SQL 就可以搞出來，之后搞個web 服務器，頁面請求的時候，執行這個SQL ，然后展示數據，好了，一個最簡單的數據分析，嚴格意義上講是統計的分析。

3、這種情況下，分析的數據源小，分析的腳本就是在線執行的 SQL ，分析的結果不用傳輸，結果的展示就在頁面上，整個流程一條龍。4、數據量大了，無法在線分析了，咋辦呢？這個時候， 數據量已經大的無法用在線執行SQL 的形式進行統計分析了。這個時候順應時代的東西產生了（當然還有其他的，我就知道這個呵呵） ，數據離線數據工具hadoop 出來了。這個時候，你的數據以文件的形式存在，可能各個屬性是逗號分隔的，數據條數有十幾個億。這時候你可能需要構建一個hadoop 集群，然后把自己的文件導入到集群上面去， 上了集群之后， 文件就是 HDFS 的格式了， 然后如果要做統計分析，需要寫mapreduce程序，

4、所謂的 mapreduce程序，就是實現map 和 reduce 的接口，按照自己的業務邏輯寫分析流程，之后把程序打成jar 包上傳到集群，之后開始執行。分析后的結果還是文件的形式產生。 5、分析個數據還要寫 java 代碼是不是效率低了點這個確實是， mapreduce 的程序，本身的可測性沒有執行一個簡單的單元測試來的爽，所以效率確實不高。這個時候， hive 出現了， hive 是一個數據倉庫分析的語言， 語法類似于數據庫的 SQL ， 但是有幾個地方是不同的。有了 hive 之后，數據分析就好之前寫 SQL 一樣了，按照邏 輯編寫 hive SQL ，然后控制臺執行。可能最大的感覺是，

5、數據庫的 sql 很快就能有結果，但是hive 的，即使很小的一個數據分析，也需要幾分鐘時間。構建hive ，需要在 hadoop的集群上，原理很簡單，就是把文件構建成表的形式（有一個數據庫或者內存數據庫維護表的schema信息），之后提交寫好的 hive sql 的時候， hadoop 集群里面的程序把 hive 腳本轉換成對應的 mapreduce程序執行。這個時候，做離線的數據分析簡單寫腳本就行了，不用再搞java 代碼，然后上傳執行了。6、數據產生的結果，怎么搞到線上提供服務的數據庫中呢？這個時候分析的結果有了，可能是一個很寬很長的excel 表格， 需要導入到線上的數據庫中， 可能你

6、想到了， 如果我的數據庫是mysql ，我直接執行load 命令就搞進去了，哪有那么麻煩。但是數據源可能有多了，mysql/oracle/hbase/hdfs 按照笛卡爾積的形式， 這樣搞要搞死程序員了。這個時候 datax （已經開源）生現了，能夠實現異構數據源的導入和導出，采用插件的形式設計，能夠支持未來的數據源。如果需要導數據，配置一下 datax 的 xml 文件或者在 web 頁面上點擊下就可以實現了。7、離線分析有時間差，實時的話怎么搞呢？要構建實時的分析系統，其實在結果數據出來之前，架構和離線是截然不同的。數據時流動的，如果在大并發海量數據流動過程中，進行自己的業務分析呢？這里其

7、實說簡單也簡單，說復雜也復雜。目前我接觸過的，方案是這樣的，業務數據在寫入數據庫的時候，這里的數據庫 mysql ， 在數據庫的機器上安裝一個程序， 類似 JMS的系統，用于監聽binlog 的變更，收到日志信息，將日志信息轉換為具體的數據，然后以消息的形式發送出來。這個時候實現了解耦，這樣的處理并不影響正常的業務流程。這個時候需要有個Storm 集群， storm 集群干啥事情呢？就一件事情， 分析數據， 這個集群來接收剛才提到的 JMS 系統發送出來的消息，然后按照指定的規則進行邏輯合并等計算，把計算的結果保存在數據庫中，這樣的話，流動的數據就可以過一遍篩子了。8、分析的結果數據特別大，在

8、線請求這些結果數據數據扛不住了，咋搞？一般的結果數據，數據量沒有那么大，也就幾十萬的樣子，這樣的數據級別，對于 mysql這樣的數據庫沒有任何壓力，但是這個數據量如果增加到千萬或者億級別，同時有復雜的 SQL 查詢，這個時候mysql肯定就扛不住了。這個時候，可能需要構建索引（例如通過lucene 來對于要檢索的字段添加索引） ， 或者用分布式的內存服務器來完成查詢。總之，兩套思路，一個是用文件索引的形式，說白來就是空間換時間，另外一種是用內存，就是用更快的存儲來抗請求。9、 在線的數據庫， 除了 mysql 、 oracle之外，還有其他選擇不？其實目前大家的思維定勢，往往第一個選擇就是 o

9、racle 或者 mysql ，其實完全可以根據場景來進行選擇， mysql 和 oracle 是傳統的關系型數據庫， 目前 nosql類的數據庫也很多，例如 HBase 就是其中一個重要的代表。如果數據離散分布比較強，且根據特定的 key 來查詢，這個時候 HBase 其實是一個不錯的選擇。 10、空間的數據怎么分析上面的分析大都是統計維度的，其實最簡單的描述就是求和或者平均值等，這個時候問題來了，大數據量的空間數據如何分析呢？對于我們電子商務而言，空間數據可能就是海量的收貨地址數據了。需要做分析，第一步就是先要把經緯度添加到數據中（如果添加經緯度，這個可以搞 http 的請求來通過地圖服務

10、提供商來或者，或者是根據測繪公司的基礎數據來進行文本切割分析） ，之后空間數據是二維的，但是我們常見的代數是一維的，這個時候一個重要的算法出現了，geohash算法，一種將經緯度數據轉換為一個可比較，可排序的字符串的算法。然后，這樣就可以再空間距離方面進行分析了，例如遠近，例如方圓周邊等數據的分析。 11 、上面這些僅僅是統計，如果想搞算法或者挖掘之類的，怎么搞呢上述的分析，大多數是統計分析，這個時候如果想高一點高級的，例如添加一個算法，咋搞呢？其他復雜的算法我沒咋接觸過。將拿一個我練過手的算法來講吧。邏輯回歸，如果樣本數據量不是很大，可以采用 weka 來做了個回歸，獲得一個表達式，然后在線

11、上系統中應用這個表達式，這種類似的表達式獲取對于實時性要求不是很高，所以公式每天跑一次就行了。如果數據量比較大，單機的 weka 無法滿足需求了，可以將weka 的 jar 包集成在系統中分析，當然也可以通過 hadoop 中的 mahout 來進行離線分析，獲取這個表達式。 12 、 我就是想離線分析數據， 但是受不了 hive 或者 hadoop的速度，咋搞其實搞過一段時間 hadoop 的人肯定有一點不爽，就是離線分析的速度太慢了，可能需要等很久，這個時候 spark 出現了， 他和 hadoop 類似， 不過由于是內存中計算，所以速度快了很多，底層可以介入HDFS 的文件系統，具體我沒有使用過，但是公司內部一個團隊目前已經