1樓：tharvest
肯定不能使用hive更新，所謂的更新也是用增量資料merge歷史資料後儲存而替換歷史資料。如果對實效性要求不高，比如T+1，一般是按天分割槽，按天分割槽實際上已經儲存了一條記錄按天的變化維。
按天同步資料存在乙個缺點，就是業務資料庫的一條記錄在一天內更新多次，只能取到資料同步時該記錄的最後狀態。
如果對資料的實效性和記錄變化狀態有要求，那麼就需要採用實時資料同步，實時同步可以採用流處理技術（structured streaming，flink等）結合實時插入效率較高的儲存引擎如hbase，kudu，clickhouse等。
2樓：王小新
hive更新用overwrite關檢詞可以做，也可以做拉鍊，前提是你的資料量要小，每天新增資料量可控，不然速度超級慢，最好的方式就是不處理，因為有分割槽的存在，每次選取分割槽時間最近的，也就相當於做了乙個拉鍊，不考慮效能可以用overwrite
3樓：taisenki
基本不用hive做資料更新……
資料更新還是考慮修改底層支撐來的更快，比如換HBase或者Kudu，或者其他的一些支撐架構。
資料倉儲與大資料的區別？
小蘿蔔運算元 先直接說區別 大資料是一種技術手段 資料倉儲是乙個存放資料的集合 乙個是手段，乙個是結果。大資料 現在的我，一看到 大資料 三個字，腦子立刻蹦出各種工具 離線計算 hadoop，hive.實時計算 flink,storm,spark,kafka.還記得我大學剛畢業在一家傳統行業的公司工...
在Hive中適不適合像傳統資料倉儲一樣利用維度建模？
朱成建 首先我覺得hive的定位是大量資料的非實時性處理，hive是使用分布式的架構去處理各種資料，換句話說就是ETL工具，而且無法達到實時處理資料的要求。而維度建模，是針對關係系資料資料分析查詢為目標設定一套資料組織方法。假如我們最終的分析資料要儲存在關係型資料庫中，我們就可以考慮維度建模。但是h...
如何量化評價乙個資料倉儲的好壞？
歌者安虹 首先得確定你是想從技術的角度還是資料業務的角度來看這個問題。從技術角度無外乎高併發，低延遲，負載均衡，災備容錯機制完善，擴充套件性，元件通用性，運維成本等方面評價。從資料業務角度來考慮要從資料分層合理性，元資料治理，維度管理，業務主題域劃分合理性，ETL邏輯健壯度，冷熱資料分流規劃，資料耦...