大數據項目如何更科學地規劃數據存儲問題呢？

 大數據項目項目的業務背景一般都是比較復雜的，所以數據來源及數據種類也是參差不齊，那么，我們需要怎樣更好地規劃數據存儲方面的東西呢？

    首先，我們來說說為什么我們需要關注數據存儲的問題。第一，上面也說了，數據源種類多而復雜，面臨各種集成的問題與使用的問題。第二，大數據分析的過程離不開ETL（數據抽取、轉換、加載），這也是做分析的前提，因此對于數據源的存儲是不容忽視的。那么，基于上面的原因，我們是否可以很肯定地說，現實項目實施過程中，一個HBase是不能夠完成復雜的數據源項目背景的需求的呢？下面，我們來分析一下。

    由于HBase是一個半結構化的數據倉庫，與傳統的RDB有很大區別，HBase更重要的是結構，而不是類型。那么我們可以假設把數據分成3類：無結構數據、半結構化數據、結構化數據。其實對于Java程序員出身的人來說，無結構化數據是很難理解的，因為沒有不能抽象化成對象的事物存在嘛，但是像Log日志文件這種數據源，它確實是種無結構化數據（當然這是以各種不同Log文件來說，這里不討論個人輸出的格式化數據）。對于半結構化的數據，就像上面說的HBase一樣。HBase的鼻祖是Google公司的BigTable，據說Google公司的地圖等數據存儲都是用BigTable，并且性能非常卓越，具體是不是這樣就不清楚了。其實我在想，結構化數據是可以轉化成半結構化數據的，因為只要他們都擁有共同的結構，是可以向上轉化，就像Java里面的任何類都是Object類的子類一樣，都可以轉化為Object類，我們把強類型的數據轉化成弱類型數據。

    再回到我們大數據項目來說，如果能夠把各式各樣的數據轉換成半結構化數據存儲到HBase中，那么我們對數據的集中讀取與管理是非常方便的，但是數據的轉換、讀取性能、數據靈活性就將成為重要的性能瓶頸。打個比方，對于實時監控或者實時分析較強的行業，如果我們把傳送回來的數據經過轉換再存儲，讀取時還需要做大量的數據類型轉換、異常、合法性判斷等，中間的時效性就會降低，那么數據的意義會大打折扣，因此，我們不能否認了RDB的地位。

    總結上面的討論，可以得出這樣一個結論：大數據的數據存儲大致地可以規劃成這3類：與Log日志文件相類似的無結構數據源、與HBase半結構化數據相類似的數據源、以RDB存儲的數據源。種3種數據源基本上可以包含了大部分大數據項目的需求，當然實際上3種數據源的權重，就要根據實際項目的背景需求去衡量了！