Building and Developing Apache HBase · HBase? 中文參考指南 3.0

# 構建和開發 Apache HBase 本章包含有關構建和發布 HBase 代碼和文檔的信息和指南。熟悉這些指南將有助于 HBase 提交者更輕松地使用您的貢獻。 ## 164.參與進來只有當人們貢獻時，Apache HBase 才會變得更好！如果您希望為 Apache HBase 做出貢獻，請在 JIRA 中查找標有'beginner'％20AND％20status％20in％20 標簽的[問題（開放％2C％20％22In％20Progress％22％2C ％20Reopened））。這些是 HBase 貢獻者認為值得的問題，但不是當下的優先事項，也是延長 HBase 內部的好方法。請參閱](https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner)[對于新貢獻者的斜坡問題，使用什么標簽？](http://search-hadoop.com/m/DHED43re96) 來自 dev 郵件列表的背景信息。在開始向 HBase 提交代碼之前，請參考[開發](#developing)。由于 Apache HBase 是 Apache Software Foundation 項目，請參閱 [asf](#asf) 以獲取有關 ASF 如何運行的更多信息。 ### 164.1。郵件列表注冊 dev-list 和用戶列表。請參閱[郵件列表](https://hbase.apache.org/mail-lists.html)頁面。鼓勵提出問題 - 并幫助回答其他人的問題！兩個列表都有不同程度的經驗，因此鼓勵耐心和禮貌（請留待主題。） ### 164.2。松弛 Apache HBase 項目有自己的鏈接： [Slack Channel](http://apache-hbase.slack.com) ，用于實時問題和討論。郵寄 [dev@hbase.apache.org](mailto:dev@hbase.apache.org) 請求邀請。 ### 164.3。互聯網中繼聊天（IRC）（注意：我們的 IRC 頻道似乎已被棄用，以支持上述 Slack 頻道）對于實時問題和討論，請使用 [FreeNode](https://freenode.net/) IRC 網絡上的`#hbase` IRC 頻道。 FreeNode 提供基于 Web 的客戶端，但大多數人更喜歡本機客戶端，并且每個操作系統都有幾個客戶端。 ### 164.4。吉拉檢查 [Jira](https://issues.apache.org/jira/projects/HBASE/issues) 中的現有問題。如果是新功能請求，增強功能或錯誤，請提交故障單。我們在 JIRA 中跟蹤多種類型的工作： * 錯誤：HBase 本身就有問題。 * 測試：需要進行測試，或者測試被破壞。 * 新功能：您對新功能有所了解。通常最好首先將它們放在郵件列表上，然后編寫一個設計規范，添加到功能請求 JIRA 中。 * 改進：存在一個功能，但可以進行調整或擴充。通常最好先將它們放在郵件列表上并進行討論，然后總結或鏈接到討論，如果其他人似乎對改進感興趣。 * 希望：這就像一個新功能，但對于某些你可能沒有背景來充實自己的東西。錯誤和測試具有最高優先級，應該是可操作的。 #### 164.4.1。報告有效問題的指南 * **搜索重復項**：您的問題可能已被報告過。看一看，意識到其他人可能會以不同的方式描述摘要。還可以搜索郵件列表，其中可能包含有關您的問題以及如何解決問題的信息。不要為已經在郵件列表中討論和解決的問題提出問題，除非您強烈反對決議**并且**愿意幫助解決問題。 * **公開討論**：使用郵件列表討論您發現的內容，看看是否有遺漏的內容。避免使用反向渠道，以便您從整個項目的經驗和專業知識中受益。 * **不要代表他人提交**：你可能沒有所有的上下文，而且你沒有那么多的動機來把它看成是實際遇到這個 bug 的人。從長遠來看，鼓勵他人提出自己的問題會更有幫助。指出這些材料并提供第一次或第二次幫助。 * **寫一個很好的總結**：一個很好的總結包括有關問題的信息，對用戶或開發人員的影響以及代碼的區域。 * 好：`Address new license dependencies from hadoop3-alpha4` * 改進空間：`Canary is broken` 如果你寫了一個糟糕的標題，別人會為你重寫它。這是他們本可以花時間處理這個問題的時候了。 * **在描述**中給出上下文：在多個部分中考慮這個可能是好的： * 會發生什么或不會發生什么？ * 它對你有何影響？ * 別人怎么能重現它？ * 什么會“固定”的樣子？您不需要知道所有這些的答案，但盡可能多地提供信息。如果您可以提供技術信息，例如您認為可能導致問題的 Git 提交 SHA，或者您認為問題首次出現在 builds.apache.org 上的構建失敗，請分享該信息。 * **填寫所有相關字段**：這些字段可幫助我們過濾，分類和查找內容。 * **一個錯誤，一個問題，一個補丁**：為了幫助反向移植，不要在多個錯誤之間拆分問題或修復。 * **如果可以**增加價值：即使您不知道如何解決問題，提交問題仍然很好。但是提供盡可能多的信息，愿意分類和回答問題，并愿意測試潛在的修復程序甚至更好！我們希望盡快修復您的問題。 * **如果我們不解決它，請不要沮喪**：時間和資源是有限的。在某些情況下，我們可能無法（或可能選擇不）修復問題，特別是如果它是邊緣情況或有解決方法。即使它沒有得到修復，JIRA 也是它的公開記錄，并且如果它們將來遇到類似的問題，將幫助其他人。 #### 164.4.2。處理一個問題要檢查您作為初學者可以解決的現有問題，請在 JIRA 中搜索標有“初學者”％20AND％20status％20in％20 標簽的[問題（開放％2C％20％22In％20Progress％ 22％2C％20Reopened））。](https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner) JIRA 優先事項 * **Blocker** ：僅在問題可能導致數據丟失或群集不穩定時使用。 * **嚴重**：在某些情況下，所描述的問題可能導致數據丟失或群集不穩定。 * **主要**：重要但不是悲劇性的問題，例如客戶端 API 的更新，它將添加許多急需的功能或需要修復但不會導致數據丟失的重大錯誤。 * **次要**：有用的增強功能和煩人但不會破壞性的錯誤。 * **瑣碎**：有用的增強功能，但通常是化妝品。示例 41\. Jira 評論中的代碼塊 Jira 中常用的宏是{code}。標簽內的所有內容都已預先格式化，如本例所示。 ``` {code} code snippet {code} ``` ## 165\. Apache HBase 存儲庫 Apache HBase 由多個存儲庫組成，這些存儲庫托管在 [Apache GitBox](https://gitbox.apache.org/) 上。這些是以下內容： * [hbase](https://gitbox.apache.org/repos/asf?p=hbase.git) - 主要的 Apache HBase 存儲庫 * [hbase-connectors](https://gitbox.apache.org/repos/asf?p=hbase-connectors.git) - Apache Kafka 和 Apache Spark 的連接器 * [hbase-operator-tools](https://gitbox.apache.org/repos/asf?p=hbase-operator-tools.git) - 可操作性和可支持性工具，如 [HBase `HBCK2`](#HBCK2) * [hbase-site](https://gitbox.apache.org/repos/asf?p=hbase-site.git) - hbase.apache.org 網站 * [hbase-thirdparty](https://gitbox.apache.org/repos/asf?p=hbase-thirdparty.git) - 流行的第三方庫的重新定位版本 ## 166\. IDE ### 166.1。日食 #### 166.1.1。代碼格式在 _dev-support /_ 文件夾下，您將找到 _hbase_eclipse _formatter.xml_ 。我們鼓勵您在編輯 HBase 代碼時在 eclipse 中使用此格式化程序。轉到`Preferences→Java→Code Style→Formatter→Import`加載 xml 文件。轉到`Preferences→Java→Editor→Save Actions`，確保選中“格式化源代碼”和“格式化編輯行”。除自動格式化外，請確保遵循 [common.patch.feedback](#common.patch.feedback) 中說明的樣式指南。 #### 166.1.2。 Eclipse Git 插件如果您通過 git 克隆項目，請下載并安裝 Git 插件（EGit）。附加到您當地的 git 倉庫（通過 Git Repositories 窗口），您將能夠看到文件修訂歷史記錄，生成補丁等。 #### 166.1.3。使用`m2eclipse`在 Eclipse 中進行 HBase 項目設置最簡單的方法是使用 Eclipse 的 m2eclipse 插件。 Eclipse Indigo 或更新版本包括 m2eclipse，或者您可以從 [http://www.eclipse.org/m2e/](http://www.eclipse.org/m2e/) 下載它。它為 Eclipse 提供了 Maven 集成，甚至允許您使用 Eclipse 中的直接 Maven 命令來編譯和測試您的項目。要導入項目，請單擊并選擇 HBase 根目錄。 `m2eclipse`為您找到所有 hbase 模塊。如果在工作區中安裝 m2eclipse 并導入 HBase，請執行以下操作來修復 eclipse Build Path。 1. 刪除 _ 目標 _ 文件夾 2. 添加 _target / generated-jamon_ 和 _target / generated-sources / java_ 文件夾。 3. 從構建路徑中刪除 _src / main / resources_ 和 _src / test / resources_ 上的排除項，以避免在控制臺中出現錯誤消息，如下所示： ``` Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.6:run (default) on project hbase: 'An Ant BuildException has occurred: Replace: source file .../target/classes/hbase-default.xml doesn't exist ``` 這也將減少日食構建周期，并使您在開發時更輕松。 #### 166.1.4。使用命令行在 Eclipse 中進行 HBase 項目設置您可以從命令行生成 Eclipse 文件，而不是使用`m2eclipse`。 1. 首先，運行以下命令，構建 HBase。你只需要這樣做一次。 ``` mvn clean install -DskipTests ``` 2. 關閉 Eclipse，并在終端的本地 HBase 項目目錄中執行以下命令，以生成新的 _.project_ 和 _.classpath_ 文件。 ``` mvn eclipse:eclipse ``` 3. 重新打開 Eclipse 并將 HBase 目錄中的 _.project_ 文件導入工作區。 #### 166.1.5。 Maven 類路徑變量需要為項目設置`$M2_REPO`類路徑變量。這需要設置為您的本地 Maven 存儲庫，通常是 _?/ .m2 / repository_ 如果未配置此類路徑變量，您將在 Eclipse 中看到如下編譯錯誤： ``` Description Resource Path Location Type The project cannot be built until build path errors are resolved hbase Unknown Java Problem Unbound classpath variable: 'M2_REPO/asm/asm/3.1/asm-3.1.jar' in project 'hbase' hbase Build path Build Path Problem Unbound classpath variable: 'M2_REPO/com/google/guava/guava/r09/guava-r09.jar' in project 'hbase' hbase Build path Build Path Problem Unbound classpath variable: 'M2_REPO/com/google/protobuf/protobuf-java/2.3.0/protobuf-java-2.3.0.jar' in project 'hbase' hbase Build path Build Path Problem Unbound classpath variable: ``` #### 166.1.6。 Eclipse 已知問題 Eclipse 目前會抱怨 _Bytes.java_ 。無法關閉這些錯誤。 ``` Description Resource Path Location Type Access restriction: The method arrayBaseOffset(Class) from the type Unsafe is not accessible due to restriction on required library /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar Bytes.java /hbase/src/main/java/org/apache/hadoop/hbase/util line 1061 Java Problem Access restriction: The method arrayIndexScale(Class) from the type Unsafe is not accessible due to restriction on required library /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar Bytes.java /hbase/src/main/java/org/apache/hadoop/hbase/util line 1064 Java Problem Access restriction: The method getLong(Object, long) from the type Unsafe is not accessible due to restriction on required library /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar Bytes.java /hbase/src/main/java/org/apache/hadoop/hbase/util line 1111 Java Problem ``` #### 166.1.7。 Eclipse - 更多信息有關在 Windows 上設置 Eclipse for HBase 開發的其他信息，請參閱 [Michael Morello 關于該主題的博客](http://michaelmorello.blogspot.com/2011/09/hbase-subversion-eclipse-windows.html)。 ### 166.2。 IntelliJ IDEA 您可以設置 IntelliJ IDEA 以實現與 Eclipse 類似的功能。跟著這些步驟。 1. 選擇 2. 您無需選擇配置文件。確保選中所需的 Maven 項目，然后單擊 **Next** 。 3. 選擇 JDK 的位置。在 IntelliJ IDEA 中使用 HBase Formatter 使用 IntelliJ IDEA 的 Eclipse Code Formatter 插件，您可以導入 [eclipse.code.formatting](#eclipse.code.formatting) 中描述的 HBase 代碼格式化程序。 ### 166.3。其他 IDE 為其他 IDE 鏡像 [eclipse](#eclipse) 設置指令會很有用。如果您想提供幫助，請查看 [HBASE-11704](https://issues.apache.org/jira/browse/HBASE-11704) 。 ## 167.構建 Apache HBase ### 167.1。基本編譯 HBase 是使用 Maven 編譯的。您必須至少使用 Maven 3.0.4。要檢查 Maven 版本，請運行命令 mvn -version。 > JDK 版本要求 > > 從 HBase 1.0 開始，您必須使用 Java 7 或更高版本從源代碼構建。有關受支持的 JDK 版本的更完整信息，請參見 [java](#java) 。 #### 167.1.1。 Maven 構建命令所有命令都從本地 HBase 項目目錄執行。 ##### 包從其 java 源代碼編譯 HBase 的最簡單命令是使用`package`目標，該目標使用編譯的文件構建 JAR。 ``` mvn package -DskipTests ``` 或者，在編譯之前進行清理： ``` mvn clean package -DskipTests ``` 如上面在 [eclipse](#eclipse) 中所述設置 Eclipse，您也可以在 Eclipse 中使用 Build 命令。要創建完整的可安裝 HBase 包需要多做一些工作，請繼續閱讀。 ##### 編 `compile`目標不會使用編譯的文件創建 JAR。 ``` mvn compile ``` ``` mvn clean compile ``` ##### 安裝要在 _?/ .m2 /_ 目錄中安裝 JAR，請使用`install`目標。 ``` mvn install ``` ``` mvn clean install ``` ``` mvn clean install -DskipTests ``` #### 167.1.2。運行所有或單個單元測試請參閱 [hbase.unittests](#hbase.unittests) 中的 [hbase.unittests.cmds](#hbase.unittests.cmds) 部分 #### 167.1.3。建立各種 hadoop 版本。 HBase 支持針對 Apache Hadoop 版本構建：2.y 和 3.y（早期版本工件）。默認情況下，我們針對 Hadoop 2.x 進行構建。要針對 Hadoop 2.y 行中的特定版本進行構建，請設置為`-Dhadoop-two.version=2.6.3`。 ``` mvn -Dhadoop-two.version=2.6.3 ... ``` 要更改我們構建的 Hadoop 的主要版本行，請在調用 mvn 時添加 hadoop.profile 屬性： ``` mvn -Dhadoop.profile=3.0 ... ``` 以上內容將針對我們在 _pom.xml_ 中作為我們的'3.0'版本的任何顯式 hadoop 3.y 版本構建。測試可能不會全部通過，因此您可能需要通過`-DskipTests`，除非您傾向于修復失敗的測試。要選擇特定的 Hadoop 3.y 版本，您需要設置 hadoop-three.version 屬性，例如`-Dhadoop-three.version=3.0.0`。 #### 167.1.4。構建 Protobuf 您可能需要更改駐留在 _hbase-protocol_ 模塊或其他模塊中的 protobuf 定義。在 hbase-2.0.0 之前，protobuf 定義文件遍布所有 hbase 模塊，但現在所有與 protobuf 相關的文件必須駐留在 hbase 協議模塊中;我們正在嘗試包含我們的 protobuf 使用，以便我們可以自由地更改版本而不會破壞任何下游項目使用 protobuf。 protobuf 文件位于 _hbase-protocol / src / main / protobuf_ 中。要使更改生效，您需要重新生成類。 ``` mvn package -pl hbase-protocol -am ``` 類似地，內部使用的 protobuf 定義位于 _hbase-protocol-shaded_ 模塊中。 ``` mvn package -pl hbase-protocol-shaded -am ``` 通常，使用本機`protoc`二進制文件完成 protobuf 代碼生成。在我們的構建中，我們使用 maven 插件以方便使用;但是，插件可能無法為所有平臺檢索適當的二進制文件。如果您發現自己處于 protoc 失敗的平臺上，則必須從源代碼編譯 protoc，并獨立于我們的 maven 構建運行它。您可以通過在 maven 參數中指定`-Dprotoc.skip`來禁用內聯代碼生成，從而允許您的構建繼續進行。 > 如果您需要手動生成 protobuf 文件，則不應在后續 maven 調用中使用`clean`，因為這將刪除新生成的文件。有關更多詳細信息，請閱讀 _hbase-protocol / README.txt_ #### 167.1.5。建立節儉您可能需要更改駐留在 _hbase-thrift_ 模塊或其他模塊中的 thrift 定義。 thrift 文件位于 _hbase-thrift / src / main / resources_ 中。要使更改生效，您需要重新生成類。您可以使用 maven profile `compile-thrift`來執行此操作。 ``` mvn compile -Pcompile-thrift ``` 您可能還想使用以下命令為 thrift 二進制文件定義`thrift.path`： ``` mvn compile -Pcompile-thrift -Dthrift.path=/opt/local/bin/thrift ``` #### 167.1.6。建立一個 Tarball 您可以通過運行以下命令，在不通過[發布](#releasing)中描述的發布過程的情況下構建 tarball： ``` mvn -DskipTests clean install && mvn -DskipTests package assembly:single ``` 分發 tarball 構建在 _hbase-assembly / target / hbase- <version>-bin.tar.gz</version>_ 中。您可以通過在 maven 命令中安裝或部署之前使用程序集：單個目標來安裝或部署 tarball： ``` mvn -DskipTests package assembly:single install ``` ``` mvn -DskipTests package assembly:single deploy ``` #### 167.1.7。建立陷阱 ##### Maven Site 失敗如果看到`Unable to find resource 'VM_global_library.vm'`，請忽略它。這不是錯誤。雖然這是[官方丑陋](https://issues.apache.org/jira/browse/MSITE-286)。 ## 168.發布 Apache HBase > 建立針對 HBase 1。 > > HBase 1.x 需要 Java 7 才能構建。有關每個 HBase 版本的 Java 要求，請參閱 [java](#java) 。示例 42.示例 _?/ .m2 / settings.xml_ 文件發布到 maven 需要您簽署要上傳的工件。為了讓您為自己簽名，您可以在 _.m2_ 下的本地存儲庫中正確配置 _settings.xml_ ，如下所示。 ``` <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> <servers> <!- To publish a snapshot of some part of Maven --> <server> <id>apache.snapshots.https</id> <username>YOUR_APACHE_ID </username> <password>YOUR_APACHE_PASSWORD </password> </server>   <server> <id>apache.releases.https</id> <username>YOUR_APACHE_ID </username> <password>YOUR_APACHE_PASSWORD </password> </server> </servers> <profiles> <profile> <id>apache-release</id> <properties> <gpg.keyname>YOUR_KEYNAME</gpg.keyname>  <gpg.passphrase>YOUR_KEY_PASSWORD </gpg.passphrase> </properties> </profile> </profiles> </settings> ``` ### 168.1。發布候選人只有提交者可以發布 hbase 工件。在你開始之前確保您的環境設置正確。 Maven 和 Git 是下面使用的主要工具。您需要在本地 _?/ .m2_ maven 存儲庫中正確配置 _settings.xml_ 文件，其中包含 apache repos 的登錄信息（參見[示例 _?/ .m2 /settings.xml_ 文件](#maven.settings.xml)）。您還需要具有已發布的簽名密鑰。瀏覽 Hadoop [如何發布](http://wiki.apache.org/hadoop/HowToRelease) wiki 頁面，了解如何發布。它是下面大多數說明的模型。它通常包含有關特定步驟的更多詳細信息，例如，在 Apache 中將代碼簽名密鑰添加到項目 KEYS 文件中，或者如何更新 JIRA 以準備發布。在制作候選版本之前，請通過部署 SNAPSHOT 進行練習。檢查以確保最近的版本已經從您將要發布的分支傳遞到該分支。您還應該在加載的集群上嘗試最近的分支提示，可能是通過運行`hbase-it`集成測試套件幾個小時來“燒入”近候選位。 > 為 Maven 指定堆空間 > > 您可能會遇到 OutOfMemoryErrors 構建，特別是構建站點和文檔。通過設置`MAVEN_OPTS`變量為 Maven 堆起來。您可以將變量作為 Maven 命令的前綴，如下例所示： > > ``` > MAVEN_OPTS="-Xmx4g -XX:MaxPermSize=256m" mvn package > ``` > > 您也可以在 shell 中的環境變量或別名中設置它。 > > 腳本 _dev-support / make _rc.sh_ 自動執行以下許多步驟。它將檢出標簽，清理結帳，構建 src 和 bin tarball，并將構建的 jar 部署到 repository.apache.org。它沒有對發布的 _CHANGES.txt_ 進行修改，檢查生成的工件以確保它們“良好” - 例如提取生成的 tarball，驗證它們是否正確，然后啟動 HBase 并檢查一切是否正常運行 - 或者將 tarball 簽名并推送到 [people.apache.org](https://people.apache.org) 。看一看。根據需要修改/改進。程序：發布程序 1. 更新 _CHANGES.txt_ 文件和 POM 文件。使用自上次發布以來的更改更新 _CHANGES.txt_ 。確保 JIRA 的 URL 指向正確的位置，該位置列出了此版本的修復程序。適當調整所有 POM 文件中的版本。如果要創建候選發布版，則必須從所有 pom.xml 文件中的所有版本中刪除`-SNAPSHOT`標簽。如果您正在運行此 receipe 以發布快照，則必須在 hbase 版本上保留`-SNAPSHOT`后綴。 [版本 Maven 插件](http://www.mojohaus.org/versions-maven-plugin/)可以在這里使用。要在 hbase 多模塊項目的所有 poms 中設置版本，請使用如下命令： ``` $ mvn clean org.codehaus.mojo:versions-maven-plugin:2.5:set -DnewVersion=2.1.0-SNAPSHOT ``` 確保 poms 中的所有版本都已更改！檢查 _CHANGES.txt_ 并更改任何 maven 版本。 2. 更新文檔。更新 _src / main / asciidoc_ 下的文檔。這通常涉及從主分支復制最新版本并進行版本特定調整以適應此候選版本。 3. 清潔結帳目錄 ``` $ mvn clean $ git clean -f -x -d ``` 4. 運行 Apache-Rat Check 許可證很好 ``` $ mvn apache-rat ``` 如果上述操作失敗，請檢查鼠標日志。 ``` $ grep 'Rat check' patchprocess/mvn_apache_rat.log ``` 5. 創建發布標記。假設您已經運行了基本測試，鼠標檢查，通過并且一切看起來都很好，現在是標記候選發布者的時間（如果您需要重做，則總是刪除標記）。要標記，請在適合您的構建的版本中進行替換。所有標簽都應該是簽名標簽;即通過 _-s_ 選項（參見[簽署您的工作](http://https://git-scm.com/book/id/v2/Git-Tools-Signing-Your-Work)，了解如何設置您的 git 環境進行簽名）。 ``` $ git tag -s 2.0.0-alpha4-RC0 -m "Tagging the 2.0.0-alpha4 first Releae Candidate (Candidates start at zero)" ``` 或者，如果您要發布，標簽應該有一個 _rel /_ 前綴，以確保它們保存在 Apache repo 中，如下所示： ``` +$ git tag -s rel/2.0.0-alpha4 -m "Tagging the 2.0.0-alpha4 Release" ``` 推送（特定）標簽（僅限）以便其他人可以訪問。 + ``` $ git push origin 2.0.0-alpha4-RC0 ``` * 有關如何刪除標簽的信息，請參閱[如何刪除標簽](http://www.manikrathee.com/how-to-delete-a-tag-in-git.html)。涵蓋刪除尚未推送到遠程 Apache repo 的標簽以及刪除推送到 Apache 的標簽。 * 構建源代碼 tarball。現在，構建源代碼 tarball。讓我們假設我們正在為 _/tmp/hbase-2.0.0-alpha4-RC0/_ 標記 _2.0.0-alpha4-RC0_ 構建源碼 tarball（此步驟要求剛剛完成了上面描述的 mvn 和 git clean 步驟）。 ``` $ git archive --format=tar.gz --output="/tmp/hbase-2.0.0-alpha4-RC0/hbase-2.0.0-alpha4-src.tar.gz" --prefix="hbase-2.0.0-alpha4/" $git_tag ``` 上面我們將 hbase-2.0.0-alpha4-src.tar.gz tarball 生成到 _/tmp/hbase-2.0.0-alpha4-RC0_ 構建輸出目錄中（我們不想要 _] RC0_ 在名稱或前綴中。這些位當前是候選版本，但如果 VOTE 通過，它們將成為釋放，因此我們不會使用 _RCX_ 來污染工件名稱。 1. 構建二進制 tarball。接下來，構建二進制 tarball。在構建時添加`-Prelease`配置文件。它運行許可證 apache-rat 檢查以及其他有助于確保所有內容都有益的規則。分兩步完成。首先安裝到本地存儲庫 ``` $ mvn clean install -DskipTests -Prelease ``` 接下來，生成文檔并組裝 tarball。請注意，下一步可能需要一段時間，幾個小時生成站點文檔。 ``` $ mvn install -DskipTests site assembly:single -Prelease ``` * 否則，當您嘗試一步完成所有操作時，構建會抱怨 hbase 模塊不在 maven 存儲庫中，尤其是在新的存儲庫中。您似乎需要在兩個步驟中都需要安裝目標。 * 提取生成的 tarball - 你會在 _hbase-assembly / target_ 下找到它并檢查出來。查看文檔，查看它是否運行等。如果好，請復制構建輸出目錄中源 tarball 旁邊的 tarball。 * 部署到 Maven 資源庫。接下來，將 HBase 部署到 Apache Maven 存儲庫。添加 apache-release `profile when running the` mvn deploy`命令。此配置文件來自我們的 pom 文件引用的 Apache 父 pom。只要 _settings.xml_ 配置正確，它就會對發布到 Maven 的工件進行簽名，如[示例 _?/ .m2 / settings.xml_ 文件](#maven.settings.xml)。此步驟取決于已由前一個 bin tarball 構建填充的本地存儲庫。 ``` $ mvn deploy -DskipTests -Papache-release -Prelease ``` 此命令將所有工件復制到處于“打開”狀態的臨時暫存 Apache maven 存儲庫。需要對這些 maven 工件進行更多的工作，以使它們普遍可用。我們不會將 HBase tarball 發布到 Apache Maven 存儲庫。要避免部署 tarball，請不要在`mvn deploy`命令中包含`assembly:single`目標。檢查已部署的工件，如下一節中所述。 > make_rc.s > > 如果你運行 _dev-support / make _rc.sh_ 腳本，這就是你需要的。要完成發布，請從此處開始編寫腳本。 1. 使候選版本可用。工件位于“打開”狀態的暫存區域中的 maven 存儲庫中。在這種“開放”狀態下，您可以查看您發布的內容，以確保一切順利。為此，請使用您的 Apache ID 在 [repository.apache.org](https://repository.apache.org) 上登錄 Apache 的 Nexus。在臨時存儲庫中查找工件。單擊“Staging Repositories”并查找以“hbase”結尾的新狀態，狀態為“Open”，然后選擇它。使用樹視圖展開存儲庫內容列表，并檢查您期望的工件是否存在。檢查 POM。只要暫存存儲倉庫處于打開狀態，您就可以在缺少某些內容或構建錯誤時重新上傳。如果出現嚴重錯誤并且您想要撤消上傳，可以使用“刪除”按鈕刪除和刪除暫存存儲庫。有時上傳在中間失敗。這是您可能必須從暫存存儲庫中“刪除”上載的另一個原因。如果簽出，請使用“關閉”按鈕關閉倉庫。必須先關閉存儲庫，然后才能使用它的公共 URL。存儲庫可能需要幾分鐘才能關閉。完成后，您將在 Nexus UI 中看到存儲庫的公共 URL。您可能還會收到一封包含該 URL 的電子郵件。在宣布候選發布版的電子郵件中提供臨時登臺存儲庫的 URL。（人們需要將此 repo URL 添加到其本地 poms 或其本地 _settings.xml_ 文件中以提取已發布的候選工件。）當發布投票成功結束時，返回此處并單擊“發布”按鈕以將工件發布到中央。發布過程將自動刪除并刪除暫存存儲庫。 > HBase 的-downstreamer > > 請參閱 [hbase-downstreamer](https://github.com/saintstack/hbase-downstreamer) 測試，了解 HBase 下游的項目的簡單示例，具體取決于它。檢查并運行其簡單測試，以確保 maven 工件正確部署到 maven 存儲庫。請務必編輯 pom 以指向正確的臨時存儲庫。確保在測試運行時從存儲庫中提取并且未從本地存儲庫獲取，方法是傳遞`-U`標志或刪除本地存儲庫內容并檢查 maven 是否已從遠程存儲庫中移出。有關此 maven 登臺過程的一些指示，請參閱[發布 Maven 工件](https://www.apache.org/dev/publishing-maven-artifacts.html)。 * 如果 HBase 版本以`-SNAPSHOT`結尾，則工件將轉移到其他位置。它們直接放入 Apache 快照存儲庫并立即可用。發布 SNAPSHOT，這就是您想要發生的事情。 * 在此階段，您在“構建輸出目錄”中有兩個 tarball，并且在 maven 存儲庫的暫存區域中有一組工件處于“關閉”狀態。下一個簽名，指紋然后通過 svnpubsub“釋放”你的發布候選構建輸出目錄，將你的目錄提交到[開發分發目錄](https://dist.apache.org/repos/dist/dev/hbase/)（參見 [HBASE-10554 上的評論請從鏡像系統中刪除舊版本](https://issues.apache.org/jira/browse/HBASE-10554)但實質上它是 [dev / hbase](https://dist.apache.org/repos/dist/dev/hbase) 的 svn 結賬 - 發布在[發布/ hbase](https://dist.apache.org/repos/dist/release/hbase) ）。在 _ 版本目錄 _ 中運行以下命令： ``` $ for i in *.tar.gz; do echo $i; gpg --print-md MD5 $i > $i.md5 ; done $ for i in *.tar.gz; do echo $i; gpg --print-md SHA512 $i > $i.sha ; done $ for i in *.tar.gz; do echo $i; gpg --armor --output $i.asc --detach-sig $i ; done $ cd .. # Presuming our 'build output directory' is named 0.96.0RC0, copy it to the svn checkout of the dist dev dir # in this case named hbase.dist.dev.svn $ cd /Users/stack/checkouts/hbase.dist.dev.svn $ svn info Path: . Working Copy Root Path: /Users/stack/checkouts/hbase.dist.dev.svn URL: https://dist.apache.org/repos/dist/dev/hbase Repository Root: https://dist.apache.org/repos/dist Repository UUID: 0d268c88-bc11-4956-87df-91683dc98e59 Revision: 15087 Node Kind: directory Schedule: normal Last Changed Author: ndimiduk Last Changed Rev: 15045 Last Changed Date: 2016-08-28 11:13:36 -0700 (Sun, 28 Aug 2016) $ mv 0.96.0RC0 /Users/stack/checkouts/hbase.dist.dev.svn $ svn add 0.96.0RC0 $ svn commit ... ``` * 通過檢查 [https://dist.apache.org/repos/dist/dev/hbase/](https://dist.apache.org/repos/dist/dev/hbase/) 確保實際發布。宣布郵件列表中的候選發布者并進行投票。 ### 168.2。將 SNAPSHOT 發布到 maven 確保您的 _settings.xml_ 設置正確（參見[示例 _?/ .m2 / settings.xml_ 文件](#maven.settings.xml)）。確保 hbase 版本包含`-SNAPSHOT`作為后綴。以下是發布其 poms 中 hbase 版本為 0.96.0 的發行版的 SNAPSHOTS 的示例。 ``` $ mvn clean install -DskipTests javadoc:aggregate site assembly:single -Prelease $ mvn -DskipTests deploy -Papache-release ``` 上面提到的 _make _rc.sh_ 腳本（參見 [maven.release](#maven.release) ）可以幫助您發布`SNAPSHOTS`。在運行腳本之前，請確保`hbase.version`后綴為`-SNAPSHOT`。它會將快照放入 apache 快照存儲庫中。 ## 169.對候選人進行投票鼓勵每個人嘗試對 HBase 候選人進行投票。只有 PMC 成員的投票具有約束力。 PMC 成員，請閱讀關于候選發布候選人[發布政策](https://github.com/rectang/asfrelease/blob/master/release.md)的政策投票的 WIP 文檔。 [quote] _ 在投出 1 個綁定票之前，個人需要將簽名的源代碼包下載到他們自己的硬件上，按照提供的方式編譯，并在自己的平臺上測試生成的可執行文件，同時驗證加密簽名和驗證該程序包符合 ASF 關于發布的策略的要求。_ 關注后者，運行+ mvn apache-rat：檢查以驗證所有文件是否獲得適當許可。參見 [HBase，mail＃dev - 最近討論澄清 ASF 發布政策](http://search-hadoop.com/m/DHED4dhFaU)。我們是如何到達這個過程的。 ## 170.宣布發布一旦 RC 成功通過并且所需的工件已經上演分配，您需要讓每個人都知道我們閃亮的新版本。這不是一項要求，但為了讓發布經理們更輕松，我們可以為您提供一個模板。請務必使用相關版本號替換 _ 版本 _ 和其他標記。您應該在發送之前手動驗證所有鏈接。 ``` The HBase team is happy to announce the immediate availability of HBase _version_. Apache HBase? is an open-source, distributed, versioned, non-relational database. Apache HBase gives you low latency random access to billions of rows with millions of columns atop non-specialized hardware. To learn more about HBase, see https://hbase.apache.org/. HBase _version_ is the _nth_ minor release in the HBase _major_.x line, which aims to improve the stability and reliability of HBase. This release includes roughly XXX resolved issues not covered by previous _major_.x releases. Notable new features include: - List text descriptions of features that fit on one line - Including if JDK or Hadoop support versions changes - If the "stable" pointer changes, call that out - For those with obvious JIRA IDs, include them (HBASE-YYYYY) The full list of issues can be found in the included CHANGES.md and RELEASENOTES.md, or via our issue tracker: https://s.apache.org/hbase-_version_-jira To download please follow the links and instructions on our website: https://hbase.apache.org/downloads.html Question, comments, and problems are always welcome at: dev@hbase.apache.org. Thanks to all who contributed and made this release possible. Cheers, The HBase Dev Team ``` 您應將此消息發送到以下列表： [dev@hbase.apache.org](mailto:dev@hbase.apache.org) ， [user@hbase.apache.org](mailto:user@hbase.apache.org) ， [announce@apache.org](mailto:announce@apache.org) 。如果您想在發送之前進行抽查，請隨時通過 jira 或開發者列表詢問。 ## 171.生成 HBase 參考指南該手冊使用 Asciidoc 進行了標記。然后我們使用 [Asciidoctor maven 插件](http://asciidoctor.org/docs/asciidoctor-maven-plugin/)將標記轉換為 html。當您在運行 mvn site 時指定站點目標時，將運行此插件。有關構建文檔的更多信息，請參閱文檔的[附錄。](#appendix_contributing_to_documentation) ## 172.更新 [hbase.apache.org](https://hbase.apache.org) ### 172.1。貢獻給 hbase.apache.org 有關對文檔或網站做出貢獻的更多信息，請參閱文檔的[附錄。](#appendix_contributing_to_documentation) ### 172.2。發布 [hbase.apache.org](https://hbase.apache.org) 有關發布網站和文檔的說明，請參閱[發布 HBase 網站和文檔](#website_publish)。 ## 173.測試開發人員至少應該熟悉單元測試細節; HBase 中的單元測試具有其他項目中通常不會出現的特征。此信息是關于 HBase 本身的單元測試。有關為 HBase 應用程序開發單元測試的信息，請參閱 [unit.tests](#unit.tests) 。 ### 173.1。 Apache HBase 模塊截至 0.96，Apache HBase 分為多個模塊。這為編寫測試的方式和位置創建了“有趣的”規則。如果您正在為`hbase-server`編寫代碼，請參閱 [hbase.unittests](#hbase.unittests) 以了解如何編寫測試。這些測試可以啟動 minicluster 并需要進行分類。對于任何其他模塊，例如`hbase-common`，測試必須是嚴格的單元測試，并且只測試被測試的類 - 不允許使用 HBaseTestingUtility 或 minicluster（或者甚至可以給定依賴樹）。 #### 173.1.1。測試 HBase Shell HBase shell 及其測試主要用 jruby 編寫。為了使這些測試作為標準構建的一部分運行，有一些 JUnit 測試類負責加載 jruby 實現的測試并運行它們。測試分為不同的類，以適應類級超時（詳見[單元測試](#hbase.unittests)）。您可以從頂層運行所有這些測試： ``` mvn clean test -Dtest=Test*Shell ``` 如果您之前已經完成了`mvn install`，那么您可以指示 maven 僅運行 hbase-shell 模塊中的測試： ``` mvn clean test -pl hbase-shell ``` 或者，您可以限制使用系統變量`shell.test`運行的 shell 測試。此值應按名稱指定特定測試用例的 ruby 文字等效項。例如，覆蓋用于更改表的 shell 命令的測試包含在測試用例`AdminAlterTableTest`中，您可以使用以下命令運行它們： ``` mvn clean test -pl hbase-shell -Dshell.test=/AdminAlterTableTest/ ``` 您還可以使用 [Ruby Regular Expression 文字](http://docs.ruby-doc.com/docs/ProgrammingRuby/html/language.html#UJ)（`/pattern/`樣式）來選擇一組測試用例。您可以使用以下命令運行所有與 HBase 管理相關的測試，包括正常管理和安全管理： ``` mvn clean test -pl hbase-shell -Dshell.test=/.*Admin.*Test/ ``` 如果測試失敗，您可以通過檢查 surefire 報告結果的 XML 版本來查看詳細信息 ``` vim hbase-shell/target/surefire-reports/TEST-org.apache.hadoop.hbase.client.TestShell.xml ``` #### 173.1.2。在其他模塊中運行測試如果您正在開發的模塊沒有其他 HBase 模塊的其他依賴項，那么您可以進入該模塊并運行： ``` mvn test ``` 這將只運行模塊中的測試。如果其他模塊存在其他依賴關系，那么您將從 ROOT HBASE DIRECTORY 運行該命令。這將在其他模塊中運行測試，除非您指定跳過該模塊中的測試。例如，要跳過 hbase-server 模塊中的測試，您將運行： ``` mvn clean test -PskipServerTests ``` 從頂級目錄運行除 hbase-server 之外的模塊中的所有測試。請注意，您可以指定跳過多個模塊中的測試以及單個模塊的測試。例如，要跳過`hbase-server`和`hbase-common`中的測試，您將運行： ``` mvn clean test -PskipServerTests -PskipCommonTests ``` 另外，請記住，如果在`hbase-server`模塊中運行測試，則需要應用 [hbase.unittests.cmds](#hbase.unittests.cmds) 中討論的 maven 配置文件，以使測試正常運行。 ### 173.2。單元測試 Apache HBase 單元測試必須帶有類別注釋，從`hbase-2.0.0`開始，必須加上 HBase `ClassRule`。以下是包含 Category 和 ClassRule 的 Test Class 的示例： ``` ... @Category(SmallTests.class) public class TestHRegionInfo { @ClassRule public static final HBaseClassTestRule CLASS_RULE = HBaseClassTestRule.forClass(TestHRegionInfo.class); @Test public void testCreateHRegionInfoName() throws Exception { // ... } } ``` 這里的測試類是`TestHRegionInfo`。 `CLASS_RULE`在每個測試類中具有相同的形式，只有你傳遞的`.class`是本地測試的形式;即在 TestTimeout 測試類中，你將`TestTimeout.class`傳遞給`CLASS_RULE`而不是我們上面的`TestHRegionInfo.class`。 `CLASS_RULE`是我們強制執行超時的（目前設置為所有測試的硬限制為 13 分鐘 - 780 秒）和其他跨單元測試設施。測試在`SmallTest`類別中。類別可以是任意的，并作為列表提供，但每個測試必須攜帶以下列表中的一個：`small`，`medium`，`large`和`integration`。使用 JUnit [類別](https://github.com/junit-team/junit4/wiki/Categories)：`SmallTests`，`MediumTests`，`LargeTests`，`IntegrationTests`指定測試大小。 JUnit 類別使用 java 注釋表示（特殊單元測試在所有單元 tess 中查找@Category 注釋的存在，如果發現測試套件缺少大小標記，則會失敗）。前三個類別`small`，`medium`和`large`用于鍵入`$ mvn test`時運行的測試用例。換句話說，這三個分類用于 HBase 單元測試。 `integration`類別不是用于單元測試，而是用于集成測試。這些通常在您調用`$ mvn verify`時運行。集成測試在 [integration.tests](#integration.tests) 中描述。繼續閱讀以確定新的 HBase 測試用例上的集合`small`，`medium`和`large`的注釋。分類測試小測試 _ 小型 _ 測試用例在共享 JVM 中執行，每個測試套件/測試類應在 15 秒或更短時間內運行;即一個 [junit 測試夾具](https://en.wikipedia.org/wiki/JUnit)，一個由測試方法組成的 java 對象，應該在 15 秒內完成，無論它有多少或幾乎沒有測試方法。這些測試用例不應使用 minicluster。中等測試 _ 中 _ 測試用例在單獨的 JVM 和單獨的測試套件或測試類中執行，或者以 junit 的說法執行，[測試夾具](https://en.wikipedia.org/wiki/JUnit)應該在 50 秒或更短的時間內運行。這些測試用例可以使用迷你集群。大型測試 _ 大型 _ 測試案例就是其他一切。它們通常是大規模測試，特定錯誤的回歸測試，超時測試或性能測試。沒有大型測試套件可能需要超過十分鐘。隨著時間的推移會被殺死。如果需要運行更長時間，請將測試作為集成測試。集成測試 _ 集成 _ 測試是系統級測試。有關詳細信息，請參閱 [integration.tests](#integration.tests) 。如果在集成測試中調用`$ mvn test`，則測試沒有超時。 ### 173.3。運行測試 #### 173.3.1。默認值：中小類別測試運行`mvn test`將在單個 JVM（無分支）中執行所有小測試，然后在單獨的 JVM 中為每個測試實例執行中等測試。如果小測試中存在錯誤，則不執行中等測試。不執行大型測試。 #### 173.3.2。運行所有測試運行`mvn test -P runAllTests`將在單個 JVM 中執行小型測試，然后在單獨的 JVM 中為每個測試執行中型和大型測試。如果小測試中存在錯誤，則不執行中型和大型測試。 #### 173.3.3。在包中運行單個測試或所有測試要進行單獨測試，例如`MyTest`，朗姆酒`mvn test -Dtest=MyTest`您還可以將多個單獨的測試作為逗號分隔列表傳遞： ``` mvn test -Dtest=MyTest1,MyTest2,MyTest3 ``` 您還可以傳遞一個包，它將運行包下的所有測試： ``` mvn test '-Dtest=org.apache.hadoop.hbase.client.*' ``` 指定`-Dtest`時，將使用`localTests`配置文件。每個 junit 測試都在一個單獨的 JVM（每個測試類的一個 fork）中執行。在此模式下運行測試時沒有并行化。您將在-report 的末尾看到一條新消息：`"[INFO] Tests are skipped"`。這是無害的。但是，您需要確保測試報告的`Results:`部分中`Tests run:`的總和與您指定的測試數相匹配，因為在指定不存在的測試用例時不會報告錯誤。 #### 173.3.4。其他測試調用排列運行`mvn test -P runSmallTests`將僅使用單個 JVM 執行“小”測試。運行`mvn test -P runMediumTests`將僅執行“中”測試，為每個測試類啟動一個新的 JVM。運行`mvn test -P runLargeTests`將僅執行“大型”測試，為每個測試類啟動一個新的 JVM。為方便起見，您可以使用單個 JVM 運行`mvn test -P runDevTests`來執行小型和中型測試。 #### 173.3.5。更快地運行測試默認情況下，`$ mvn test -P runAllTests`并行運行 5 個測試。它可以在開發人員的機器上增加。允許每個核心可以并行進行 2 次測試，每次測試需要大約 2GB 內存（在極端情況下），如果你有 8 核 24GB 盒子，你可以并行進行 16 次測試。但可用內存將其限制為 12（24/2），要并行執行 12 次測試的所有測試，請執行以下操作：mvn test -P runAllTests -Dsurefire.secondPartForkCount = 12。如果使用早于 2.0 的版本，請執行：+ mvn test -P runAllTests -Dsurefire.secondPartThreadCount = 12 +。要提高速度，您也可以使用 ramdisk。您將需要 2GB 的內存來運行所有測試。您還需要在兩次測試運行之間刪除文件。在 Linux 上配置 ramdisk 的典型方法是： ``` $ sudo mkdir /ram2G sudo mount -t tmpfs -o size=2048M tmpfs /ram2G ``` 然后，您可以使用以下命令在 2.0 上運行所有 HBase 測試： ``` mvn test -P runAllTests -Dsurefire.secondPartForkCount=12 -Dtest.build.data.basedirectory=/ram2G ``` 在早期版本中，使用： ``` mvn test -P runAllTests -Dsurefire.secondPartThreadCount=12 -Dtest.build.data.basedirectory=/ram2G ``` #### 173.3.6。 hbasetests.sh 也可以使用腳本 hbasetests.sh。此腳本與兩個 maven 實例并行運行中型和大型測試，并提供單個報告。此腳本不使用 surefire 的 hbase 版本，因此除了腳本設置的兩個 maven 實例之外，不會進行任何并行化。它必須從包含 _pom.xml_ 的目錄執行。例如，運行./dev-support/hbasetests.sh 將執行中小型測試。運行./dev-support/hbasetests.sh runAllTests 將執行所有測試。運行./dev-support/hbasetests.sh replayFailed 將在單獨的 jvm 中重新運行失敗的測試，并且沒有并行化。 #### 173.3.7。測試超時不嚴格執行 HBase 單元測試大小分類超時。任何運行時間超過十分鐘的測試都將超時/終止。從 hbase-2.0.0 開始，我們已經清除了所有的每個測試方法超時：即 ``` ... @Test(timeout=30000) public void testCreateHRegionInfoName() throws Exception { // ... } ``` 考慮到我們是整個測試夾具/類/套件需要多長時間的基礎，并且測試方法所需的時間差異在很大程度上取決于上下文（加載的 Apache 基礎設施與開發人員機器），因此他們不鼓勵并且沒有多大意義沒有別的東西在上面運行）。 #### 173.3.8。測試資源檢查器自定義 Maven SureFire 插件監聽器在每個 HBase 單元測試運行之前和之后檢查許多資源，并在測試輸出文件的末尾記錄其結果，這些文件可以在每個 Maven 模塊的 _target / surefire-reports_ 中找到（測試將為測試類命名的測試報告寫入此目錄。檢查 _* -out.txt_ 文件）。計算的資源是線程數，文件描述符數等。如果數量增加，它會增加 _LEAK？_ 在日志中發表評論。由于您可以在后臺運行 HBase 實例，因此可以刪除/創建一些線程，而無需在測試中執行任何特定操作。但是，如果測試不能按預期工作，或者測試不會影響這些資源，則值得檢查這些日志行... hbase.ResourceChecker（157）：before ...和... hbase.ResourceChecker（157 ）：之后....例如： ``` 2012-09-26 09:22:15,315 INFO [pool-1-thread-1] hbase.ResourceChecker(157): after: regionserver.TestColumnSeeking#testReseeking Thread=65 (was 65), OpenFileDescriptor=107 (was 107), MaxFileDescriptor=10240 (was 10240), ConnectionCount=1 (was 1) ``` ### 173.4。寫測試 #### 173.4.1。通用規則 * 盡可能將測試編寫為類別小測試。 * 必須編寫所有測試以支持在同一臺機器上并行執行，因此它們不應將共享資源用作固定端口或固定文件名。 * 測試不應該過度。超過 100 行/秒使得日志復雜化以便讀取和使用 i / o，因此不能用于其他測試。 * 可以使用`HBaseTestingUtility`編寫測試。此類提供輔助函數來創建臨時目錄并執行清理或啟動集群。 #### 173.4.2。類別和執行時間 * 必須對所有測試進行分類，否則可以跳過它們。 * 所有測試都應盡可能快地編寫。 * 見＆lt; <hbase.unittests>用于測試用例類別和相應的超時。這應確保使用它的人員具有良好的并行性，并在測試失敗時簡化分析。</hbase.unittests> #### 173.4.3。在測試中睡覺只要有可能，測試不應該使用 Thread.sleep，而是等待他們需要的真實事件。這對讀者來說更快更清晰。測試不應該在沒有測試結束條件的情況下執行 Thread.sleep。這樣可以了解測試正在等待的內容。而且，無論機器性能如何，測試都能正常工作。睡眠應該盡可能快。等待變量應該在 40ms 的睡眠循環中完成。等待套接字操作應該在 200 毫秒的睡眠循環中完成。 #### 173.4.4。使用群集進行測試使用 HRegion 進行的測試不必啟動集群：區域可以使用本地文件系統。啟動/停止群集成本大約 10 秒。它們不應該按照測試方法而是按測試類啟動。必須使用 HBaseTestingUtility＃shutdownMiniCluster 關閉已啟動的集群，該程序清除目錄。盡可能多地，測試應使用群集的默認設置。如果他們不這樣做，他們應該記錄下來。這將允許稍后共享群集。 #### 173.4.5。測試骨架代碼這是一個帶有分類和基于類別的超時規則的測試框架代碼，用于復制和粘貼并用作測試貢獻的基礎。 ``` /** * Describe what this testcase tests. Talk about resources initialized in @BeforeClass (before * any test is run) and before each test is run, etc. */ // Specify the category as explained in <<hbase.unittests,hbase.unittests>>. @Category(SmallTests.class) public class TestExample { // Replace the TestExample.class in the below with the name of your test fixture class. private static final Log LOG = LogFactory.getLog(TestExample.class); // Handy test rule that allows you subsequently get the name of the current method. See // down in 'testExampleFoo()' where we use it to log current test's name. @Rule public TestName testName = new TestName(); // The below rule does two things. It decides the timeout based on the category // (small/medium/large) of the testcase. This @Rule requires that the full testcase runs // within this timeout irrespective of individual test methods' times. The second // feature is we'll dump in the log when the test is done a count of threads still // running. @Rule public static TestRule timeout = CategoryBasedTimeout.builder(). withTimeout(this.getClass()).withLookingForStuckThread(true).build(); @Before public void setUp() throws Exception { } @After public void tearDown() throws Exception { } @Test public void testExampleFoo() { LOG.info("Running test " + testName.getMethodName()); } } ``` ### 173.5。集成測試 HBase 集成/系統測試是超出 HBase 單元測試的測試。它們通常是持久的，相當大的（測試可以被要求為 1M 行或 1B 行），可以定位（它們可以采取配置，將它們指向它們要運行的現成集群;集成測試不包括集群啟動/停止代碼），并驗證成功，集成測試僅依賴于公共 API;他們不會嘗試檢查服務器內部斷言成功/失敗。當您需要對單元測試可以執行的發布候選項進行更詳細的校對時，您將運行集成測試。它們通常不在 Apache Continuous Integration 構建服務器上運行，但是，一些站點選擇運行集成測試作為其在實際集群上進行連續測試的一部分。集成測試目前位于 hbase-it 子模塊中的 _src / test_ 目錄下，并且將匹配正則表達式： _*** / IntegrationTest** .java_ 。所有集成測試也使用`@Category(IntegrationTests.class)`進行注釋。集成測試可以以兩種模式運行：使用迷你集群，或針對實際的分布式集群。 Maven failsafe 用于使用迷你集群運行測試。 IntegrationTestsDriver 類用于對分布式集群執行測試。集成測試不應該假設它們是針對迷你集群運行的，并且不應該使用私有 API 來訪問集群狀態。要統一地與分布式或迷你集群交互，可以使用`IntegrationTestingUtility`和`HBaseCluster`類以及公共客戶端 API。在分布式群集上，使用 ChaosMonkey 的集成測試或通過集群管理器（例如，重新啟動區域服務器）操縱服務的集成測試使用 SSH 來執行此操作。要運行這些，測試進程應該能夠在遠程端運行命令，因此應該相應地配置 ssh（例如，如果 HBase 在集群中的 hbase 用戶下運行，則可以為該用戶設置無密碼 ssh 并運行測試在它下面）。為此，可以使用`hbase.it.clustermanager.ssh.user`，`hbase.it.clustermanager.ssh.opts`和`hbase.it.clustermanager.ssh.cmd`配置設置。 “User”是集群管理器用于執行 ssh 命令的遠程用戶。 “Opts”包含傳遞給 SSH 的其他選項（例如，“ - i / tmp / my-key”）。最后，如果您有一些自定義環境設置，“cmd”是整個隧道（ssh）命令的覆蓋格式。默認字符串是{`/usr/bin/ssh %1$s %2$s%3$s%4$s "%5$s"`}，是一個很好的起點。這是一個標準的 Java 格式字符串，帶有 5 個參數，用于執行遠程命令。參數 1（％1 $ s）是 SSH 選項設置 via opts 設置或通過環境變量，2 是 SSH 用戶名，如果設置了 username，則 3 是“@”，否則，“4”是目標主機名，并且 5 是要執行的邏輯命令（可能包括單引號，因此不要使用它們）。例如，如果您在非 hbase 用戶下運行測試并希望 ssh 作為該用戶并在遠程計算機上更改為 hbase，則可以使用： ``` /usr/bin/ssh %1$s %2$s%3$s%4$s "su hbase - -c \"%5$s\"" ``` 這樣，殺死 RS（例如）集成測試可能會運行： ``` {/usr/bin/ssh some-hostname "su hbase - -c \"ps aux | ... | kill ...\""} ``` 該命令記錄在測試日志中，因此您可以驗證它是否適合您的環境。要禁用集成測試的運行，請在命令行`-PskipIntegrationTests`上傳遞以下配置文件。例如， ``` $ mvn clean install test -Dtest=TestZooKeeper -PskipIntegrationTests ``` #### 173.5.1。針對迷你群集運行集成測試 HBase 0.92 添加了`verify` maven 目標。調用它，例如通過執行`mvn verify`，將通過 maven [故障安全插件](https://maven.apache.org/plugins/maven-failsafe-plugin/)運行所有階段，包括驗證階段，運行所有上述 HBase 單元測試以及中的測試 HBase 集成測試組。完成 mvn install -DskipTests 后，您可以通過調用以下命令運行集成測試： ``` cd hbase-it mvn verify ``` 如果您只想在頂層運行集成測試，則需要運行兩個命令。第一：mvn failsafe：integration-test 這實際上運行所有集成測試。 > 即使存在測試失敗，該命令也將始終輸出`BUILD SUCCESS`。此時，您可以手動查找輸出失敗的測試。但是，maven 會為我們這樣做;只需使用：mvn failsafe：verify 上面的命令基本上查看了測試失敗的所有測試結果（因此不要刪除'target'目錄）并報告結果。 ##### 運行 Integration 測試的子集這與您指定運行單元測試子集（參見上文）的方式非常相似，但使用屬性`it.test`而不是`test`。要運行`IntegrationTestClassXYZ.java`，請使用：mvn failsafe：integration-test -Dit.test = IntegrationTestClassXYZ 您可能要做的下一件事是運行集成測試組，例如所有名為 IntegrationTestClassX _.java 的集成測試： mvn failsafe：integration-test -Dit.test =_ ClassX _ 這將運行與 **ClassX** 匹配的集成測試。這意味著任何匹配：“**_ / IntegrationTest _ClassX **”。您還可以使用逗號分隔列表運行多組集成測試（類似于單元測試）。使用匹配列表仍支持每個組的完整正則表達式匹配。這看起來像：mvn failsafe：integration-test -Dit.test =_ ClassX _，_ ClassY #### 173.5.2。針對分布式群集運行集成測試如果您已經安裝了 HBase 集群，則可以通過調用類`IntegrationTestsDriver`來啟動集成測試。您可能必須先運行 test-compile。配置將由 bin / hbase 腳本選取。 ``` mvn test-compile ``` 然后啟動測試： ``` bin/hbase [--config config_dir] org.apache.hadoop.hbase.IntegrationTestsDriver ``` 通過`-h`來使用這個甜蜜的工具。不帶任何參數運行 IntegrationTestsDriver 將啟動在`hbase-it/src/test`下找到的測試，具有`@Category(IntegrationTests.class)`注釋，名稱以`IntegrationTests`開頭。通過傳遞-h 來查看用法，以了解如何過濾測試類。您可以傳遞一個正則表達式，該正則表達式將根據完整的類名進行檢查;所以，可以使用類名的一部分。 IntegrationTestsDriver 使用 Junit 來運行測試。目前，不支持使用 maven 對分布式集群運行集成測試（參見 [HBASE-6201](https://issues.apache.org/jira/browse/HBASE-6201) ）。測試通過使用`DistributedHBaseCluster`（實現`HBaseCluster`）類中的方法與分布式集群交互，后者又使用可插入的`ClusterManager`。具體實現提供了用于執行特定于部署和環境的任務（SSH 等）的實際功能。默認`ClusterManager`是`HBaseClusterManager`，它使用 SSH 遠程執行 start / stop / kill / signal 命令，并假設一些 posix 命令（ps 等）。還假設運行測試的用戶具有足夠的“電源”來啟動/停止遠程計算機上的服務器。默認情況下，它從 env 中獲取`HBASE_SSH_OPTS`，`HBASE_HOME`，`HBASE_CONF_DIR`，并使用`bin/hbase-daemon.sh`執行操作。目前支持 tarball 部署，使用 _hbase-daemons.sh_ 和 [Apache Ambari](https://incubator.apache.org/ambari/) 部署的部署。 _/etc/init.d/_ 腳本現在不受支持，但可以輕松添加。對于其他部署選項，可以實現和插入 ClusterManager。 #### 173.5.3。破壞性集成/系統測試（ChaosMonkey） HBase 0.96 引入了一個名為`ChaosMonkey`的工具，該工具以 Netflix 的混沌猴工具的[同名工具為藍本。 ChaosMonkey 通過終止或斷開隨機服務器或將其他故障注入環境來模擬正在運行的集群中的實際故障。您可以使用 ChaosMonkey 作為獨立工具在其他測試運行時運行策略。在某些環境中，ChaosMonkey 始終在運行，以便不斷檢查高可用性和容錯是否按預期工作。](https://netflix.github.io/chaosmonkey/) ChaosMonkey 定義**動作**和**策略**。操作操作是預定義的事件序列，例如： * 重啟活動主人（睡 5 秒） * 重啟隨機區域服務器（睡 5 秒） * 重啟隨機區域服務器（睡眠 60 秒） * 重啟 META regionserver（睡 5 秒） * 重啟 ROOT regionserver（睡 5 秒） * 批量重啟 50％的區域服務器（睡眠 5 秒） * 滾動重啟 100％的區域服務器（睡眠 5 秒）政策策略是用于執行一個或多個動作的策略。默認策略基于預定義的操作權重每分鐘執行一次隨機操作。在 ChaosMonkey 中斷之前，將執行給定的策略。大多數 ChaosMonkey 操作都配置為具有合理的默認值，因此您可以針對現有群集運行 ChaosMonkey，而無需任何其他配置。以下示例使用默認配置運行 ChaosMonkey： ``` $ bin/hbase org.apache.hadoop.hbase.util.ChaosMonkey 12/11/19 23:21:57 INFO util.ChaosMonkey: Using ChaosMonkey Policy: class org.apache.hadoop.hbase.util.ChaosMonkey$PeriodicRandomActionPolicy, period:60000 12/11/19 23:21:57 INFO util.ChaosMonkey: Sleeping for 26953 to add jitter 12/11/19 23:22:24 INFO util.ChaosMonkey: Performing action: Restart active master 12/11/19 23:22:24 INFO util.ChaosMonkey: Killing master:master.example.com,60000,1353367210440 12/11/19 23:22:24 INFO hbase.HBaseCluster: Aborting Master: master.example.com,60000,1353367210440 12/11/19 23:22:24 INFO hbase.ClusterManager: Executing remote command: ps aux | grep master | grep -v grep | tr -s ' ' | cut -d ' ' -f2 | xargs kill -s SIGKILL , hostname:master.example.com 12/11/19 23:22:25 INFO hbase.ClusterManager: Executed remote command, exit code:0 , output: 12/11/19 23:22:25 INFO hbase.HBaseCluster: Waiting service:master to stop: master.example.com,60000,1353367210440 12/11/19 23:22:25 INFO hbase.ClusterManager: Executing remote command: ps aux | grep master | grep -v grep | tr -s ' ' | cut -d ' ' -f2 , hostname:master.example.com 12/11/19 23:22:25 INFO hbase.ClusterManager: Executed remote command, exit code:0 , output: 12/11/19 23:22:25 INFO util.ChaosMonkey: Killed master server:master.example.com,60000,1353367210440 12/11/19 23:22:25 INFO util.ChaosMonkey: Sleeping for:5000 12/11/19 23:22:30 INFO util.ChaosMonkey: Starting master:master.example.com 12/11/19 23:22:30 INFO hbase.HBaseCluster: Starting Master on: master.example.com 12/11/19 23:22:30 INFO hbase.ClusterManager: Executing remote command: /homes/enis/code/hbase-0.94/bin/../bin/hbase-daemon.sh --config /homes/enis/code/hbase-0.94/bin/../conf start master , hostname:master.example.com 12/11/19 23:22:31 INFO hbase.ClusterManager: Executed remote command, exit code:0 , output:starting master, logging to /homes/enis/code/hbase-0.94/bin/../logs/hbase-enis-master-master.example.com.out .... 12/11/19 23:22:33 INFO util.ChaosMonkey: Started master: master.example.com,60000,1353367210440 12/11/19 23:22:33 INFO util.ChaosMonkey: Sleeping for:51321 12/11/19 23:23:24 INFO util.ChaosMonkey: Performing action: Restart random region server 12/11/19 23:23:24 INFO util.ChaosMonkey: Killing region server:rs3.example.com,60020,1353367027826 12/11/19 23:23:24 INFO hbase.HBaseCluster: Aborting RS: rs3.example.com,60020,1353367027826 12/11/19 23:23:24 INFO hbase.ClusterManager: Executing remote command: ps aux | grep regionserver | grep -v grep | tr -s ' ' | cut -d ' ' -f2 | xargs kill -s SIGKILL , hostname:rs3.example.com 12/11/19 23:23:25 INFO hbase.ClusterManager: Executed remote command, exit code:0 , output: 12/11/19 23:23:25 INFO hbase.HBaseCluster: Waiting service:regionserver to stop: rs3.example.com,60020,1353367027826 12/11/19 23:23:25 INFO hbase.ClusterManager: Executing remote command: ps aux | grep regionserver | grep -v grep | tr -s ' ' | cut -d ' ' -f2 , hostname:rs3.example.com 12/11/19 23:23:25 INFO hbase.ClusterManager: Executed remote command, exit code:0 , output: 12/11/19 23:23:25 INFO util.ChaosMonkey: Killed region server:rs3.example.com,60020,1353367027826\. Reported num of rs:6 12/11/19 23:23:25 INFO util.ChaosMonkey: Sleeping for:60000 12/11/19 23:24:25 INFO util.ChaosMonkey: Starting region server:rs3.example.com 12/11/19 23:24:25 INFO hbase.HBaseCluster: Starting RS on: rs3.example.com 12/11/19 23:24:25 INFO hbase.ClusterManager: Executing remote command: /homes/enis/code/hbase-0.94/bin/../bin/hbase-daemon.sh --config /homes/enis/code/hbase-0.94/bin/../conf start regionserver , hostname:rs3.example.com 12/11/19 23:24:26 INFO hbase.ClusterManager: Executed remote command, exit code:0 , output:starting regionserver, logging to /homes/enis/code/hbase-0.94/bin/../logs/hbase-enis-regionserver-rs3.example.com.out 12/11/19 23:24:27 INFO util.ChaosMonkey: Started region server:rs3.example.com,60020,1353367027826\. Reported num of rs:6 ``` 輸出表明 ChaosMonkey 啟動了默認的`PeriodicRandomActionPolicy`策略，該策略配置了所有可用的操作。它選擇運行`RestartActiveMaster`和`RestartRandomRs`動作。 #### 173.5.4。可用政策 HBase 附帶了幾個 ChaosMonkey 策略，可在`hbase/hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/policies/`目錄中找到。 #### 173.5.5。配置單個 ChaosMonkey 操作可以在每次測試運行中配置 ChaosMonkey 集成測試。在 HBase CLASSPATH 中創建 Java 屬性文件，并使用`-monkeyProps`配置標志將其傳遞給 ChaosMonkey。可配置屬性及其默認值（如果適用）列在`org.apache.hadoop.hbase.chaos.factories.MonkeyConstants`類中。對于具有默認值的屬性，可以通過將它們包含在屬性文件中來覆蓋它們。以下示例使用名為 [monkey.properties](#monkey.properties) 的屬性文件。 ``` $ bin/hbase org.apache.hadoop.hbase.IntegrationTestIngest -m slowDeterministic -monkeyProps monkey.properties ``` 上面的命令將啟動集成測試和混亂猴子。它將在 HBase CLASSPATH 上查找屬性文件 _monkey.properties_ ;例如在 HBASE _conf_ dir 里面。這是一個混亂的猴子文件示例：示例 ChaosMonkey 屬性文件 ``` sdm.action1.period=120000 sdm.action2.period=40000 move.regions.sleep.time=80000 move.regions.max.time=1000000 move.regions.sleep.time=80000 batch.restart.rs.ratio=0.4f ``` 周期/時間以毫秒表示。 HBase 1.0.2 和更新版本增加了重啟 HBase 底層 ZooKeeper 仲裁或 HDFS 節點的能力。要使用這些操作，您需要在 ChaosMonkey 屬性文件中配置一些新屬性，這些屬性沒有合理的默認值，因為它們是特定于部署的，可能是`hbase-site.xml`或不同的屬性文件。 ``` <property> <name>hbase.it.clustermanager.hadoop.home</name> <value>$HADOOP_HOME</value> </property> <property> <name>hbase.it.clustermanager.zookeeper.home</name> <value>$ZOOKEEPER_HOME</value> </property> <property> <name>hbase.it.clustermanager.hbase.user</name> <value>hbase</value> </property> <property> <name>hbase.it.clustermanager.hadoop.hdfs.user</name> <value>hdfs</value> </property> <property> <name>hbase.it.clustermanager.zookeeper.user</name> <value>zookeeper</value> </property> ``` ## 174.開發者指南 ### 174.1。分行我們使用 Git 進行源代碼管理，并在`master`分支上進行最新的開發。過去的主要/次要/維護版本都有分支，重要的功能和錯誤修復通常會反向移植到它們。 ### 174.2。代碼標準 #### 174.2.1。接口分類界面按受眾和穩定性級別進行分類。這些標簽出現在班級的頭部。 HBase 遵循的約定由其父項目 Hadoop 繼承。通常使用以下接口分類： InterfaceAudience `@InterfaceAudience.Public` 用戶和 HBase 應用程序的 API。這些 API 將通過主要版本的 HBase 棄用。 `@InterfaceAudience.Private` HBase 內部開發人員的 API。在將來的版本中不保證兼容性或可用性。專用接口不需要`@InterfaceStability`分類。 `@InterfaceAudience.LimitedPrivate(HBaseInterfaceAudience.COPROC)` HBase 協處理器編寫器的 API。沒有`@InterfaceAudience`分類沒有`@InterfaceAudience`標簽的包被視為私有。如果可以公開訪問，請標記新包。 > 從 API 文檔中排除非公共接口 > > 只有分類`@InterfaceAudience.Public`的接口才應包含在 API 文檔（Javadoc）中。對于不包含公共類的新包，提交者必須為 _pom.xml_ 添加新包，不包括`ExcludePackageNames`部分。 @InterfaceStability `@InterfaceStability`對標有`@InterfaceAudience.Public`的包很重要。 `@InterfaceStability.Stable` 如果沒有棄用路徑或非常好的理由，則無法更改標記為穩定的公共包。 `@InterfaceStability.Unstable` 標記為不穩定的公共包可以在沒有棄用路徑的情況下進行更改。 `@InterfaceStability.Evolving` 標記為演變的公共包可能會被更改，但不鼓勵使用。沒有`@InterfaceStability`標簽不鼓勵沒有`@InterfaceStability`標簽的公共類，并且應該將其視為隱式不穩定。如果您不清楚如何標記包，請在開發列表中詢問。 #### 174.2.2。代碼格式約定請遵循以下準則，以便更快地審核您的補丁。這些指南是基于對新貢獻者的補丁的共同反饋而開發的。有關 Java 編碼約定的更多信息，請參見 [Java 編程語言的代碼約定](http://www.oracle.com/technetwork/java/index-135089.html)。請參閱 [eclipse.code.formatting](#eclipse.code.formatting) 以設置 Eclipse 以自動檢查其中一些指南。 ##### 太空侵略者不要在括號周圍使用額外的空格。使用第二種風格，而不是第一種風格。 ``` if ( foo.equals( bar ) ) { // don't do this ``` ``` if (foo.equals(bar)) { ``` ``` foo = barArray[ i ]; // don't do this ``` ``` foo = barArray[i]; ``` ##### 自動生成的代碼 Eclipse 中自動生成的代碼通常使用錯誤的變量名，例如`arg0`。使用更具信息性的變量名稱。像這里的第二個例子一樣使用代碼。 ``` public void readFields(DataInput arg0) throws IOException { // don't do this foo = arg0.readUTF(); // don't do this ``` ``` public void readFields(DataInput di) throws IOException { foo = di.readUTF(); ``` ##### 排長龍保持行少于 100 個字符。您可以將 IDE 配置為自動執行此操作。 ``` Bar bar = foo.veryLongMethodWithManyArguments(argument1, argument2, argument3, argument4, argument5, argument6, argument7, argument8, argument9); // don't do this ``` ``` Bar bar = foo.veryLongMethodWithManyArguments( argument1, argument2, argument3,argument4, argument5, argument6, argument7, argument8, argument9); ``` ##### 尾隨空間確保在代碼結束后有一個換行符，并避免只有空格的行。這使得差異更有意義。您可以配置 IDE 以幫助解決此問題。 ``` Bar bar = foo.getBar(); <--- imagine there is an extra space(s) after the semicolon. ``` ##### API 文檔（Javadoc）別忘了 Javadoc！在預先提交期間檢查 Javadoc 警告。如果預先提交工具給你一個'-1'，請修復 javadoc 問題。如果添加此類警告，則不會提交您的補丁。此外，沒有`@author`標簽 - 這是一個規則。 ##### FindBugs 的 `Findbugs`用于檢測常見錯誤模式。在 precommit 構建期間檢查它。如果發現錯誤，請修復它們。您可以使用`mvn findbugs:findbugs`在本地運行 findbugs，它將在本地生成`findbugs`文件。有時，您可能必須編寫比`findbugs`更智能的代碼。您可以通過使用以下注釋對類進行注釋來注釋代碼以告訴`findbugs`您知道自己在做什么： ``` @edu.umd.cs.findbugs.annotations.SuppressWarnings( value="HE_EQUALS_USE_HASHCODE", justification="I know what I'm doing") ``` 使用 Apache 許可版本的注釋很重要。這通常意味著在`edu.umd.cs.findbugs.annotations`包中使用注釋，這樣我們就可以依賴于潔凈室重新實現而不是`javax.annotations`包中的注釋。 ##### Javadoc - 無用的默認值不要像 IDE 生成它們那樣保留 javadoc 標記，也不要在其中填充冗余信息。 ``` /** * @param table <---- don't leave them empty! * @param region An HRegion object. <---- don't fill redundant information! * @return Foo Object foo just created. <---- Not useful information * @throws SomeException <---- Not useful. Function declarations already tell that! * @throws BarException when something went wrong <---- really? */ public Foo createFoo(Bar bar); ``` 添加描述符號的內容，或者只刪除它們。首選是添加描述性和有用的東西。 ##### 一次一件事，伙計們如果您為一件事提交補丁，請不要在完全不同的代碼區域上進行自動重新格式化或不相關的代碼重新格式化。同樣，不要在 Jira 的范圍之外添加不相關的清理或重構。 ##### 模糊單元測試確保您清楚自己在單元測試中測試的內容以及原因。 ##### 實現可寫 > 適用于 0.96 之前的版本 > > 在 0.96 中，HBase 轉移到協議緩沖區（protobufs）。關于 Writables 的以下部分適用于 0.94.x 及之前，而不是 0.96 及更高版本。 RegionServers 返回的每個類都必須實現`Writable`接口。如果要創建需要實現此接口的新類，請不要忘記默認構造函數。 #### 174.2.3。垃圾收集保護指南以下指南來自 [http://engineering.linkedin.com/performance/linkedin-feed-faster-less-jvm-garbage](http://engineering.linkedin.com/performance/linkedin-feed-faster-less-jvm-garbage) 。牢記這一點，將可預防的垃圾收集工作降至最低。請查看博客文章，了解如何根據這些指南重構代碼的一些很好的示例。 * 對迭代器要小心 * 初始化時估計集合的大小 * 推遲表達評估 * 提前編譯正則表達式模式 * 如果可以，請緩存它 * 字符串實習生很有用但很危險 ### 174.3。不變我們沒有很多，但我們在下面列出了什么。當然所有都受到挑戰，但在此之前，請遵守道路規則。 #### 174.3.1。 ZooKeeper 中沒有永久狀態 ZooKeeper 狀態應該是瞬態的（將其視為內存）。如果刪除 ZooKeeper 狀態，hbase 應該能夠恢復并且基本上處于相同的狀態。 * .Exceptions：目前我們需要解決幾個例外，無論表是啟用還是禁用。 * 復制數據當前僅存儲在 ZooKeeper 中。刪除與復制相關的 ZooKeeper 數據可能會導致禁用復制。不要刪除復制樹， _/ hbase / replication /_ 。 > 如果從 ZooKeeper 中刪除復制樹（ _/ hbase / replication /_ ），則可能會中斷復制并導致數據丟失。在 [HBASE-10295](https://issues.apache.org/jira/browse/HBASE-10295) 上關注此問題的進展。 ### 174.4。原地運行如果您正在開發 Apache HBase，那么測試您對更真實的集群的更改通常比您在單元測試中找到的更有用。在這種情況下，HBase 可以在本地模式下直接從源運行。您需要做的就是運行： ``` ${HBASE_HOME}/bin/start-hbase.sh ``` 這將啟動一個完整的本地群集，就像您已打包 HBase 并將其安裝在您的計算機上一樣。請記住，您需要將 HBase 安裝到本地 maven 存儲庫中，以使原位群集正常工作。也就是說，您需要運行： ``` mvn clean install -DskipTests ``` 確保 maven 可以找到正確的類路徑和依賴項。一般來說，如果 maven 行為奇怪，上面的命令首先嘗試運行是一件好事。 ### 174.5。添加指標添加新功能后，開發人員可能希望添加指標。 HBase 使用 Hadoop Metrics 2 系統公開指標，因此添加新指標涉及將該指標公開給 hadoop 系統。不幸的是，metrics2 的 API 從 hadoop 1 變為 hadoop 2.為了解決這個問題，必須在運行時加載一組接口和實現。要深入了解這些類的推理和結構，您可以閱讀[這里的博客文章](https://blogs.apache.org/hbase/entry/migration_to_the_new_metrics)。要向現有 MBean 添加指標，請遵循以下簡短指南： #### 174.5.1。將度量標準名稱和函數添加到 Hadoop Compat 接口。在源接口內部，對應于生成度量的位置（例如，來自 HMaster 的事物的 MetricsMasterSource）為度量標準名稱和描述創建新的靜態字符串。然后添加一個將被調用以添加新讀數的新方法。 #### 174.5.2。將實現添加到 Hadoop 1 和 Hadoop 2 Compat 模塊。在源的實現內部（例如，上例中的 MetricsMasterSourceImpl）在 init 方法中創建新的直方圖，計數器，計量器或 stat。然后在添加到接口的方法中連接傳入直方圖的參數。現在添加測試以確保數據正確導出到 metrics 2 系統。為此，提供了 MetricsAssertHelper。 ### 174.6。 Git 最佳實踐避免 git 合并。使用`git pull --rebase`或`git fetch`，然后按`git rebase`。不要使用`git push --force`。如果推送不起作用，請解決問題或尋求幫助。如果您考慮其他 Git 最佳實踐，請參與此文檔。 #### 174.6.1。 `rebase_all_git_branches.sh` 提供了 _dev-support / rebase_all_git _branches.sh_ 腳本以幫助保持 Git 存儲庫的清潔。使用`-h`參數獲取使用說明。該腳本會自動刷新您的跟蹤分支，嘗試針對其遠程分支自動重新定位每個本地分支，并為您提供刪除代表已關閉`HBASE-` JIRA 的任何分支的選項。該腳本有一個可選的配置選項，即 Git 目錄的位置。您可以通過編輯腳本來設置默認值。否則，您可以使用`-d`參數手動傳遞 git 目錄，然后使用絕對或相對目錄名稱，甚至是“。”對于當前的工作目錄。在繼續之前，腳本會檢查目錄中是否有名為 _.git /_ 的子目錄。 ### 174.7。提交補丁如果您不熟悉提交補丁到開源或新提交補丁到 Apache，請首先閱讀 [Apache Commons Project](https://commons.apache.org/) 中的 [On Contributing Patches](https://commons.apache.org/patches.html) 頁面。它提供了一個很好的概述，同樣適用于 Apache HBase 項目。 #### 174.7.1。創建補丁請務必查看 [common.patch.feedback](#common.patch.feedback) 的代碼樣式。如果您的補丁生成不正確或您的代碼不符合代碼格式指南，則可能會要求您重做某些工作。使用 submit-patch.py??（推薦） ``` $ dev-support/submit-patch.py -jid HBASE-xxxxx ``` 使用此腳本創建修補程序，上傳到 jira 并可選擇在 Re??view Board 上創建/更新評論。補丁名稱自動格式化為 _（JIRA）。（分支名稱）。（補丁號）。補丁 _ 遵循 Yetus 的命名規則。使用`-h`標志了解詳細的使用信息。最有用的選項是： * `-b BRANCH, --branch BRANCH`：指定用于生成 diff 的基本分支。如果未指定，則使用跟蹤分支。如果沒有跟蹤分支，則會拋出錯誤。 * `-jid JIRA_ID, --jira-id JIRA_ID`：如果使用，則從 jira 中的附件推斷下一個補丁版本并上傳新補丁。腳本將要求 jira 用戶名/密碼進行身份驗證。如果未設置，則將補丁命名為 <branch>.patch。</branch> 默認情況下，它還會創建/更新審核委員會。要跳過該操作，請使用`-srb`選項。它使用 jira 中的“問題鏈接”來確定審核請求是否已存在。如果沒有審核請求，則創建一個新請求并使用 jira 摘要，補丁說明等填充所有必填字段。此外，還將此評論的鏈接添加到 jira。保存身份驗證憑據（可選）由于在 JIRA 上附加補丁并在 ReviewBoard 上創建/更改審閱請求需要有效的用戶身份驗證，因此腳本將提示您輸入用戶名和密碼。為了避免每次麻煩，請使用登錄詳細信息設置`~/.apache-creds`并按照腳本幫助消息頁腳中的步驟對其進行加密。 Python 依賴項要安裝所需的 python 依賴項，請從 master 分支執行`pip install -r dev-support/python-requirements.txt`。手動 1. 首先使用`git rebase -i`，將較小的提交組合（壓縮）到一個較大的提交中。 2. 使用 IDE 或 Git 命令創建補丁。 `git format-patch`是首選，因為它保留了補丁作者的姓名和提交消息。此外，它默認處理二進制文件，而`git diff`忽略它們，除非您使用`--binary`選項。 3. 補丁名稱應如下符合 Ye??tus 的命名約定：`(JIRA).(branch name).(patch number).patch`例如。 HBASE-11625.master.001.patch，HBASE-XXXXX.branch-1.2.0005.patch 等 4. 使用`More→Attach Files`將補丁附加到 JIRA，然后單擊 **Submit Patch** 按鈕，這將觸發 Hudson 作業以檢查補丁的有效性。 5. 如果您的補丁長于單個屏幕，還可以在 Review Board 上創建評論并添加指向 JIRA 的鏈接。參見[評論板](#reviewboard)。一般指導原則很少 * 即使您要在另一個分支中進行修補，也要始終首先修補主分支。 HBase 提交程序始終首先將修補程序應用于主分支，并在必要時應用反向端口。 * 提交一個修補程序的單個修補程序。如有必要，首先將本地提交壓縮為單個提交。有關壓縮提交的更多信息，請參閱此[堆棧溢出問題](http://stackoverflow.com/questions/5308816/how-to-use-git-merge-squash)。 * 請理解并非每個補丁都可能會被提交，并且可能會在補丁上提供反饋。 * 如果您需要修改補丁，請將之前的補丁文件保留在 JIRA 上，然后上傳一個補丁編號增加的補丁文件。單擊**取消補丁**，然后單擊**提交補丁**以觸發預提交運行。 #### 174.7.2。單元測試在進行更改時始終添加和/或更新相關的單元測試。在提交補丁之前確保新的/更改的單元測試在本地通過，因為它比等待運行完整測試套件的預提交結果更快。這將節省您自己的時間和精力。使用 [mockito](#mockito) 制作模擬，這些模擬對于通過注入適當的故障來測試故障情況非常有用。如果要創建新的單元測試類，請注意其他單元測試類在類名稱之前是否具有分類/大小調整注釋以及用于設置/拆除測試環境的靜態方法。請務必在任何新的單元測試文件中包含注釋。有關測試的更多信息，請參見 [hbase.tests](#hbase.tests) 。 #### 174.7.3。集成測試除了單元測試之外，重要的新功能還應提供集成測試，適用于在其配置空間的不同點執行新功能。 #### 174.7.4。 ReviewBoard 大于一個屏幕的補丁或者難以查看的補丁應該通過 [ReviewBoard](https://reviews.apache.org) 。過程：使用 ReviewBoard 1. 如果您還沒有帳戶，請注冊一個帳戶。它不使用 [issues.apache.org](https://issues.apache.org) 的憑據。登錄。 2. 單擊“新建審閱請求” 3. 選擇`hbase-git`存儲庫。單擊“選擇文件”以選擇差異和可選的父差異。單擊**創建審核請求**。 4. 根據需要填寫字段。至少，填寫摘要并選擇`hbase`作為審核組。如果您填寫 Bugs 字段，審核委員會會鏈接回相關的 JIRA。您填寫的字段越多越好。點擊**發布**即可公開您的評論請求。將向`hbase`組中的每個人發送一封電子郵件，以查看該補丁。 5. 返回 JIRA，單擊并粘貼 ReviewBoard 請求的 URL。這將 ReviewBoard 附加到 JIRA，以便于訪問。 6. 要取消請求，請單擊。有關如何使用 ReviewBoard 的更多信息，請參閱 [ReviewBoard 文檔](http://www.reviewboard.org/docs/manual/1.5/)。 #### 174.7.5。 HBase 提交者指南 ##### 成為提交者提交者負責審查和整合代碼更改，測試和投票候選版本，權衡設計討論以及其他類型的項目貢獻。 PMC 根據對項目貢獻的評估，投票決定讓貢獻者成為提交者。預計提交者將展示對項目和社區參與的高質量貢獻的持續歷史。貢獻可以通過多種方式進行。成為提交者沒有單一的途徑，也沒有任何預期的時間表。提交功能，改進和錯誤修復是最常見的途徑，但其他方法都得到了認可和鼓勵（對于 HBase 作為項目和社區的健康狀況可能更為重要）。潛在貢獻的非詳盡清單（無特定順序）： * [更新文檔](#appendix_contributing_to_documentation)以了解新的更改，最佳做法，配方和其他改進。 * 使網站保持最新。 * 執行測試并報告結果。例如，總是贊賞尺度測試和測試非標準配置。 * 維護共享的 Jenkins 測試環境和其他測試基礎架構。 * [在執行驗證后投票發布候選](#hbase.rc.voting)，即使不具有約束力。非約束性投票是非提交者的投票。 * 為[郵件列表](/mail-lists.html)（通常在主題行中有`[DISCUSS]`）的討論主題提供輸入。 * 回答用戶或開發人員郵件列表和 Slack 上的問題。 * 確保 HBase 社區是一個熱情的社區，并且我們遵守我們的[行為準則](/coc.html)。如果您有疑慮，請提醒 PMC。 * 查看其他人的工作（代碼和非代碼）并提供公眾反饋。 * 報告找到的錯誤或提交新功能請求。 * 分類問題并保持 JIRA 的組織。這包括根據需要關閉陳舊問題，標記新問題，更新元數據和其他任務。 * 各種導師的新貢獻者。 * 談談和寫關于 HBase 的博客。將這些添加到網站的[新聞](/)部分。 * 提供有關 HBase，Web UI，CLI，API 和網站的 UX 反饋。 * 編寫演示應用程序和腳本。 * 幫助吸引和留住多元化的社區。 * 以有利于 HBase 和其他項目的方式與其他項目互動。并非每個人都能夠完成此列表中的所有（甚至任何）項目。如果您想到其他貢獻方式，請選擇它（并將它們添加到列表中）。為了對 HBase 項目產生積極影響，您需要一個愉快的風度和貢獻的意愿。邀請成為提交者是長期與社區穩定互動的結果，這建立了信任和認可。 ##### 新的提交者鼓勵新的提交者首先閱讀 Apache 的通用提交者文檔： * [Apache 新提交者指南](https://www.apache.org/dev/new-committers-guide.html) * [Apache Committer FAQ](https://www.apache.org/dev/committers.html) ##### 評論 HBase 提交者應盡可能多地嘗試審查其他人提交的補丁。理想情況下，每個提交的補丁都會在幾天內由提交者 _ 審核 _。如果提交者審查他們沒有創作的補丁，并認為它具有足夠的質量，那么他們可以提交補丁。否則，應該取消補丁，并清楚解釋它被拒絕的原因。提交的補丁列表位于 [HBase Review Queue](https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12312392) 中，該隊列按上次修改時間排序。提交者應該從上到下掃描列表，尋找他們認為有資格審查并可能提交的補丁。如果您看到一個補丁，您認為其他人更有資格審核，您可以在 JIRA 中通過用戶名提及它們。對于非平凡的更改，需要另一個提交者在提交之前檢查您的修補程序。 **不允許自行提交非平凡補丁。** 使用 JIRA 中的 **Submit Patch** 按鈕，就像其他貢獻者一樣，然后在提交之前等待來自另一個提交者的`+1`響應。 ##### 拒絕應拒絕不符合 [HowToContribute](https://hbase.apache.org/book.html#developer) 和[代碼審查清單](https://wiki.apache.org/hadoop/CodeReviewChecklist)中的指南的補丁。提交者應始終對貢獻者保持禮貌，并嘗試指導并鼓勵他們提供更好的補丁。如果提交者希望改進不可接受的補丁，那么首先應該拒絕補丁，并且應該由提交者附加新的補丁以供進一步審查。 ##### 承諾提交者向 Apache HBase GIT 存儲庫提交補丁。 > 在你提交之前！ > > 確保您的本地配置正確，尤其是您的身份和電子郵件。檢查$ git config --list 命令的輸出并確保它是正確的。如果需要指針，請參閱[設置 Git](https://help.github.com/articles/set-up-git) 。提交補丁時： 1. 在提交消息中包含 Jira 問題 ID 以及更改的簡短描述。嘗試添加不僅僅是 Jira 標題的東西，以便有人看`git log`輸出不必去 Jira 來辨別變化是什么。確保問題 ID 正確，因為這會導致 Jira 鏈接到 Git 中的更改（使用問題的“所有”選項卡查看這些自動鏈接）。 2. 將補丁提交到基于`master`或其他預期分支的新分支。在這個分支的名稱中包含 JIRA ID 是個好主意。查看要提交的相關目標分支，并通過執行 git pull --rebase 或其他類似命令確保本地分支具有所有遠程更改。接下來，櫻桃選擇每個相關分支（例如 master）的更改，并使用 git push <remote-server><remote-branch>等命令將更改推送到遠程分支。</remote-branch></remote-server> > 如果您沒有進行所有遠程更改，則推送將失敗。如果推送因任何原因失敗，請解決問題或尋求幫助。不要做 git push --force。在提交補丁之前，您需要確定補丁的創建方式。圍繞創建補丁的方式的說明和偏好已經改變，并且將存在過渡期。確定修補程序的創建方式 * 如果補丁的前幾行看起來像電子郵件的標題，帶有 From，Date 和 Subject，則使用 git format-patch 創建。這是首選方法，因為您可以重用提交者的提交消息。如果提交消息不合適，您仍然可以使用提交，然后根據需要運行`git commit --amend`和 reword。 * 如果補丁的第一行看起來類似于以下內容，則使用 git diff 創建而不使用`--no-prefix`。這也是可以接受的。注意文件名前面的`a`和`b`。這表明補丁不是用`--no-prefix`創建的。 ``` diff --git a/src/main/asciidoc/_chapters/developer.adoc b/src/main/asciidoc/_chapters/developer.adoc ``` * 如果補丁的第一行看起來類似于以下（沒有`a`和`b`），則補丁是使用 git diff --no-prefix 創建的，您需要將`-p0`添加到下面的 git apply 命令中。 ``` diff --git src/main/asciidoc/_chapters/developer.adoc src/main/asciidoc/_chapters/developer.adoc ``` 示例 43.提交補丁的示例你會注意到這些例子的一件事是有很多 git pull 命令。實際將任何東西寫入遠程存儲庫的唯一命令是 git push，你需要確保你擁有正確的所有版本，并且在推送之前沒有任何沖突。額外的 git pull 命令通常是多余的，但比抱歉更安全。第一個示例顯示如何應用使用 git format-patch 生成的補丁并將其應用于`master`和`branch-1`分支。使用 git format-patch 而不是 git diff 而不使用`--no-prefix`的指令是一個新指令。請參閱第二個示例，了解如何應用使用 git diff 創建的補丁，并教育創建補丁的人員。 ``` $ git checkout -b HBASE-XXXX $ git am ~/Downloads/HBASE-XXXX-v2.patch --signoff # If you are committing someone else's patch. $ git checkout master $ git pull --rebase $ git cherry-pick <sha-from-commit> # Resolve conflicts if necessary or ask the submitter to do it $ git pull --rebase # Better safe than sorry $ git push origin master # Backport to branch-1 $ git checkout branch-1 $ git pull --rebase $ git cherry-pick <sha-from-commit> # Resolve conflicts if necessary $ git pull --rebase # Better safe than sorry $ git push origin branch-1 $ git branch -D HBASE-XXXX ``` 此示例顯示如何提交使用 git diff 而不使用`--no-prefix`創建的修補程序。如果使用`--no-prefix`創建補丁，請將`-p0`添加到 git apply 命令。 ``` $ git apply ~/Downloads/HBASE-XXXX-v2.patch $ git commit -m "HBASE-XXXX Really Good Code Fix (Joe Schmo)" --author=<contributor> -a # This and next command is needed for patches created with 'git diff' $ git commit --amend --signoff $ git checkout master $ git pull --rebase $ git cherry-pick <sha-from-commit> # Resolve conflicts if necessary or ask the submitter to do it $ git pull --rebase # Better safe than sorry $ git push origin master # Backport to branch-1 $ git checkout branch-1 $ git pull --rebase $ git cherry-pick <sha-from-commit> # Resolve conflicts if necessary or ask the submitter to do it $ git pull --rebase # Better safe than sorry $ git push origin branch-1 $ git branch -D HBASE-XXXX ``` 3. 將問題解決為固定的，感謝貢獻者。此時始終設置“修復版本”，但僅為已提交更改的每個分支設置單個修訂版本，即將在其中顯示更改的分支中的最早版本。 ###### 提交消息格式提交消息應包含 JIRA ID 以及修補程序的功能描述。首選的提交消息格式為： ``` <jira-id> <jira-title> (<contributor-name-if-not-commit-author>) ``` ``` HBASE-12345 Fix All The Things (jane@example.com) ``` 如果貢獻者使用 git format-patch 生成補丁，則他們的提交消息在他們的補丁中，您可以使用它，但請確保 JIRA ID 位于提交消息的前面，即使貢獻者將其遺漏。 ###### 在沖突櫻桃回擊后添加修改 - 作者我們已經建立了承諾掌握的做法，然后盡可能地回到分支機構，除非 * 它正在打破 compat：在這種情況下，如果它可以進入次要版本，則向后移植到 branch-1 和 branch-2。 * 這是一個新功能：對于維護版本不適用，對于次要版本，討論并達成共識。當存在輕微沖突時，我們可以修復它并繼續提交。生成的提交保留原始作者。當修改作者與原始提交者不同時，在提交消息的末尾添加以下內容：`Amending-Author: Author <committer&apache>`參見[HBase，mail＃dev - [討論](http://search-hadoop.com/m/DHED4wHGYS)的討論修改提交時的最佳實踐從主人到分店挑選]。 ###### 關閉相關的 GitHub PR 作為一個項目，我們努力確保每個變更都有一個 JIRA，但我們并未要求任何特定工具用于評審。由于 ASF 在托管的 git 存儲庫和 GitHub 之間的集成的實現細節，PMC 無法直接關閉我們的 GitHub 存儲庫上的 PR。如果貢獻者在 GitHub 上發出了拉取請求，或者因為貢獻者發現比將補丁附加到 JIRA 更容易，或者因為審閱者更喜歡用于檢查更改的 UI，那么在提交中記下 PR 是很重要的。到主分支，以便 PR 保持最新。要閱讀有關 GitHub“close via keyword in commit”機制的提示消息的詳細信息，請參閱 [GitHub 文檔“使用關鍵字關閉問題”](https://help.github.com/articles/closing-issues-using-keywords/)。總之，您應該包含一個包含短語“closing #XXX”的行，其中 XXX 是拉取請求 ID。拉取請求 ID 通常在主題標題末尾的灰色 GitHub UI 中給出。 ###### 提交者負責確保提交不會破壞構建或測試如果提交者提交補丁，他們有責任確保它通過測試套件。如果貢獻者注意他們的補丁不會破壞 hbase 構建和/或測??試，那么這是有幫助的，但最終，不能指望貢獻者知道像 HBase 這樣的項目中發生的所有特定變幻莫測和互連。提交者應該。 ###### 修補禮儀在線程 [HBase，郵件#dev - 通知：Git Migration In Progress（WAS?Re：Git Migration）](http://search-hadoop.com/m/DHED4EiwOz)中，對以下補丁流程達成了一致意見 1. 首先開發并提交針對 master 的補丁。 2. 如果可能的話，嘗試在向后移動時挑選補丁。 3. 如果這不起作用，請手動將修補程序提交到分支。 ###### 合并提交避免合并提交，因為它們會在 git 歷史記錄中產生問題。 ###### 提交文檔參見文獻的[附錄。](#appendix_contributing_to_documentation) #### 174.7.6。對話提交者應該在 irc.freenode.net 的#hbase 會議室中進行實時討論。但是，任何實質性討論（與任何列表項目相關的討論一樣）都應該在 Jira 或開發人員列表中重新進行。 #### 174.7.7。不要編輯 JIRA 評論拼寫錯誤和/或錯誤的語法比 JIRA 評論編輯導致的中斷更可取：參見[上的討論 Re：（HBASE-451）從 HRegionInfo](http://search-hadoop.com/?q=%5BReopened%5D+%28HBASE-451%29+Remove+HTableDescriptor+from+HRegionInfo&fc_project=HBase) 中刪除 HTableDescriptor ### 174.8。 hbase-thirdparty 依賴和著色/重定位為 hbase-2.0.0 的發布創建了一個新項目。它被稱為`hbase-thirdparty`。該項目僅用于為主 hbase 項目提供流行的第三方庫（如番石榴，netty 和 protobuf）的重定位或陰影版本。主線 HBase 項目依賴于從 hbase-thirdparty 獲取的這些庫的重定位版本，而不是在通常位置查找這些類。我們這樣做，所以我們可以指定我們希望的任何版本。如果我們不重新定位，我們必須協調我們的版本以匹配 hadoop，spark 和其他項目使用的版本。對于開發人員來說，這意味著你需要小心引用 netty，guava，protobuf，gson 等類。（參見 hbase-thirdparty pom.xml 提供的內容）。開發人員必須參考 hbase-thirdparty 提供的類。在實踐中，這通常不是問題（雖然它可能有點痛苦）。您將不得不尋找特定類的重定位版本。您可以通過添加`org.apache.hbase.thirdparty.`的常規重定位前綴來找到它。例如，如果您正在尋找`com.google.protobuf.Message`，HBase 內部使用的重新定位版本可以在`org.apache.hbase.thirdparty.com.google.protobuf.Message`中找到。對于一些第三方庫，比如 protobuf（參見本書中的 protobuf 章節了解原因），你的 IDE 可能會給你兩個選項 - `com.google.protobuf.` **和`org.apache.hbase.thirdparty.com.google.protobuf.`** - 因為這兩個類都在你的 CLASSPATH。除非您正在進行協處理器端點開發所需的特定雜耍（再次參見上面引用的 protobuf 章節），否則您將始終使用著色版本。 `hbase-thirdparty`項目的 groupid 為`org.apache.hbase.thirdparty`。在撰寫本文時，它提供了三個罐子;一個用于`hbase-thirdparty-netty`的人工制造，一個用于`hbase-thirdparty-protobuf`的 protobuf，然后是一個罐子用于其他所有 - gson，番石榴 - 在`hbase-thirdpaty-miscellaneous`。 hbase-thirdparty 工件是由 HBase 項目管理委員會支持下的 Apache HBase 項目生成的產品。發布是通過 hbase dev 郵件列表上的常規投票項目完成的。如果在 hbase-thirdparty 中出現問題，請使用 hbase JIRA 和郵件列表發布通知。 ### 174.9。 HBase 相關 Maven 原型的開發 HBase 相關 Maven 原型的開發始于 [HBASE-14876](https://issues.apache.org/jira/browse/HBASE-14876) 。有關 hbase-archetypes 基礎結構的概述以及開發新的 HBase 相關 Maven 原型的說明，請參閱`hbase/hbase-archetypes/README.md`。