首先：1.hive本身只是在hadoop map reduce 或者spark 計算引擎上的封裝，應用場景自然更侷限，不可能滿足所有需求。有些場景是不能用hive來實現，就需要map reduce或者spark rdd程式設計來實現。
2.結構複雜的日誌檔案，首先要經過etl處理（使用mapreduce），得到的資料再有hive處理比較合適。直接讓hive處理結構複雜的資料估計很難處理。
小結：業務比較複雜的，還是必須寫mapreduce才能實現。
二 背景介紹
隨著工作的資料內容越來越多,越來越複雜,對應的調整也越來越多,越來越複雜.純使用mr方式整個流程就比較複雜,如果需要修改某個部分,那首先需要修改**中的邏輯,然後把**打包上傳到某個可訪問路徑上(一般就是hdfs),然後在排程平台內執行.如果改動較大的情況,可能還會需要在測試環境中多次除錯. 總之就是會花比較多的時間在非業務邏輯改動的工作上.
考慮到維護的成本的增大,慢慢的開始準備將mr的作業,逐漸的移植到一些指令碼平台上去，hive成了我們的首選。
1. 運算資源消耗無論從時間，資料量，計算量上來看，一般情況下mr都是優於或者等於hive的。mr的靈活性是毋庸置疑的。在轉換到hive的過程中，會有一些為了實現某些場景的需求而不得不用多步hive來實現的時候。
2.2. 開發成本/維護成本
毫無疑問，hive的開發成本是遠低於mr的。如果能熟練的運用udf和transform會更加提高hvie開發的效率。另外對於資料的操作也非常的直觀，對於全世界程式設計師都喜聞樂見的sql語法的繼承也讓它更加的容易上手。
hive獨有的分割槽管理，方便進行資料的管理。
**的管理也很方便，就是直接的文字。
邏輯的修改和生效很方便。
但是當出現異常錯誤的時候，hive的除錯會比較麻煩。特別是在大的生產集群上面的時候。
3. 底層相關性
在使用hive以後，讀取檔案的時候，再也不用關心檔案的格式，檔案的分隔符，只要指定一次，hive就會儲存好。相比mr來說方便了很多。
當側重關心與業務相關的內容的時候，用hive會比較有優勢。而在一些效能要求高，演算法研究的時候，mr會更加適合。
MapReduce的推測執行（Hive優化）
在分布式集群環境下，因為程式 bug 包括 hadoop 本身的 bug 負載不均衡或者資 源分布不均等原因，會造成同乙個作業的多個任務之間執行速度不一致，有些任務的執行速 度可能明顯慢於其他任務 比如乙個作業的某個任務進度只有 50 而其他所有任務已經 執行完畢 則這些任務會拖慢作業的整體執行進度...
hive 執行mapreduce任務報錯
近期由於公司大資料集群有很多歷史遺留頑疾，進行了新舊集群的資料遷移。前期進行了大資料新集群的搭建，接下來在跑hive任務的時候，發現了乙個讓人頭痛的問題。可以看一下執行sql select substr even ttime,0,10 from ods ods.ods ods ishare log發...
用Hive實現MapReduce的單詞統計
乙個簡單的單詞統計在用mapreduce來實現雖然是經典用例，但是現實起來還是比較複雜的。下面介紹如何用hive來實現單詞統計。首先準備乙個記錄單詞的word.txt 然後在hive中新建乙個表 並將word.txt的資料匯入到該表中 然後執行如下的命令 select tt.wordtxt,coun...