anchor.diff:  instance, you must use parcels and you should use the instructions provided in
   <<install_impala_kudu_parcels_side_by_side,procedure>>, rather than these instructions.
   
  -[install_impala_kudu_parcels]
  +[[install_impala_kudu_parcels]]
   === Installing the Impala_Kudu Service Using Parcels
   
  -[install_impala_kudu_parcels_side_by_side]
  +[[install_impala_kudu_parcels_side_by_side]]
   ==== Manual Installation
   
   Manual installation of Impala_Kudu is only supported where there is no other Impala
  
positive.code: - View the link:http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/impala_langref.html
  [Impala SQL reference].
  - Read about Impala internals or learn how to contribute to Impala on the link:https://github.com/cloudera/Impala/wiki[Impala Wiki].
  - Read about the native link:installation.html#view_api[Kudu APIs].
negative.code: All properties in the `TBLPROPERTIES` subclause are required, and the `kudu.key_columns`
  must contain at least one column.
  
  === Partitioning Tables
  
  Tables are partitioned into tablets according to a partition schema on the primary
  key columns. Each tablet is served by at least one tablet server. Ideally, a table
  should be split into tablets that are distributed across a number of tablet servers
  to maximize parallel operations. The details of the partitioning schema you use
  will depend entirely on the type of data you store and how you access it.
  
  Kudu currently has no mechanism for splitting or merging tablets after the table has
  been created. Until this feature has been implemented, you must provide a partition
  schema for your table when you create it. When designing your tables, consider using
  primary keys that will allow you to partition your table into tablets which grow
  at similar rates.
  
  You can partition your table using Impala's `DISTRIBUTE BY` keyword, which
  supports distribution by `RANGE` or `HASH`. The partition scheme can contain zero
  or more `HASH` definitions, followed by an optional `RANGE` definition. The `RANGE`
  definition can refer to one or more primary key columns.
  Examples of <<basic_partitioning,basic>> and <<advanced_partitioning, advanced>>
  partitioning are shown below.
  
  NOTE: Impala keywords, such as `group`, are enclosed by back-tick characters when
  they are used as identifiers, rather than as keywords.
  
  [[basic_partitioning]]
  ==== Basic Partitioning
  
  .`DISTRIBUTE BY RANGE`
  You can specify split rows for one or more primary key columns that contain integer
  or string values. Range partitioning in Kudu allows splitting a table based based
  on the lexicographic order of its primary keys. This allows you to balance parallelism
  in writes with scan efficiency.
  
  The split row does not need to exist. It defines an exclusive bound in the form of:
  `(START_KEY, SplitRow), [SplitRow, STOP_KEY)` In other words, the split row, if
  it exists, is included in the tablet after the split point. For instance, if you
  specify a split row `abc`, a row `abca` would be in the second tablet, while a row
  `abb` would be in the first.
  
  Suppose you have a table that has columns `state`, `name`, and `purchase_count`. The
  following example creates 50 tablets, one per US state.
  
  [NOTE]
  .Monotonically Increasing Values
  ====
  If you partition by range on a column whose values are monotonically increasing,
  the last tablet will grow much larger than the others. Additionally, all data
  being inserted will be written to a single tablet at a time, limiting the scalability
  of data ingest. In that case, consider distributing by `HASH` instead of, or in
  addition to, `RANGE`.
  ====
  
  [source,sql]
  ----
  CREATE TABLE customers (
    state STRING,
    name STRING,
    purchase_count int32,
  ) DISTRIBUTE BY RANGE(state)
  SPLIT ROWS(('al'), ('ak'), ('ar'), .., ('wv'), ('wy'))
  TBLPROPERTIES(
  'storage_handler' = 'com.cloudera.kudu.hive.KuduStorageHandler',
  'kudu.table_name' = 'customers',
  'kudu.master_addresses' = 'kudu-master.example.com:7051',
  'kudu.key_columns' = 'state, name'
  );
  ----
  
  [[distribute_by_hash]]
  .`DISTRIBUTE BY HASH`
  
  Instead of distributing by an explicit range, or in combination with range distribution,
  you can distribute into a specific number of 'buckets' by hash. You specify the primary
  key columns you want to partition by, and the number of buckets you want to use. Rows are
  distributed by hashing the specified key columns. Assuming that the values being
  hashed do not themselves exhibit significant skew, this will serve to distribute
  the data evenly across buckets.
  
  You can specify multiple definitions, and you can specify definitions which
  use compound primary keys. However, one column cannot be mentioned in multiple hash
  definitions. Consider two columns, `a` and `b`:
  * icon:check[pro, role="green"] `HASH(a)`, `HASH(b)`
  * icon:check[pro, role="green"] `HASH(a,b)`
  * icon:times[pro, role="red"] `HASH(a), HASH(a,b)`
  
  NOTE: `DISTRIBUTE BY HASH` with no column specified is a shortcut to create the desired
  number of buckets by hashing all primary key columns.
  
  Hash partitioning is a reasonable approach if primary key values are evenly
  distributed in their domain and no data skew is apparent, such as timestamps or
  serial IDs.
  
  The following example creates 16 tablets by hashing the `id` column. A maximum of
  16 tablets can be written to in parallel. In this example, a query for a range of `sku` values
  is likely to need to read all 16 tablets, so this may not be the optimum schema for
  this table. See <<advanced_partitioning>> for an extended example.
  
  [source,sql]
  ----
  CREATE TABLE cust_behavior (
    id BIGINT,
    sku STRING,
    salary STRING,
    edu_level INT,
    usergender STRING,
    `group` STRING,
    city STRING,
    postcode STRING,
    last_purchase_price FLOAT,
    last_purchase_date BIGINT,
    category STRING,
    rating INT,
    fulfilled_date BIGINT
  )
  DISTRIBUTE BY HASH (id) INTO 16 BUCKETS
  TBLPROPERTIES(
  'storage_handler' = 'com.cloudera.kudu.hive.KuduStorageHandler',
  'kudu.table_name' = 'cust_behavior',
  'kudu.master_addresses' = 'kudu-master.example.com:7051',
  'kudu.key_columns' = 'id, sku'
  );
  ----
  
  
  [[advanced_partitioning]]
  ==== Advanced Partitioning
  
  You can use zero or more `HASH` definitions, followed by zero or one `RANGE` definitions
  to partition a table. Each definition can encompass one or more columns.
  While every possible distribution schema is out of the scope of this document, a few
  demonstrations follow.
  
  .`DISTRIBUTE BY RANGE` Using Compound Split Rows
  
  This example creates 100 tablets, two for each US state. Per state, the first tablet
  holds names starting with characters before 'm', and the second tablet holds names
  starting with `m-z`. At least 50 tablets (and up to 100) can be written to in parallel.
  A query for a range of names in a given state is likely to only need to read from
  one tablet, while a query for a range of names across every state will likely only
  read from 50 tablets.
  
  [source,sql]
  ----
  CREATE TABLE customers (
    state STRING,
    name STRING,
    purchase_count int32,
  ) DISTRIBUTE BY RANGE(state, name)
  SPLIT ROWS(('al', ''), ('al', 'm'), ('ak', ''), ('ak', 'm'), .., ('wy', ''), ('wy', 'm'))
  TBLPROPERTIES(
  'storage_handler' = 'com.cloudera.kudu.hive.KuduStorageHandler',
  'kudu.table_name' = 'customers',
  'kudu.master_addresses' = 'kudu-master.example.com:7051',
  'kudu.key_columns' = 'state, name'
  );
  ----
  
  ==== `DISTRIBUTE BY HASH` and `RANGE`
  
  Let's go back to the hashing example above. If you often query for a range of `sku`
  values, you can optimize the example by combining hash partitioning with range partitioning.
  The following example still creates 16 tablets, by first hashing the `id` column into 4
  buckets, and then applying range partitioning to split each bucket into four tablets,
  based upon the value of the `sku` string. At least four tablets (and possibly up to 16) can
  be written to in parallel, and when you query for a contiguous range of `sku` values, you have a
  good chance of only needing to read from 1/4 of the tablets to fulfill the query.
  
  [source,sql]
  ----
  CREATE TABLE cust_behavior (
    id BIGINT,
    sku STRING,
    salary STRING,
    edu_level INT,
    usergender STRING,
    `group` STRING,
    city STRING,
    postcode STRING,
    last_purchase_price FLOAT,
    last_purchase_date BIGINT,
    category STRING,
    rating INT,
    fulfilled_date BIGINT
  )
  DISTRIBUTE BY HASH (id) INTO 4 BUCKETS,
  RANGE (sku) SPLIT ROWS(('g'), ('o'), ('u'))
  TBLPROPERTIES(
  'storage_handler' = 'com.cloudera.kudu.hive.KuduStorageHandler',
  'kudu.table_name' = 'cust_behavior',
  'kudu.master_addresses' = 'kudu-master.example.com:7051',
  'kudu.key_columns' = 'id, sku'
  );
  ----
  
  .Multiple `DISTRIBUTE BY HASH` Definitions
  Again expanding the example above, suppose that the query pattern will be unpredictable,
  but you want to maximimize parallelism of writes. You can achieve even distribution
  across the entire primary key by hashing on both primary key columns.
  
  [source,sql]
  ----
  CREATE TABLE cust_behavior (
    id BIGINT,
    sku STRING,
    salary STRING,
    edu_level INT,
    usergender STRING,
    `group` STRING,
    city STRING,
    postcode STRING,
    last_purchase_price FLOAT,
    last_purchase_date BIGINT,
    category STRING,
    rating INT,
    fulfilled_date BIGINT
  )
  DISTRIBUTE BY HASH (id) INTO 4 BUCKETS, HASH (sku) INTO 4 BUCKETS
  TBLPROPERTIES(
  'storage_handler' = 'com.cloudera.kudu.hive.KuduStorageHandler',
  'kudu.table_name' = 'cust_behavior',
  'kudu.master_addresses' = 'kudu-master.example.com:7051',
  'kudu.key_columns' = 'id, sku'
  );
  ----
  
  The example creates 16 buckets. You could also use `HASH (id, sku) INTO 16 BUCKETS`.
  However, a scan for `sku` values would almost always impact all 16 buckets, rather
  than possibly being limited to 4.
  
  === Inserting A Row
  
  [source,sql]
  