近幾年大資料的概念被炒的紅紅火火，各種雲應運而生，也有不少企業開始搭載自己的雲，但是真的什麼企業都需要嗎？下面我要說的也僅僅是基於我目前工作的一些感想，歡迎拍磚！

   公司的主要資料是利用HBase收集的報文，整個到目前執行了一年零一兩個月的時間。目前資料量是266GB（其中包含一份完全副本，實際業務資料133GB），在7月出進行資料統計時，該平臺資料量為250GB（其中包含一份完全副本，實際業務資料125GB），並且通過計算可以得知，在過去14個月內，平均每月獲得的資料量為9.5GB，並且7月份一個月的時間內HBase收集的報文為8GB左右。

   通過上面的描述可以看出這個業務的資料量並不大，可能很多公司tomcat一天的日誌量都比這一年的總資料量要大的多。並且在前段時間對HBase內表的資料進行了一次統計，大約有700W的資料，搜尋一共耗時20分鐘左右。說實話，這個速度並不算快，由於節點數量的不足並不能充分發揮HBase在分散式上的有點，但是這個時間對比Oracle真的能有提升嗎？

   在有了如上疑問後跟領導進行了溝通，領導要表達的是：不管是不是合適，我們要先搶佔技術的高峰，就算目前資料量不大以後也會變大。根據領導的回答我也算明白了，當初在構建這個平臺的時候基本沒有考慮到這個平臺是否符合業務邏輯的需求（PS:雖然我在這個公司也不想涉及到業務邏輯方面的內容），只是因為這個東西很新，很火。

   在和領導溝通後，我簡單的瞭解了一下表內的內容：時間、報文型別（公司設定的傳送報文、接受報文、企業報文用不同的編號來表示）、報文XML檔案。說真的，儲存的方式對於分析來說作用很小，因為XML檔案沒有解析，所以有了第二次溝通。

   在第二次溝通前我瞭解了一下關於XML解析方面的內容，可以通過Java程式解析後再報錯，同時Hadoop在某一個版本是確實存在著XML解析的類，不過後來被取消了。溝通的結果就是領導讓我去想辦法弄XML的解析，說真的這東西我真力不從心。後來的幾次溝通也是這樣（內容多種多樣，包含HBase的API介面壓力測試，雲平臺改進想法文件等等），最後都是無功而返。

   通過多次的溝通，我始終覺得領導從來沒有在這個系統是不適合Hadoop上進行過思考，每次一說到這個，就開始跟我說百度、谷歌每天要對幾個PB的檔案進行分析，而我們對百十來個GB的資料束手無策。但是真的是束手無策嗎？每次溝通我都會說一些想法，最後也都被很容易得PASS了，原因大部分都是因為他試驗過效率不行等原因。

   一個月就算多說10個G的資料量，平均到每天也就不足350MB。真的都放到Oracle甚至MySQL裡面每天跑個列表出來應該並不困難。而堅定的認為Hadoop在架構上比那兩個更先進，所以效果就更好。這裡我打個比方吧！

   一個人走路的速度比騎車的速度慢，騎車的速度又比汽車的速度慢！同樣是5公里，走路可能需要半個小時，騎車需要15分鐘，汽車需要10分鐘。但是如果你想從一個樓到對面的樓裡面去那？你會選擇開走路、汽車還是騎車那一種？如果你要是去1公里外的報亭買報紙你會選擇開走路、汽車還是騎車那一種？如果你去50公里外的地方郊遊你會選擇開走路、汽車還是騎車那一種？

   現在的情況是：

   小部分企業給人的感覺就是開著汽車去隔壁串門！

   大部分企業跟人的感覺是開著汽車去一公里外的地方買報紙！

   極小一部分的企業是開著汽車去郊遊！