Hive Hive將HiveQL（類sql語言）轉為MapReduce，完成數據的查詢與分析，減少了編寫MapReduce的複雜度。它有以下優點： 學習成本低：熟悉sql就能使用 良好的數據分析：底層基於MapReduce實現 同樣存在一些缺點： HiveDL表達能力有限 效率不高 Hive調優比較 ...
資料庫項目的代碼組織大致有兩種形式：增量式與快照式。
Entity Framework (Core)的資料庫遷移工程就是經典的增量式組織形式：有專門的遷移歷史表標識增量版本，不同版本之間的升級、降級由相應的腳本專職負責。在升/降級腳本的編撰過程中，有經驗的資料庫開發工程師會採取各種措施，來實現數據無損發佈。
快照式組織形式的典型是微軟的SQL Server工程（即.sqlproj工程）：工程中為每個對象列出最終腳本，按Object Type方式分門別類放置於不同的目錄下；工程編譯後得到一個DACPAC文件表達資料庫的期望架構，利用SqlPackage.exe工具，與目標資料庫比較後自動生成遷移腳本。
兩種組織形式各有其優缺點：
- 快照式的代碼組織結構簡潔明瞭，對象定位迅速、方便；但SqlPackage.exe工具比較傻，即使選擇冪等方式其自動生成的遷移腳本仍有數據損失的風險，必須由有經驗的資料庫開發人員把關，通常得進行適當的調整才敷使用。
- 增量式的發佈沒有數據損失風險，可以很方便地通過連續集成平臺實現自動發佈；但對象代碼組織凌亂不易定位，對象的更改歷史不清晰明確，對開發極不友好。
必須指出，對象代碼組織凌亂不易定位是很嚴重的問題。每當對某個已經存在的對象進行調整時，開發人員必須向上追溯到最近的一個版本，在此基礎上進行更改——這是一個很容易產生錯誤的環節，比如追溯到的不是最近的版本而是上上一個版本，比如多人協同時有人有不良習慣，屢屢更改其已提交的增量腳本而未通知其他開發人員，等等。
而對象的更改歷史不清晰明確也是很嚴重的缺點。首先如前所敘，將涉及到同一個對象的增量腳本找出來本身即是費力的工作；其次，通常地一個增量腳本可能包含多個對象的更改，使用代碼比較工具時會引入大量雜訊不利分析。
筆者在數個項目中需要開發達數千行代碼的存儲過程，對此深有體會。
那麼這兩種組織形式在實踐中該如何選擇呢？個人的體會是，純粹地追求快照式或增量式都不是好的選擇，應該混合起來用：
- 每個對象在工程中有一個最終腳本，留存其在當前版本中的快照；
- 工程中專門設立一個增量腳本目錄，放置對錶結構、索引、系統數據的更改腳本；
- 由專門的工具實施資料庫遷移，在遷移過程中首先（根據歷史版本號）決定必須執行的增量腳本，執行之並更新曆史版本號，然後遍歷快照腳本區，將其中的編程對象，按函數、視圖、存儲過程、觸發器的次序依次執行其腳本。
其中第二點、第三點容易產生疑問：為什麼不對編程對象產生增量腳本？首先這些編程對象的更改天然就不表現為增量形式，不象表結構、系統數據的更改那樣只提及發生變化的部分，而是在ALTER命令中以完全體的形式出現，硬加入增量腳本會大幅增加其尺寸並分散開發人員註意力；其次，如視圖這種編程對象，當底層表結構發生變化後通常必須在資料庫里重新聲明一次；再次，（由於開發人員的失誤）編程對象中可能含有不適應增量腳本變更的代碼段，因為SQL Server的延遲解析特性，不重新聲明一次不會報告此類錯誤。
索引的更改其實也表現為完全體形式：同名的索引要進行調整隻能先DROP後CREATE。放在增量腳本中加以體現，是出於以下考慮：
- 因為創建索引是非常消耗資源的行為，尤其當目標表含有大量數據且不是採用著昂貴的企業版SQL Server（有線上索引創建支持）時，應儘量避免重建索引的操作；
- 索引有大量元數據，如何確認索引是否發生了變化需要很繁瑣的代碼。
書寫增量腳本時，目標索引已經很明確需要更改了，上述兩點便不再成為問題。
在這樣一種混合代碼組織中，首先建議編程對象的書寫遵從一定規範，比如這樣
IF (OBJECT_ID(N'dbo.MyProc', N'P') IS NULL) BEGIN; EXEC sys.sp_executesql N'CREATE PROC dbo.MyProc AS RETURN;'; END; GO ALTER PROC dbo.MyProc AS BEGIN; SET NOCOUNT ON; /* The logic code here */ END; GO
可以避免編程對象的元數據，如create_date發生變化；其次，要廢棄的編程對象其腳本文件必須保留，其內容是檢查該對象是否存在，若存在則需刪除，即
IF (OBJECT_ID(N'dbo.MyProc', N'P') IS NOT NULL) BEGIN; DROP PROC dbo.MyProc; END;
採用這種代碼組織形式的缺點是，需要自己開發相應的遷移工具進行部署。但這個開發工作量並不大，而且其他資料庫項目也可以使用這個工具，只要其目錄結構滿足事先約定。我司2006年借鑒Jesse Hersch （Elsasoft LLC）的思路利用SMO（SQL Server Object Managerment）庫開發的遷移工具延用至今，滿足了大量項目的需求。
當然時至今日此工具表現出了一些缺點，最大的缺點是依賴的SMO庫有32位和64位兩種不相容版本，而且似乎微軟也不再進行升級。其實遷移工具中只使用了SMO中的一樣功能，執行包含GO命令的T-SQL腳本，所以很容易擺脫對其依賴：一種方法是取GO加回車為分隔符，將T-SQL腳本拆分成幾段依次調用SqlCommand執行；另一種是調用System.Diagnositics.Process，使用-i -I開關【1】執行SqlCmd命令運行T-SQL腳本【2】。這兩種方式用PowerShell、C#腳本都可以很方便地實現。
【1】SqlCmd命令預設關閉引用標識符（Quoted Identifier），所以需要用開關-I顯式打開。
【2】這一方式要求分發伺服器上裝有SqlCmd工具。
