You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@accumulo.apache.org by ct...@apache.org on 2022/11/02 21:26:21 UTC
[accumulo-website] branch main updated: Fix typos/grammar in docs2 (#366)
This is an automated email from the ASF dual-hosted git repository.
ctubbsii pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/accumulo-website.git
The following commit(s) were added to refs/heads/main by this push:
new 46e7a445 Fix typos/grammar in docs2 (#366)
46e7a445 is described below
commit 46e7a4453aa5799827d164cf751e28eb19bc1292
Author: Dom G <do...@gmail.com>
AuthorDate: Wed Nov 2 17:26:16 2022 -0400
Fix typos/grammar in docs2 (#366)
Co-authored-by: Christopher Tubbs <ct...@apache.org>
---
_docs-2/administration/caching.md | 2 +-
_docs-2/administration/compaction.md | 12 ++++++------
_docs-2/administration/fate.md | 6 +++---
_docs-2/administration/in-depth-install.md | 12 ++++++------
_docs-2/administration/multivolume.md | 2 +-
_docs-2/administration/replication.md | 4 ++--
_docs-2/administration/scan-executors.md | 8 ++++----
_docs-2/administration/upgrading.md | 12 ++++++------
_docs-2/configuration/files.md | 6 +++---
_docs-2/configuration/overview.md | 4 ++--
_docs-2/configuration/server-properties.md | 2 +-
_docs-2/development/iterators.md | 6 +++---
_docs-2/development/sampling.md | 2 +-
_docs-2/development/summaries.md | 6 +++---
_docs-2/getting-started/clients.md | 14 +++++++-------
_docs-2/getting-started/design.md | 4 ++--
_docs-2/getting-started/features.md | 8 ++++----
_docs-2/getting-started/glossary.md | 2 +-
_docs-2/getting-started/quickstart.md | 6 +++---
_docs-2/getting-started/table_configuration.md | 14 +++++++-------
_docs-2/security/authorizations.md | 4 ++--
_docs-2/security/kerberos.md | 10 +++++-----
_docs-2/security/on-disk-encryption.md | 2 +-
_docs-2/security/wire-encryption.md | 2 +-
_docs-2/troubleshooting/advanced.md | 10 +++++-----
_docs-2/troubleshooting/basic.md | 6 +++---
_docs-2/troubleshooting/system-metadata-tables.md | 2 +-
_docs-2/troubleshooting/tools.md | 4 ++--
28 files changed, 86 insertions(+), 86 deletions(-)
diff --git a/_docs-2/administration/caching.md b/_docs-2/administration/caching.md
index 1438cbda..cea0fd68 100644
--- a/_docs-2/administration/caching.md
+++ b/_docs-2/administration/caching.md
@@ -19,7 +19,7 @@ for tables where read performance is critical.
## Configuration
The {% plink tserver.cache.manager.class %} property controls which block cache implementation is used within the tablet server. Users
-can supply their own implementation and set custom configuration properties to control it's behavior (see org.apache.accumulo.core.spi.cache.BlockCacheManager$Configuration.java).
+can supply their own implementation and set custom configuration properties to control its behavior (see org.apache.accumulo.core.spi.cache.BlockCacheManager$Configuration.java).
The index and data block caches are configured for tables by the following properties:
diff --git a/_docs-2/administration/compaction.md b/_docs-2/administration/compaction.md
index 577d4f6c..6ef01668 100644
--- a/_docs-2/administration/compaction.md
+++ b/_docs-2/administration/compaction.md
@@ -6,7 +6,7 @@ order: 6
In Accumulo each tablet has a list of files associated with it. As data is
written to Accumulo it is buffered in memory. The data buffered in memory is
-eventually written to files in DFS on a per tablet basis. Files can also be
+eventually written to files in DFS on a per-tablet basis. Files can also be
added to tablets directly by bulk import. In the background tablet servers run
major compactions to merge multiple files into one. The tablet server has to
decide which tablets to compact and which files within a tablet to compact.
@@ -32,7 +32,7 @@ a set. The default planner looks for file sets where LFS*CR <= FSS. By only
compacting sets of files that meet this requirement the amount of work done by
compactions is O(N * log<sub>CR</sub>(N)). Increasing the ratio will
result in less compaction work and more files per tablet. More files per
-tablet means more higher query latency. So adjusting this ratio is a trade off
+tablet means higher query latency. So adjusting this ratio is a trade-off
between ingest and query performance.
When CR=1.0 this will result in a goal of a single per file tablet, but the
@@ -48,7 +48,7 @@ of this documentation only applies to Accumulo 2.1 and later.
Below are some Accumulo shell commands that do the following :
* Create a compaction service named `cs1` that has three executors. The first executor named `small` has 8 threads and runs compactions less than 16M. The second executor `medium` runs compactions less than 128M with 4 threads. The last executor `large` runs all other compactions.
- * Create a compaction service named `cs2` that has three executors. It has similar config to `cs1`, but its executors have less threads. Limits total I/O of all compactions within the service to 40MB/s.
+ * Create a compaction service named `cs2` that has three executors. It has similar config to `cs1`, but its executors have fewer threads. Limits total I/O of all compactions within the service to 40MB/s.
* Configure table `ci` to use compaction service `cs1` for system compactions and service `cs2` for user compactions.
```
@@ -97,7 +97,7 @@ accumulo compactor -q <queueName>
### Configuration
Configuration for external compactions is very similar to the internal compaction example above.
-In the example below we create a Compaction Service `cs1` and configure it with an queue
+In the example below we create a Compaction Service `cs1` and configure it with a queue
named `DCQ1`. We then define the Compaction Dispatcher on table `testTable` and configure the
table to use the `cs1` Compaction Service for planning and executing all compactions.
@@ -120,7 +120,7 @@ The CompactionCoordinator is responsible for managing the global external compac
When a Compactor is free to perform work, it asks the CompactionCoordinator for the next compaction job. The CompactionCoordinator contacts the next TabletServer that has the highest priority for the Compactor's queue. The TabletServer returns the information necessary for the compaction to occur to the CompactionCoordinator, which is passed on to the Compactor. The Compaction Coordinator maintains an in-memory list of running compactions and also inserts an entry into the metadata table [...]
-External compactions handle faults and major system events in Accumulo. When a compactor process dies this will be detected and any files it had reserved in a tablet will be unreserved. When a tserver dies, this will not impact any external compactions running on behalf of tablets that tserver was hosting. The case of tablets not being hosted on an tserver when an external compaction tries to commit is also handled. Tablets being deleted (by split, merge, or table deletion) will cause [...]
+External compactions handle faults and major system events in Accumulo. When a compactor process dies this will be detected and any files it had reserved in a tablet will be unreserved. When a tserver dies, this will not impact any external compactions running on behalf of tablets that tserver was hosting. The case of tablets not being hosted on a tserver when an external compaction tries to commit is also handled. Tablets being deleted (by split, merge, or table deletion) will cause [...]
### External Compaction in Action
@@ -241,7 +241,7 @@ Finally, the TabletServer commits the compaction.
The names of compaction services and executors are used in logging. The log
messages below are from a tserver with the configuration above with data being
-written to the ci table. Also a compaction of the table was forced from the
+written to the ci table. Also, a compaction of the table was forced from the
shell.
```
diff --git a/_docs-2/administration/fate.md b/_docs-2/administration/fate.md
index 55a26911..a6aca4a9 100644
--- a/_docs-2/administration/fate.md
+++ b/_docs-2/administration/fate.md
@@ -32,7 +32,7 @@ of these operations. This property is also what guarantees safety in light of fa
### REPO Stack
A FATE transaction is composed of a sequence of Repeatable persisted operations (REPO). In order to start a FATE transaction,
-a REPO is pushed onto a per transaction REPO stack. The top of the stack always contains the
+a REPO is pushed onto a per-transaction REPO stack. The top of the stack always contains the
next REPO the FATE transaction should execute. When a REPO is successful it may return another
REPO which is pushed on the stack.
@@ -147,8 +147,8 @@ invoke. It is not normal to invoke this command.
This command accepts zero more transaction IDs. If given no transaction IDs,
it will dump all active transactions. A FATE operations is compromised as a
sequence of REPOs. In order to start a FATE transaction, a REPO is pushed onto
-a per transaction REPO stack. The top of the stack always contains the next
+a per-transaction REPO stack. The top of the stack always contains the next
REPO the FATE transaction should execute. When a REPO is successful it may
return another REPO which is pushed on the stack. The `dump` command will
print all of the REPOs on each transactions stack. The REPOs are serialized to
-JSON in order to make them human readable.
+JSON in order to make them human-readable.
diff --git a/_docs-2/administration/in-depth-install.md b/_docs-2/administration/in-depth-install.md
index f4c8366c..81b1f8b1 100644
--- a/_docs-2/administration/in-depth-install.md
+++ b/_docs-2/administration/in-depth-install.md
@@ -103,7 +103,7 @@ manually or run `accumulo-cluster create-config`.
Logging is configured in [accumulo-env.sh] to use three log4j configuration files in `conf/`. The
file used depends on the Accumulo command or service being run. Logging for most Accumulo services
-(i.e Manager, TabletServer, Garbage Collector) is configured by [log4j-service.properties] except for
+(i.e. Manager, TabletServer, Garbage Collector) is configured by [log4j-service.properties] except for
the Monitor which is configured by [log4j-monitor.properties]. All Accumulo commands (i.e `init`,
`shell`, etc) are configured by [log4j.properties].
@@ -251,7 +251,7 @@ instance, Accumulo identifies `localhost:8020` as a different HDFS instance than
### Deploy Configuration
Copy [accumulo-env.sh] and [accumulo.properties] from the `conf/` directory on the manager to all
-Accumulo tablet servers. The "host" configuration files files `accumulo-cluster` only need to be on
+Accumulo tablet servers. The "host" configuration files `accumulo-cluster` only need to be on
servers where that command is run.
### Sensitive Configuration Values
@@ -351,7 +351,7 @@ Below is an example for specify the app1 context in the [accumulo.properties] fi
general.vfs.context.classpath.app1=hdfs://localhost:8020/applicationA/classpath/.*.jar,file:///opt/applicationA/lib/.*.jar
```
-The default behavior follows the Java ClassLoader contract in that classes, if they exists, are
+The default behavior follows the Java ClassLoader contract in that classes, if they exist, are
loaded from the parent classloader first. You can override this behavior by delegating to the parent
classloader after looking in this classloader first. An example of this configuration is:
@@ -439,7 +439,7 @@ stopped and recovery will not need to be performed when the tablets are re-hoste
Occasionally, it might be necessary to restart the processes on a specific node. In addition
to the `accumulo-cluster` script, Accumulo has a `accumulo-service` script that
-can be use to start/stop processes on a node.
+can be used to start/stop processes on a node.
#### A note on rolling restarts
@@ -730,11 +730,11 @@ can be exacerbated by resource constraints and clock drift.
Each release of Accumulo is built with a specific version of Apache
Hadoop, Apache ZooKeeper and Apache Thrift. We expect Accumulo to
work with versions that are API compatible with those versions.
-However this compatibility is not guaranteed because Hadoop, ZooKeeper
+However, this compatibility is not guaranteed because Hadoop, ZooKeeper
and Thrift may not provide guarantees between their own versions. We
have also found that certain versions of Accumulo and Hadoop included
bugs that greatly affected overall stability. Thrift is particularly
-prone to compatibility changes between versions and you must use the
+prone to compatibility changes between versions, and you must use the
same version your Accumulo is built with.
Please check the release notes for your Accumulo version or use the
diff --git a/_docs-2/administration/multivolume.md b/_docs-2/administration/multivolume.md
index 07164080..3aed973e 100644
--- a/_docs-2/administration/multivolume.md
+++ b/_docs-2/administration/multivolume.md
@@ -56,7 +56,7 @@ Using viewfs or HA namenode, introduced in Hadoop 2, offers another option for
managing the fully qualified URIs stored in Accumulo. Viewfs and HA namenode
both introduce a level of indirection in the Hadoop configuration. For
example assume viewfs:///nn1 maps to hdfs://nn1 in the Hadoop configuration.
-If viewfs://nn1 is used by Accumulo, then its easy to map viewfs://nn1 to
+If viewfs://nn1 is used by Accumulo, then it's easy to map viewfs://nn1 to
hdfs://nnA by changing the Hadoop configuration w/o doing anything to Accumulo.
A production system should probably use a HA namenode. Viewfs may be useful on
a test system with a single non HA namenode.
diff --git a/_docs-2/administration/replication.md b/_docs-2/administration/replication.md
index fe9947fe..cb18a616 100644
--- a/_docs-2/administration/replication.md
+++ b/_docs-2/administration/replication.md
@@ -26,7 +26,7 @@ space available on the primary system.
Replication configurations can be considered as a directed graph which allows cycles.
The systems in which data was replicated from is maintained in each Mutation which
-allow each system to determine if a peer has already has the data in which
+allow each system to determine if a peer already has the data in which
the system wants to send.
Data is replicated by using the Write-Ahead logs (WAL) that each TabletServer is
@@ -233,7 +233,7 @@ root@peer> grant -t my_table -u peer Table.READ
root@peer> tables -l
```
-Remember what the table ID for 'my_table' is. You'll need that to configured the primary instance.
+Remember what the table ID for 'my_table' is. You'll need that to configure the primary instance.
### Primary
diff --git a/_docs-2/administration/scan-executors.md b/_docs-2/administration/scan-executors.md
index 09ed5aaf..e3976d15 100644
--- a/_docs-2/administration/scan-executors.md
+++ b/_docs-2/administration/scan-executors.md
@@ -58,7 +58,7 @@ SimpleScanDispatcher supports an `executor` option for choosing a scan
executor. If this option is not set, then SimpleScanDispatcher will dispatch
to the scan executor named `default`.
-To to tie everything together, consider the following use case.
+To tie everything together, consider the following use case.
* Create tables named LOW1 and LOW2 using a scan executor with a single thread.
* Create a table named HIGH with a dedicated scan executor with 8 threads.
@@ -89,7 +89,7 @@ config -t HIGH -s table.scan.dispatcher=org.apache.accumulo.core.spi.scan.Simple
config -t HIGH -s table.scan.dispatcher.opts.executor=high
```
-While not necessary because its the default, it is safer to also set
+While not necessary because it's the default, it is safer to also set
`table.scan.dispatcher=org.apache.accumulo.core.spi.scan.SimpleScanDispatcher`
for each table. This ensures things work as expected in the case where
`table.scan.dispatcher` was set at the system or namespace level.
@@ -97,7 +97,7 @@ for each table. This ensures things work as expected in the case where
### Configuring and using Scan Prioritizers.
When all scan executor threads are busy, incoming work is queued. By
-default this queue has a FIFO order. A {% jlink org.apache.accumulo.core.spi.scan.ScanPrioritizer %} can be configured to
+default, this queue has a FIFO order. A {% jlink org.apache.accumulo.core.spi.scan.ScanPrioritizer %} can be configured to
reorder the queue. Accumulo ships with the {% jlink org.apache.accumulo.core.spi.scan.IdleRatioScanPrioritizer %} which
orders the queue by the ratio of run time to idle time. For example, a scan
with a run time of 50ms and an idle time of 200ms would have a ratio of .25.
@@ -161,7 +161,7 @@ scan -t tex --execution-hints scan_type=alpha
Execution Hints can also be used to influence how the block caches are used for
a scan. The following configuration would modify the `gamma` executor to use blocks
-in the cache if they are already cached, but would never load mising blocks into the
+in the cache if they are already cached, but would never load missing blocks into the
cache.
```
diff --git a/_docs-2/administration/upgrading.md b/_docs-2/administration/upgrading.md
index 2e46e460..d9ee2bf2 100644
--- a/_docs-2/administration/upgrading.md
+++ b/_docs-2/administration/upgrading.md
@@ -69,7 +69,7 @@ Below are some changes in 2.0 that you should be aware of:
* `accumulo-service` script can be used to start/stop Accumulo services (i.e master, tablet server, monitor) on a single node.
- Can be used even if Accumulo was started using `accumulo-cluster` script.
* `accumulo-env.sh` constructs environment variables (such as `JAVA_OPTS` and `CLASSPATH`) used when running Accumulo processes
- - This file was used in Accumulo 1.x but has changed signficantly for 2.0
+ - This file was used in Accumulo 1.x but has changed significantly for 2.0
- Environment variables (such as `$cmd`, `$bin`, `$conf`) are set before `accumulo-env.sh` is loaded and can be used to customize environment.
- The `JAVA_OPTS` variable is constructed in `accumulo-env.sh` to pass command-line arguments to the `java` command that the starts Accumulo processes
(i.e. `java $JAVA_OPTS main.class.for.$cmd`).
@@ -98,7 +98,7 @@ that users start using the new API, the old API will continue to be supported th
Below is a list of client API changes that users are required to make for 2.0:
-* Update your pom.xml use Accumulo 2.0. Also, update any Hadoop & ZooKeeper dependencies in your pom.xml to match the versions runing on your cluster.
+* Update your pom.xml use Accumulo 2.0. Also, update any Hadoop & ZooKeeper dependencies in your pom.xml to match the versions running on your cluster.
```xml
<dependency>
<groupId>org.apache.accumulo</groupId>
@@ -106,7 +106,7 @@ Below is a list of client API changes that users are required to make for 2.0:
<version>2.0.1</version>
</dependency>
```
-* ClientConfiguration objects can no longer be ceated using `new ClientConfiguration()`.
+* ClientConfiguration objects can no longer be created using `new ClientConfiguration()`.
* Use `ClientConfiguration.create()` instead
* Some API deprecated in 1.x releases was dropped
* Aggregators have been removed
@@ -114,7 +114,7 @@ Below is a list of client API changes that users are required to make for 2.0:
Below is a list of recommended client API changes:
* The API for [creating Accumulo clients]({% durl getting-started/clients#creating-an-accumulo-client %}) has changed in 2.0.
- * The old API using [ZooKeeeperInstance], [Connector], [Instance], and [ClientConfiguration] has been deprecated.
+ * The old API using [ZooKeeperInstance], [Connector], [Instance], and [ClientConfiguration] has been deprecated.
* [Connector] objects can be created from an [AccumuloClient] object using [Connector.from()]
* Accumulo's [MapReduce API]({% durl development/mapreduce %}) has changed in 2.0.
* A new API has been introduced in the `org.apache.accumulo.hadoop` package of the `accumulo-hadoop-mapreduce` jar.
@@ -135,7 +135,7 @@ For upgrades from prior to 1.7, follow the upgrade instructions to 1.7 first.
The recommended way to upgrade from a prior 1.7.x release is to stop Accumulo, upgrade to 1.7.y and then start 1.7.y.
-When upgrading, there is a known issue if the upgrade fails due to outstanding [FATE] operations, see [ACCUMULO-4496] The work around if this situation is encountered:
+When upgrading, there is a known issue if the upgrade fails due to outstanding [FATE] operations, see [ACCUMULO-4496] The workaround if this situation is encountered:
- Start tservers
- Start shell
@@ -225,7 +225,7 @@ This happens automatically the first time Accumulo 1.5 is started.
[FATE]: {{ site.baseurl }}/1.7/accumulo_user_manual.html#_fault_tolerant_executor_fate
[ACCUMULO-4496]: https://issues.apache.org/jira/browse/ACCUMULO-4496
-[ZooKeeeperInstance]: {% jurl org.apache.accumulo.core.client.ZooKeeperInstance %}
+[ZooKeeperInstance]: {% jurl org.apache.accumulo.core.client.ZooKeeperInstance %}
[Connector]: {% jurl org.apache.accumulo.core.client.Connector %}
[Instance]: {% jurl org.apache.accumulo.core.client.Instance %}
[ClientConfiguration]: {% jurl org.apache.accumulo.core.client.ClientConfiguration %}
diff --git a/_docs-2/configuration/files.md b/_docs-2/configuration/files.md
index 41a4ecb5..37aaa70d 100644
--- a/_docs-2/configuration/files.md
+++ b/_docs-2/configuration/files.md
@@ -11,7 +11,7 @@ Accumulo has the following configuration files which can be found in the
The {% ghc assemble/conf/accumulo.properties %} file configures Accumulo server processes using
[server properties]({% durl configuration/server-properties %}). This file can be found in the `conf/`
-direcory. It is needed on every host that runs Accumulo processes. Therfore, any configuration should be
+directory. It is needed on every host that runs Accumulo processes. Therefore, any configuration should be
replicated to all hosts of the Accumulo cluster. If a property is not configured here, it might have been
[configured another way]({% durl configuration/overview %}). See the [quick start] for help with
configuring this file.
@@ -74,11 +74,11 @@ to run standby Monitors that can take over if the lead Monitor fails.
### tserver
Contains list of hosts where [Tablet Server] processes should run. While only one host is needed, it is recommended that
-multiple tablet servers are run for improved fault tolerance and peformance.
+multiple tablet servers are run for improved fault tolerance and performance.
### sserver
-Contains a list of hosts where [ScanServer] processes should run. While only only one host is needed, it is recommended
+Contains a list of hosts where [ScanServer] processes should run. While only one host is needed, it is recommended
that multiple ScanServers are run for improved performance.
### compaction coordinator
diff --git a/_docs-2/configuration/overview.md b/_docs-2/configuration/overview.md
index 42596359..0445f0a4 100644
--- a/_docs-2/configuration/overview.md
+++ b/_docs-2/configuration/overview.md
@@ -13,7 +13,7 @@ Configuration is managed differently for Accumulo clients and servers.
## Server Configuration
-Accumulo processes (i.e manager, tablet server, monitor, etc) are configured by [server properties] whose values can be
+Accumulo processes (i.e. manager, tablet server, monitor, etc.) are configured by [server properties] whose values can be
set in the following configuration locations (with increasing precedence):
1. [Default](#default) - All properties have a default value
@@ -72,7 +72,7 @@ client.instanceOperations().modifyProperties(properties -> {
```
### Namespace
-Namespace configuration refers to [table.* properties] set for a certain table namespace (i.e group of tables). These settings are stored in ZooKeeper. Namespace configuration
+Namespace configuration refers to [table.* properties] set for a certain table namespace (i.e. group of tables). These settings are stored in ZooKeeper. Namespace configuration
will override System configuration and can be set using the following shell command:
config -ns NAMESPACE -s PROPERTY=VALUE
diff --git a/_docs-2/configuration/server-properties.md b/_docs-2/configuration/server-properties.md
index 50908586..72f9d9e3 100644
--- a/_docs-2/configuration/server-properties.md
+++ b/_docs-2/configuration/server-properties.md
@@ -6,7 +6,7 @@ order: 4
<!-- WARNING: Do not edit this file. It is a generated file that is copied from Accumulo build (from core/target/generated-docs) -->
-Below are properties set in `accumulo.properties` or the Accumulo shell that configure Accumulo servers (i.e tablet server, manager, etc). Properties labeled 'Experimental' should not be considered stable and have a higher risk of changing in the future.
+Below are properties set in `accumulo.properties` or the Accumulo shell that configure Accumulo servers (i.e. tablet server, manager, etc). Properties labeled 'Experimental' should not be considered stable and have a higher risk of changing in the future.
| Property | Description |
|--------------|-------------|
diff --git a/_docs-2/development/iterators.md b/_docs-2/development/iterators.md
index 275331c7..54808482 100644
--- a/_docs-2/development/iterators.md
+++ b/_docs-2/development/iterators.md
@@ -68,7 +68,7 @@ optimize itself.
The purpose of the seek method is to advance the stream of Key-Value pairs to a certain point in the iteration (the Accumulo table). It is common that before
the implementation of this method returns some additional processing is performed which may further advance the current
position past the `startKey` of the [Range]. This, however, is dependent on the functionality the iterator provides. For
-example, a filtering iterator would consume a number Key-Value pairs which do not meets its criteria before `seek`
+example, a filtering iterator would consume a number Key-Value pairs which do not meet its criteria before `seek`
returns. The important condition for `seek` to meet is that this Iterator should be ready to return the first Key-Value
pair, or none if no such pair is available, when the method returns. The Key-Value pair would be returned by `getTopKey`
and `getTopValue`, respectively, and `hasTop` should return a boolean denoting whether or not there is
@@ -322,7 +322,7 @@ values will be grouped, insert mutations with those fields as the key, and confi
the table with a combining iterator that supports the summarizing operation
desired.
-The only restriction on an combining iterator is that the combiner developer
+The only restriction on a combining iterator is that the combiner developer
should not assume that all values for a given key have been seen, since new
mutations can be inserted at anytime. This precludes using the total number of
values in the aggregation such as when calculating an average, for example.
@@ -332,7 +332,7 @@ feature vectors for use in machine learning algorithms. For example, many
algorithms such as k-means clustering, support vector machines, anomaly detection,
etc. use the concept of a feature vector and the calculation of distance metrics to
learn a particular model. The columns in an Accumulo table can be used to efficiently
-store sparse features and their weights to be incrementally updated via the use of an
+store sparse features and their weights to be incrementally updated via the use of a
combining iterator.
## Best practices
diff --git a/_docs-2/development/sampling.md b/_docs-2/development/sampling.md
index 79bd28df..df504271 100644
--- a/_docs-2/development/sampling.md
+++ b/_docs-2/development/sampling.md
@@ -12,7 +12,7 @@ placed in the sample data is configurable per table.
This feature can be used for query estimation and optimization. For an example
of estimation, assume an Accumulo table is configured to generate a sample
-containing one millionth of a tables data. If a query is executed against the
+containing one millionth of the table's data. If a query is executed against the
sample and returns one thousand results, then the same query against all the
data would probably return a billion results. A nice property of having
Accumulo generate the sample is that its always up to date. So estimations
diff --git a/_docs-2/development/summaries.md b/_docs-2/development/summaries.md
index 044c835d..5bf0b2b4 100644
--- a/_docs-2/development/summaries.md
+++ b/_docs-2/development/summaries.md
@@ -7,7 +7,7 @@ order: 6
## Overview
Accumulo has the ability to generate summary statistics about data in a table
-using user defined functions. Currently these statistics are only generated for
+using user defined functions. Currently, these statistics are only generated for
data written to files. Data recently written to Accumulo that is still in
memory will not contribute to summary statistics.
@@ -147,11 +147,11 @@ visibilities that were not counted.
tooMany = 4
```
-Another summarizer is configured below that tracks the number of deletes. Also
+Another summarizer is configured below that tracks the number of deletes. Also,
a compaction strategy that uses this summary data is configured. The
`TooManyDeletesCompactionStrategy` will force a compaction of the tablet when
the ratio of deletes to non-deletes is over 25%. This threshold is
-configurable. Below a delete is added and its reflected in the statistics. In
+configurable. Below a delete is added and it's reflected in the statistics. In
this case there is 1 delete and 10 non-deletes, not enough to force a
compaction of the tablet.
diff --git a/_docs-2/getting-started/clients.md b/_docs-2/getting-started/clients.md
index f208bfb1..50342292 100644
--- a/_docs-2/getting-started/clients.md
+++ b/_docs-2/getting-started/clients.md
@@ -54,7 +54,7 @@ of the following methods:
AccumuloClient client = Accumulo.newClient().from(props).build();
```
-If an [accumulo-client.properties] file or a Java Properties object is used to create a [AccumuloClient], the following
+If an [accumulo-client.properties] file or a Java Properties object is used to create an [AccumuloClient], the following
[client properties][client-props] must be set:
* [instance.name] - Name of Accumulo instance to connect to
@@ -69,7 +69,7 @@ If an [accumulo-client.properties] file or a Java Properties object is used to c
| kerberos | Path to Kerberos keytab | /path/to/keytab |
| Authentication token class | Base64 encoded token | AAAAGh+LCAAAAAAAAAArTk0uSi0BAOXoolwGAAAA |
-If a token class is used for `auth.type`, you can create create a Base64 encoded token using the `accumulo create-token` command.
+If a token class is used for `auth.type`, you can create a Base64 encoded token using the `accumulo create-token` command.
```
$ accumulo create-token
@@ -82,7 +82,7 @@ auth.token = AAAAGh+LCAAAAAAAAAArTk0uSi0BAOXoolwGAAAA
# Authentication
-When creating a [AccumuloClient], the user must be authenticated using one of the following
+When creating an [AccumuloClient], the user must be authenticated using one of the following
implementations of [AuthenticationToken] below:
1. [PasswordToken] is the must commonly used implementation.
@@ -155,11 +155,11 @@ absence. For example a conditional mutation can require that column A is
absent inorder to be applied. Iterators can be applied when checking
conditions. Using iterators, many other operations besides equality and
absence can be checked. For example, using an iterator that converts values
-less than 5 to 0 and everything else to 1, its possible to only apply a
+less than 5 to 0 and everything else to 1, it's possible to only apply a
mutation when a column is less than 5.
In the case when a tablet server dies after a client sent a conditional
-mutation, its not known if the mutation was applied or not. When this happens
+mutation, it's not known if the mutation was applied or not. When this happens
the [ConditionalWriter] reports a status of UNKNOWN for the ConditionalMutation.
In many cases this situation can be dealt with by simply reading the row again
and possibly sending another conditional mutation. If this is not sufficient,
@@ -194,7 +194,7 @@ Durability can be set in multiple ways:
```
root@uno> config -t mytable -s table.durability=sync
```
-3. When creating a [AccumuloClient], the default durability can be overridden using `withBatchWriterConfig()`
+3. When creating an [AccumuloClient], the default durability can be overridden using `withBatchWriterConfig()`
or by setting [batch.writer.durability] in [accumulo-client.properties].
4. When a BatchWriter or ConditionalWriter is created, the durability settings above will be overridden
by the `BatchWriterConfig` that is passed in.
@@ -266,7 +266,7 @@ columns, it is possible that you will only see two of those modifications.
With the isolated scanner either all three of the changes are seen or none.
The [IsolatedScanner] buffers rows on the client side so a large row will not
-crash a tablet server. By default rows are buffered in memory, but the user
+crash a tablet server. By default, rows are buffered in memory, but the user
can easily supply their own buffer if they wish to buffer to disk when rows are
large.
diff --git a/_docs-2/getting-started/design.md b/_docs-2/getting-started/design.md
index 2e6170db..f16e05c0 100644
--- a/_docs-2/getting-started/design.md
+++ b/_docs-2/getting-started/design.md
@@ -143,7 +143,7 @@ ingest and query load is balanced across the cluster.
When a write arrives at a TabletServer it is written to a Write-Ahead Log and
then inserted into a sorted data structure in memory called a MemTable. When the
MemTable reaches a certain size, the TabletServer writes out the sorted
-key-value pairs to a file in HDFS called an [RFile](#rfile)). This process is
+key-value pairs to a file in HDFS called an [RFile](#rfile). This process is
called a minor compaction. A new MemTable is then created and the fact of the
compaction is recorded in the Write-Ahead Log.
@@ -182,7 +182,7 @@ for more information.
## Splitting
When a table is created it has one tablet. As the table grows its initial
-tablet eventually splits into two tablets. Its likely that one of these
+tablet eventually splits into two tablets. It's likely that one of these
tablets will migrate to another tablet server. As the table continues to grow,
its tablets will continue to split and be migrated. The decision to
automatically split a tablet is based on the size of a tablets files. The
diff --git a/_docs-2/getting-started/features.md b/_docs-2/getting-started/features.md
index c2c5ba01..d3c099b8 100644
--- a/_docs-2/getting-started/features.md
+++ b/_docs-2/getting-started/features.md
@@ -32,7 +32,7 @@ as `(A&B)|C`) and authorizations are sets of strings (such as `{C,D}`).
[Constraints]({% durl getting-started/table_configuration#constraints %}) are configurable
conditions where table writes are rejected. Constraints are written in Java and configurable
-on a per table basis.
+on a per-table basis.
### Sharding
@@ -156,9 +156,9 @@ can become quite large. When the index is large, a lot of memory is consumed and
files take a long time to open. To avoid this problem, RFiles have a
multi-level index tree. Index blocks can point to other index blocks or data
blocks. The entire index never has to be resident, even when the file is
-written. When an index block exceeds the configurable size threshold, its
+written. When an index block exceeds the configurable size threshold, it's
written out between data blocks. The size of index blocks is configurable on a
-per table basis.
+per-table basis.
### Binary search in RFile blocks
@@ -272,7 +272,7 @@ plugins in a stable manner.
### Balancer
Users can provide a balancer plugin that decides how to distribute tablets
-across a table. These plugins can be provided on a per table basis. This is
+across a table. These plugins can be provided on a per-table basis. This is
useful for ensuring a particular table's tablets are placed optimally for
tables with special query needs. The default balancer randomly spreads each
table's tablets across the cluster. It takes into account where a tablet was
diff --git a/_docs-2/getting-started/glossary.md b/_docs-2/getting-started/glossary.md
index 345c106b..146e7d4a 100644
--- a/_docs-2/getting-started/glossary.md
+++ b/_docs-2/getting-started/glossary.md
@@ -118,7 +118,7 @@ a distinct set of tablets at any given time, but the tablets may be hosted by
different servers over time.
timestamp
-: > the portion of the key that controls versioning. Otherwise identical keys
+: > the portion of the key that controls versioning. Otherwise, identical keys
with differing timestamps are considered to be versions of a single
*cell*. Accumulo can be configured to keep the *N* newest
versions of each *cell*. When a deletion entry is inserted, it deletes
diff --git a/_docs-2/getting-started/quickstart.md b/_docs-2/getting-started/quickstart.md
index 567bf47d..8876d8dc 100644
--- a/_docs-2/getting-started/quickstart.md
+++ b/_docs-2/getting-started/quickstart.md
@@ -80,7 +80,7 @@ server, manager, monitor, etc). Follow these steps to set it up:
to `false`.
2. Set {% plink instance.volumes %} to HDFS location where Accumulo will store
- data. If your namenode is running at 192.168.1.9:8020 and you want to store
+ data. If your namenode is running at 192.168.1.9:8020, and you want to store
data in `/accumulo` in HDFS, then set {% plink instance.volumes %} to
`hdfs://192.168.1.9:8020/accumulo`.
@@ -181,7 +181,7 @@ started.
### Run individual Accumulo services
-Start individual Accumulo processes (tserver, master, monitor, etc) as a
+Start individual Accumulo processes (tserver, master, monitor, etc.) as a
background service using the example accumulo-service script followed by the
service name. For example, to start only the tserver, run:
@@ -228,7 +228,7 @@ file contains sections that should be configured with a list of node names in ya
all nodes where compactors should run.
The Accumulo, Hadoop, and Zookeeper software should be present at the same
-location on every node. Also the files in the `conf` directory must be copied to
+location on every node. Also, the files in the `conf` directory must be copied to
every node. There are many ways to replicate the software and configuration, two
possible tools that can help replicate software and/or config are [pdcp] and
[prsync].
diff --git a/_docs-2/getting-started/table_configuration.md b/_docs-2/getting-started/table_configuration.md
index 0044790f..385626d6 100644
--- a/_docs-2/getting-started/table_configuration.md
+++ b/_docs-2/getting-started/table_configuration.md
@@ -78,7 +78,7 @@ com.test.ExampleConstraint=1
com.test.AnotherConstraint=2
```
-Currently there are no general-purpose constraints provided with the Accumulo
+Currently, there are no general-purpose constraints provided with the Accumulo
distribution. New constraints can be created by writing a Java class that implements
the [Constraint][constraint] interface.
@@ -191,9 +191,9 @@ user@myinstance mytable> config -t mytable -s table.iterator.minc.vers.opt.maxVe
user@myinstance mytable> config -t mytable -s table.iterator.majc.vers.opt.maxVersions=3
```
-When a table is created, by default its configured to use the
+When a table is created, by default it's configured to use the
VersioningIterator and keep one version. A table can be created without the
-VersioningIterator with the -ndi option in the shell. Also the Java API
+VersioningIterator with the -ndi option in the shell. Also, the Java API
has the following method
```java
@@ -205,7 +205,7 @@ client.tableOperations.create(String tableName, boolean limitVersion);
Accumulo 1.2 introduces the concept of logical time. This ensures that timestamps
set by Accumulo always move forward. This helps avoid problems caused by
TabletServers that have different time settings. The per tablet counter gives unique
-one up time stamps on a per mutation basis. When using time in milliseconds, if
+one up time stamps on a per-mutation basis. When using time in milliseconds, if
two things arrive within the same millisecond then both receive the same
timestamp. When using time in milliseconds, Accumulo set times will still
always move forward and never backwards.
@@ -349,7 +349,7 @@ See {% dlink administration/compaction %}
Accumulo will balance and distribute tables across servers. Before a
table gets large, it will be maintained as a single tablet on a single
server. This limits the speed at which data can be added or queried
-to the speed of a single node. To improve performance when the a table
+to the speed of a single node. To improve performance when a table
is new, or small, you can add split points and generate new tablets.
In the shell:
@@ -448,7 +448,7 @@ flush option is present and is enabled by default in the shell. If the flush
option is not enabled, then any data the source table currently has in memory
will not exist in the clone.
-A cloned table copies the configuration of the source table. However the
+A cloned table copies the configuration of the source table. However, the
permissions of the source table are not copied to the clone. After a clone is
created, only the user that created the clone can read and write to it.
@@ -525,7 +525,7 @@ root@a14 cic>
## Exporting Tables
Accumulo supports exporting tables for the purpose of copying tables to another
-cluster. Exporting and importing tables preserves the tables configuration,
+cluster. Exporting and importing tables preserves the tables' configuration,
splits, and logical time. Tables are exported and then copied via the hadoop
`distcp` command. To export a table, it must be offline and stay offline while
`distcp` runs. Staying offline prevents files from being deleted during the process.
diff --git a/_docs-2/security/authorizations.md b/_docs-2/security/authorizations.md
index 31aa2bbf..55854315 100644
--- a/_docs-2/security/authorizations.md
+++ b/_docs-2/security/authorizations.md
@@ -24,7 +24,7 @@ preserving data confidentiality.
### Writing labeled data
When [writing data to Accumulo]({% durl getting-started/clients#writing-data %}), users can
-specify a security label for each value by passing a [ColumnVisibilty] to the [Mutation].
+specify a security label for each value by passing a [ColumnVisibility] to the [Mutation].
```java
try (BatchWriter writer = client.createBatchWriter("employees")) {
@@ -42,7 +42,7 @@ value the label is associated with. The set of tokens required can be specified
syntax that supports logical AND `&` and OR `|` combinations of terms, as
well as nesting groups `()` of terms together.
-Each term is comprised of one to many alpha-numeric characters, hyphens, underscores or
+Each term is comprised of one to many alphanumeric characters, hyphens, underscores or
periods. Optionally, each term may be wrapped in quotation marks
which removes the restriction on valid characters. In quoted terms, quotation marks
and backslash characters can be used as characters in the term by escaping them
diff --git a/_docs-2/security/kerberos.md b/_docs-2/security/kerberos.md
index bb80c580..48a12fca 100644
--- a/_docs-2/security/kerberos.md
+++ b/_docs-2/security/kerberos.md
@@ -22,13 +22,13 @@ which allow cross-language integration with Kerberos for authentication. GSSAPI,
the generic security service application program interface, is a standard which
Kerberos implements. In the Java programming language, the language itself also implements
GSSAPI which is leveraged by other applications, like Apache Hadoop and Apache Thrift.
-SASL, simple authentication and security layer, is a framework for authentication and
+SASL, simple authentication and security layer, is a framework for authentication
and security over the network. SASL provides a number of mechanisms for authentication,
one of which is GSSAPI. Thus, SASL provides the transport which authenticates
using GSSAPI that Kerberos implements.
Kerberos is a very complicated software application and is deserving of much
-more description than can be provided here. An [explain like I`m 5](https://www.roguelynn.com/words/explain-like-im-5-kerberos/)
+more description than can be provided here. An [explain like I'm 5](https://www.roguelynn.com/words/explain-like-im-5-kerberos/)
blog post is very good at distilling the basics, while [MIT Kerberos's project page](https://web.mit.edu/kerberos/)
contains lots of documentation for users or administrators. Various Hadoop "vendors"
also provide free documentation that includes step-by-step instructions for
@@ -187,7 +187,7 @@ to granting Authorizations and Permissions to new users.
#### Administrative User
Out of the box (without Kerberos enabled), Accumulo has a single user with administrative permissions "root".
-This users is used to "bootstrap" other users, creating less-privileged users for applications using
+This user is used to "bootstrap" other users, creating less-privileged users for applications using
the system. In Kerberos, to authenticate with the system, it's required that the client presents Kerberos
credentials for the principal (user) the client is trying to authenticate as.
@@ -243,7 +243,7 @@ it can only connect to Accumulo as itself. Impersonation, in this context, refer
of the proxy to authenticate to Accumulo as itself, but act on behalf of an Accumulo user.
Accumulo supports basic impersonation of end-users by a third party via static rules in
-`accumulo.properties`. These two properties are semi-colon separated properties which are aligned
+`accumulo.properties`. These two properties are semicolon separated properties which are aligned
by index. This first element in the user impersonation property value matches the first element
in the host impersonation property value, etc.
@@ -411,7 +411,7 @@ JVM to each YARN task is secure, even in multi-tenant instances.
### Debugging
-**Q**: I have valid Kerberos credentials and a correct client configuration file but
+**Q**: I have valid Kerberos credentials and a correct client configuration file, but
I still get errors like:
```
diff --git a/_docs-2/security/on-disk-encryption.md b/_docs-2/security/on-disk-encryption.md
index 1314b6c4..bf9a2c03 100644
--- a/_docs-2/security/on-disk-encryption.md
+++ b/_docs-2/security/on-disk-encryption.md
@@ -122,7 +122,7 @@ even with the crypto service enabled.
For queries, data is decrypted when read from RFiles and cached in memory. This means that data is unencrypted in memory
while Accumulo is running. Depending on the situation, this also means that some data can be printed to logs. A stacktrace being logged
during an exception is one example. Accumulo developers have made sure not to expose data protected by authorizations during logging, but
-its the additional data that gets encrypted on-disk that could be exposed in a log file.
+it's the additional data that gets encrypted on-disk that could be exposed in a log file.
#### Bulk Import
diff --git a/_docs-2/security/wire-encryption.md b/_docs-2/security/wire-encryption.md
index 60001383..8c2eced4 100644
--- a/_docs-2/security/wire-encryption.md
+++ b/_docs-2/security/wire-encryption.md
@@ -119,6 +119,6 @@ keytool -import -trustcacerts -alias server-crt -file server.crt -keystore serve
```
The `server.jks` file is the Java keystore containing the certificate for a given host. The above
-methods are equivalent whether the certificate is generate for an Accumulo server or a client.
+methods are equivalent whether the certificate is generated for an Accumulo server or a client.
[clients]: {{ page.docs_baseurl }}/getting-started/clients#creating-an-accumulo-client
diff --git a/_docs-2/troubleshooting/advanced.md b/_docs-2/troubleshooting/advanced.md
index 1d63e115..b2b24b30 100644
--- a/_docs-2/troubleshooting/advanced.md
+++ b/_docs-2/troubleshooting/advanced.md
@@ -11,7 +11,7 @@ order: 2
The primary reason a tablet server loses its lock is that it has been pushed into swap.
A large java program (like the tablet server) may have a large portion
-of its memory image unused. The operation system will favor pushing
+of its memory image unused. The operating system will favor pushing
this allocated, but unused memory into swap so that the memory can be
re-used as a disk buffer. When the java virtual machine decides to
access this memory, the OS will begin flushing disk buffers to return that
@@ -116,7 +116,7 @@ Ensure your client has adequate memory and is not being swapped out to disk.
**I had disastrous HDFS failure. After bringing everything back up, several tablets refuse to go online.**
Data written to tablets is written into memory before being written into indexed files. In case the server
-is lost before the data is saved into a an indexed file, all data stored in memory is first written into a
+is lost before the data is saved into an indexed file, all data stored in memory is first written into a
write-ahead log (WAL). When a tablet is re-assigned to a new tablet server, the write-ahead logs are read to
recover any mutations that were in memory when the tablet was last hosted.
@@ -195,7 +195,7 @@ The directory structure in HDFS for tables will follow the general structure:
/accumulo/tables/2/t-00001/A000007.rf
If files under `/accumulo/tables` are corrupt, the best course of action is to
-recover those files in hdsf see the section on HDFS. Once these recovery efforts
+recover those files in hdfs see the section on HDFS. Once these recovery efforts
have been exhausted, the next step depends on where the missing file(s) are
located. Different actions are required when the bad files are in Accumulo data
table files or if they are metadata table files.
@@ -232,7 +232,7 @@ before creating the new instance. You will not be able to use RestoreZookeeper
because the table names and references are likely to be different between the
original and the new instances, but it can serve as a reference.
-If the files cannot be recovered, replace corrupt data files with a empty
+If the files cannot be recovered, replace corrupt data files with an empty
rfiles to allow references in the metadata table and in the tablet servers to be
resolved. Rebuild the metadata table if the corrupt files are metadata files.
@@ -245,7 +245,7 @@ WAL file, never being able to succeed.
In the cases where the WAL file's original contents are unrecoverable or some degree
of data loss is acceptable (beware if the WAL file contains updates to the Accumulo
-metadata table!), the following process can be followed to create an valid, empty
+metadata table!), the following process can be followed to create a valid, empty
WAL file. Run the following commands as the Accumulo unix user (to ensure that
the proper file permissions in HDFS)
diff --git a/_docs-2/troubleshooting/basic.md b/_docs-2/troubleshooting/basic.md
index 53c4bb1f..1b756ba2 100644
--- a/_docs-2/troubleshooting/basic.md
+++ b/_docs-2/troubleshooting/basic.md
@@ -14,7 +14,7 @@ these remote computers writes down events as they occur, into a local
file. By default, this is defined in `conf/accumulo-env.sh` as `ACCUMULO_LOG_DIR`.
Look in the `$ACCUMULO_LOG_DIR/tserver*.log` file. Specifically, check the end of the file.
-**The tablet server did not start and the debug log does not exists! What happened?**
+**The tablet server did not start and the debug log does not exist! What happened?**
When the individual programs are started, the stdout and stderr output
of these programs are stored in `.out` and `.err` files in
@@ -128,7 +128,7 @@ undesirable to ssh to every node in the cluster to ensure that all hosts are run
**My process died again. Should I restart it via `cron` or tools like `supervisord`?**
-A repeatedly dying Accumulo process is a sign of a larger problem. Typically these problems are due to a
+A repeatedly dying Accumulo process is a sign of a larger problem. Typically, these problems are due to a
misconfiguration of Accumulo or over-saturation of resources. Blind automation of any service restart inside of Accumulo
is generally an undesirable situation as it is indicative of a problem that is being masked and ignored. Accumulo
processes should be stable on the order of months and not require frequent restart.
@@ -146,7 +146,7 @@ Use the [rfile-info] tool on a representative file to get some idea
of the visibilities in the underlying data.
Note that the use of `rfile-info` is an administrative tool and can only
-by used by someone who can access the underlying Accumulo data. It
+be used by someone who can access the underlying Accumulo data. It
does not provide the normal access controls in Accumulo.
## Ingest
diff --git a/_docs-2/troubleshooting/system-metadata-tables.md b/_docs-2/troubleshooting/system-metadata-tables.md
index 4145016c..2cee189a 100644
--- a/_docs-2/troubleshooting/system-metadata-tables.md
+++ b/_docs-2/troubleshooting/system-metadata-tables.md
@@ -74,7 +74,7 @@ Let's decode this little session:
lock.
* `srv:time [] M1373998392323` -
- This indicates the time time type (`M` for milliseconds or `L` for logical) and the timestamp of the most recently written key in this tablet. It is used to ensure automatically assigned key timestamps are strictly increasing for the tablet, regardless of the tablet server's system time.
+ This indicates the time type (`M` for milliseconds or `L` for logical) and the timestamp of the most recently written key in this tablet. It is used to ensure automatically assigned key timestamps are strictly increasing for the tablet, regardless of the tablet server's system time.
* `~tab:~pr [] \x00` -
The end-row marker for the previous tablet (prev-row). The first byte
diff --git a/_docs-2/troubleshooting/tools.md b/_docs-2/troubleshooting/tools.md
index aca3733a..0ccb3ef0 100644
--- a/_docs-2/troubleshooting/tools.md
+++ b/_docs-2/troubleshooting/tools.md
@@ -152,7 +152,7 @@ every tablet matches, and the start and stop for the table is empty:
## RemoveEntriesForMissingFiles
-If your Hadoop cluster has a lost a file due to a NameNode failure, you can remove the
+If your Hadoop cluster has a lost a file due to a NameNode failure, you can remove
the file reference using `RemoveEntriesForMissingFiles`. It will check every file reference
and ensure that the file exists in HDFS. Optionally, it will remove the reference:
@@ -339,7 +339,7 @@ sorted by the id.
## mode: print property mappings
-With Accumulo version 2.1, the storage of properties in ZooKeeper has changed and the properties are not direclty
+With Accumulo version 2.1, the storage of properties in ZooKeeper has changed and the properties are not directly
readable with the ZooKeeper zkCli utility. The properties can be listed in an Accumulo shell with the `config` command.
However, if a shell is not available, this utility `zoo-info-viewer` can be used instead.