# Kudu Transaction Semantics ( 事務語義 )
原文鏈接 : [http://kudu.apache.org/docs/transaction_semantics.html](http://kudu.apache.org/docs/transaction_semantics.html)
譯文鏈接 : [http://cwiki.apachecn.org/pages/viewpage.action?pageId=10813638](http://cwiki.apachecn.org/pages/viewpage.action?pageId=10813638)
貢獻者 : [小瑤](/display/~chenyao) [ApacheCN](/display/~apachecn) [Apache中文網](/display/~apachechina)
## Apache Kudu 的 Transaction Semantics ( 事務語義 )
這是 **Kudu** 的 交易和一致性語義的簡要介紹。對于這里提到的大部分內容的深入技術論述，為什么是正確的，請參閱技術報告[[1]](/pages/viewpage.action?pageId=10813638)。
**Kudu** 的 ?**transactional semantics** ( 事務語義 )和體系結構受到 **Spanner** [[2]](/pages/viewpage.action?pageId=10813638) 和 **Calvin** [[3]](/pages/viewpage.action?pageId=10813638) 等最先進的系統的啟發。 **Kudu** 建立在數十年的數據庫研究基礎之上。核心理念是通過提供簡單，強大的語義的事務，使開發人員的生活更輕松，而不會犧牲性能或調整到不同需求的能力。
**Kudu** 旨在最終完全獲得 **ACID** ，但是多 **tablet** 事務尚未實施。因此，本次討論的重點是單片寫入操作，只是簡單地觸摸多 **tablets** 讀取。最終 **Kudu** 將支持完全嚴格的可序列化語義。事實上，它已經在有限的范圍內，但并不是所有的角落都被覆蓋，因為這仍然是一個正在進行的工作。
**Kudu** 目前允許以下操作：
* **Write operations** ( 寫入操作?)?是在具有多個副本的單個 **tablet** 中在存儲引擎中插入，更新或刪除的 **sets of rows?**( 行集?) 。寫操作沒有單獨的 **“read sets”** ，即它們在執行寫入之前不掃描現有數據。每個寫入僅涉及即將更改的行的先前狀態。用戶明確不寫 **“committed”** 。相反，它們將在系統完成后自動提交。
* **Scans**?( 掃描?) 是可以遍歷多個 **tablets** 并讀取信息的讀取操作，具有一致性或正確性保證。掃描可以執行時間行進讀取，即用戶能夠設置過去的掃描時間戳，并返回在該時間點反映存儲引擎的狀態的結果。
重要
**開始之前**
* 多次提到術語時間戳來說明功能，但是時間戳是用戶最不可見的內部概念，除了在 **KuduScanner** 上設置時間戳。
* 我們通常指的是 **C ++ ?client** 的方法和類。雖然 **Java** 客戶端大多具有類似的方法和類，但是 **API** 的確切名稱可能不同。
## Single tablet write operations ( 單 tablet 寫入操作 )
**Kudu** 采用 **Multiverion** 并發控制 （**MVCC**） 和 Raft 一致性算法 [[4]](/pages/viewpage.action?pageId=10813638) 。**Kudu** 的每個寫入操作必須經過 tablet 的領導。
1. leader 將為其將更改的行獲取所有鎖。
2. leader 在提交寫入復制之前分配寫入時間戳。這個時間戳是 **MVCC** 中的 **write** 的 **“tag”** 。
3. 在大多數副本確認更改后，實際的行將被更改。
4. 更改完成后，它們可以以原子方式同時進行寫入和讀取。
**tablets** 的所有副本都遵循相同的操作順序，如果為寫入操作分配時間戳 **n** 并更改 行 **x** ，則保證時間戳 **m > ?n** 的第二次寫入操作可以看到 x 的新值。
鎖定采集和時間戳分配的這種嚴格排序通過協商一致的方式強制執行 **tablets** 的所有副本。因此，相對于同一個平板電腦中的其他寫入，關于時鐘分配的時間戳，寫入操作是完全排序的。換句話說，寫入具有嚴格的可序列化語義，盡管在一個公認的有限的上下文中。有關這些語義是什么意思，請參閱這篇 [博客文章](http://www.bailis.org/blog/linearizability-versus-serializability) 。
雖然在 **ACID** 意義上的隔離和耐用性，多行寫入操作尚未完全原子化。批量操作中單次寫入的故障不會回滾操作，而是產生每行錯誤。
## Writing to multiple tablets ( 寫入多個 tablets )
**Kudu** 還不支持跨多個 **tablets** 的事務。但是，一致的快照讀取是可能的（如當前實現中的警告），如下所述。
**Kudu** 客戶端的寫入可選地緩沖在內存中，直到它們被刷新并發送到服務器。當客戶端的會話刷新時，每個 **tablet** 的行被批處理在一起，并發送到托管 **tablet** 的 **leader replica** 的 **tablet servers** 。由于沒有 **inter-tablet** 事務，這些批次中的每一個代表具有自己的時間戳的單獨的獨立寫入操作。然而，客戶端 **API** 提供了對分配的時間戳施加一些約束的選項，以及客戶端如何觀察對不同 **tablet** 的寫入。
**Kudu** 像 **Spanner** 一樣被設計為外部一致 [[5]](/pages/viewpage.action?pageId=10813638) ，即使在跨多個平板電腦甚至多個數據中心的情況下也能保持一致性。在實踐中，這意味著如果寫入操作在平板電腦 **A** 上更改項目 **x** ，并且以下寫入操作在平板電腦 **B** 上更改項目 **y** ，則可能需要強制執行，如果觀察到 **y** 的更改，則 **x** 的更改也必須為觀察到的。有很多例子可以說是重要的。例如，如果 **Kudu** 正在存儲用于進一步分析的點擊流，并且兩次點擊相互關聯，但存儲在不同的 **tablet** 中，則后續點擊應該被分配后續時間戳，以便捕獲它們之間的因果關系。
**CLIENT_PROPAGATED Consistency**
**Kudu** 的默認外部一致性模式稱為 **CLIENT_PROPAGATED** 。有關如何工作的詳細說明，請參閱 [[1]](/pages/viewpage.action?pageId=10813638) 。簡而言之，此模式會導致單個客戶端的寫入自動在外部保持一致。在上述 **Clickstream** 場景中，如果兩個點擊是由不同的客戶端實例提交的，則應用程序必須手動將時間戳從一個客戶端傳播到另一個客戶端，以便捕獲因果關系。
客戶端 **a** 和 **b** 之間的時間戳可以傳播如下：
**Java Client**
調用?**AsyncKuduClient#getLastPropagatedTimestamp()** 在客戶端 **a** ，將時間戳傳播到客戶端 **b** ，并在客戶端 **b** 上調用**AsyncKuduClient#setLastPropagatedTimestamp()** 。
**C++ Client**
在客戶端 **a** 上調用**KuduClient::GetLatestObservedTimestamp()** ，將時間戳傳播到客戶端 **b** ，并在客戶端 **b** 上調用?**KuduClient::SetLatestObservedTimestamp()** 。
**`COMMIT_WAIT`?Consistency**
**Kudu** 還有一個在 **Google** 的 **Spanner** 中使用的外部一致性模型的實驗實現，稱為 **COMMIT_WAIT** 。 ?**COMMIT_WAIT** 通過在集群中的所有計算機上緊密同步時鐘來起作用。然后，當發生寫入時，分配時間戳，并且在通過足夠的時間之前寫入的結果不可見，使得集群中的其他計算機不可能為下一次寫入分配較低的時間戳。
當使用此模式時，寫入的延遲與所有集群主機上的時鐘精度緊密相關，并且使用松散時鐘同步的此模式會導致寫入需要很長時間才能完成甚至超時。請參閱 [已知問題和限制](/pages/viewpage.action?pageId=10813638) 。
**COMMIT_WAIT**一致性模式可以如下選擇：
**Java Client**
調用 **KuduSession#setExternalConsistencyMode(ExternalConsistencyMode.COMMIT_WAIT)**
**C++ Client**
調用 **KuduSession :: SetExternalConsistencyMode(COMMIT_WAIT)**
注意
**COMMIT_WAIT** 一致性被認為是一個實驗功能。它可能會返回不正確的結果，展示性能問題或對集群穩定性產生負面影響。不鼓勵在生產環境中使用。
## Read Operations (Scans) ( 閱讀操作(掃描) )
掃描是由可能跨越一個或多個 **tablets** 跨越一行或多行的客戶端執行的讀取操作。當服務器接收到掃描請求時，會收到 **MVCC** 狀態的快照，然后根據用戶選擇的讀取模式，以兩種方式之一進行。該模式可以如下選擇：
**Java Client**
調用 **KuduScannerBuilder#setReadMode(...)**
**C++ Client**
調用 **KuduScanner :: SetReadMode()**
以下模式在兩個客戶端都可用：
**READ_LATEST**
這是默認的讀取模式。服務器拍攝 **MVCC** 狀態的快照，并立即繼續閱讀。在此模式下讀取只會產生 **“Read Committed”** 隔離。
**READ_AT_SNAPSHOT**
在這種讀取模式下，掃描是一致的和可重復的。快照的時間戳由服務器選擇，或由用戶通過 **KuduScanner :: SetSnapshotMicros()** 顯式設置。建議明確設置時間戳;見 [**Recommendations** ( 建議書?)](/pages/viewpage.action?pageId=10813638)?。服務器等待，直到這個時間戳為 **“safe”** （直到所有具有較低時間戳的寫入操作都已完成并可見）。這種延遲加上外部一致性方法，最終將允許 **Kudu** 具有完全嚴格可序列化的讀寫語義。這仍然是一個正在進行的工作，一些異常仍然是可能的（請參閱 [已知問題和限制](/pages/viewpage.action?pageId=10813638) ）。只有在這種模式下進行掃描可以是容錯的。
在讀取模式之間進行選擇需要平衡權衡并做出適合您工作負載的選擇。 例如，需要掃描整個數據庫的報告應用程序可能需要執行仔細的計費操作，以便掃描可能需要容錯，但可能不需要一個微微小的最新視圖 的數據庫。 在這種情況下，您可以選擇 **READ_AT_SNAPSHOT** ，并選擇掃描開始時過去幾秒的時間戳。 另一方面，不吸收整個數據集并且已經具有統計性質的機器學習工作負載可能不要求掃描是可重復的，因此您可以選擇 **READ_LATEST** 。
## Known Issues and Limitations ( 已知問題和限制?)
目前，在一些情況下，**Kudu** 已經完全嚴格序列化，存在幾個缺陷和角落。以下是詳細信息，接下來是一些建議。
### Reads (Scans) ( 閱讀（掃描）?)
* 對 **COMMIT_WAIT** 的支持是實驗性的，需要仔細調整時間同步協議，如 **NTP** （網絡時間協議）。在生產環境中不鼓勵使用它。
### Writes ( 寫入 )
* 在 **leader change** 中，**READ_AT_SNAPSHOT** 掃描時間戳超出最后一次寫入的快照，也可能會產生不可重復的讀取（參見 **[KUDU-1188](https://issues.apache.org/jira/browse/KUDU-1188)** ）。請參閱 有關解決方法的[建議](/pages/viewpage.action?pageId=10813638)。
* **Impala** 掃描當前以 **READ_LATEST** 的形式執行，并且沒有一致性保證。
* 在 **AUTO_BACKGROUND_FLUSH** 模式下，或者使用 “異步” 刷新機制時，應用于單個客戶端會話的寫入可能由于將數據刷新到服務器的并發而重新排序。如果用不同的值連續快速更新單個行，這可能會特別明顯。這種現象影響所有的客戶端 API 實現。解決方法在 API 文檔中介紹了 **FlushMode** 或 **AsyncKuduSession** 文檔中各自的實現。見** [KUDU-1767](https://issues.apache.org/jira/browse/KUDU-1767)** 。
### Recommendations ?( 建議 )
* 如果可重復的快照讀取是必需的，請使用 **READ_AT_SNAPSHOT** ，其時間戳稍微在過去（在 **2-5** 秒之間，理想情況下）。這將繞過 **Reads（Scans）** 中描述的異常。即使異常已被解決，回溯時間戳總是使掃描速度更快，因為它們不太可能被阻止。
* 如果需要外部一致性，并且您決定使用 **COMMIT_WAIT** ，則需要仔細調整時間同步協議。每個事務將在執行時等待 **2x** 最大時鐘錯誤，通常為 **100** 毫秒至 **1** 秒范圍與默認設置，也許更多。因此，交易將需要至少 **200** 毫秒至 **2** 秒使用默認設置完成甚至可能會超時。
*?本地服務器應該用作時間服務器。我們使用 Google Compute Engine 數據中心提供的默認 **NTP** 時間源進行實驗，并能夠獲得合理的最大誤差范圍，通常在 **12-17** 毫秒之間變化。
*?應在 **/etc/ntp.conf** 中調整以下參數以收緊最大錯誤：
* * * 服務器 my_server.org iburst minpoll 1 maxpoll 8
* tinker dispersion 500
* tinker allan 0
信息
上述參數以估計誤差為代價最小化最大誤差，后者可能高于 **“normal”** 值的數量級。這些參數也可能對時間服務器造成更大的負擔，因為它們使得服務器的輪詢頻率更高。
## References ( 參考 )
* [1] David Alves, Todd Lipcon and Vijay Garg. Technical Report: HybridTime - Accessible Global Consistency with High Clock Uncertainty. April, 2014.?[http://users.ece.utexas.edu/~garg/pdslab/david/hybrid-time-tech-report-01.pdf](http://users.ece.utexas.edu/~garg/pdslab/david/hybrid-time-tech-report-01.pdf)
* [2] James C. Corbett, Jeffrey Dean, Michael Epstein, Andrew Fikes, Christopher Frost, J. J. Furman, Sanjay Ghemawat, Andrey Gubarev, Christopher Heiser, Peter Hochschild, Wilson Hsieh, Sebastian Kanthak, Eugene Kogan, Hongyi Li, Alexander Lloyd, Sergey Melnik, David Mwaura, David Nagle, Sean Quinlan, Rajesh Rao, Lindsay Rolig, Yasushi Saito, Michal Szymaniak, Christopher Taylor, Ruth Wang, and Dale Woodford. 2012\. Spanner: Google’s globally-distributed database. In Proceedings of the 10th USENIX conference on Operating Systems Design and Implementation (OSDI'12). USENIX Association, Berkeley, CA, USA, 251-264.
* [3] Alexander Thomson, Thaddeus Diamond, Shu-Chun Weng, Kun Ren, Philip Shao, and Daniel J. Abadi. 2012\. Calvin: fast distributed transactions for partitioned database systems. In Proceedings of the 2012 ACM SIGMOD International Conference on Management of Data (SIGMOD '12). ACM, New York, NY, USA, 1-12\. DOI=10.1145/2213836.2213838?[http://doi.acm.org/10.1145/2213836.2213838](http://doi.acm.org/10.1145/2213836.2213838)
* [4] Diego Ongaro and John Ousterhout. 2014\. In search of an understandable consensus algorithm. In Proceedings of the 2014 USENIX conference on USENIX Annual Technical Conference (USENIX ATC'14), Garth Gibson and Nickolai Zeldovich (Eds.). USENIX Association, Berkeley, CA, USA, 305-320.
* [5] Kwei-Jay Lin, "Consistency issues in real-time database systems," in System Sciences, 1989\. Vol.II: Software Track, Proceedings of the Twenty-Second Annual Hawaii International Conference on , vol.2, no., pp.654-661 vol.2, 3-6 Jan 1989 doi: 10.1109/HICSS.1989.48069
