anchor.diff:  and <<known-limitations,known limitations>> with regard to schema design.
   
   [[column-design]]
  +== Column Design
   
   A Kudu Table consists of one or more columns, each with a predefined type.
   Columns that are not part of the primary key may optionally be nullable.
  
positive.code: after creation, so you must design your partition schema ahead of time to ensure
  a sufficient number of tablets are created.
  
  [[range-partitioning]
  === Range Partitioning
  
  Range partitioning distributes rows into tablets using a totally-ordered
  
negative.code: * binary
  
  Kudu takes advantage of strongly-typed columns and a columnar on-disk storage
  format to provide efficient encoding and serialization. To utilize these
  features, columns should be specified as the appropriate type, as opposed to
  simulating a 'schemaless' table using string or binary columns for data which
  may otherwise be structured. In addition to encoding, Kudu optionally allows
  compression to be specified on a per-column basis.
  
  [[encoding]]
  === Column Encoding
  
  Each column in a Kudu table can be created with an encoding, based on the type
  of the column. Columns use plain encoding by default.
  
  .Encoding Types
  |===
  | Column Type        | Encoding
  | integer, timestamp | plain, bitshuffle, run length
  | float              | plain, bitshuffle
  | bool               | plain, dictionary, run length
  | string, binary     | plain, prefix, dictionary
  |===
  
  [[plain]]
  Plain Encoding:: stores data in its natural format. For example, int32 values
  are stored as fixed-size 32 bit little endian integers.
  
  [[bitshuffle]]
  Bitshuffle Encoding:: rearranges data by storing the most significant bit of
  every value, followed by the second most significant bit of every value, and so
  on. Finally, the result is LZ4 compressed. Bitshuffle is a good choice for
  columns that have many repeated values, or values that change by small amounts
  when sorted by primary key. The
  https://github.com/kiyo-masui/bitshuffle[bitshuffle] project has a good
  overview of performance and use cases.
  
  [[run-length]]
  Run Length Encoding:: compresses runs, or consecutive repeated values, in a
  column by storing only the value and the count. Run length encoding is effective
  for columns that have many consecutive repeated values when sorted by primary
  key.
  
  [[dictionary]]
  Dictionary Encoding:: builds a dictionary of unique values and encodes each
  column value as its corresponding index in the dictionary. Dictionary encoding
  is effective for columns with low cardinality. If the column values are unable
  to be compressed because the number of unique values is too high, Kudu will
  automatically fall back to plain encoding.
  
  [[prefix]]
  Prefix Encoding:: compresses common prefixes in consecutive column values. Prefix
  encoding can be effictive for values that share common prefixes, or the first
  column of the primary key, since rows are sorted by primary key within tablets.
  
  [[compression]]
  === Column Compression
  
  Kudu allows per-column compression using LZ4, snappy, or zlib compression
  codecs. By default, columns are stored uncompressed. Consider using compression
  if reducing storage space is more important than raw scan performance. Every
  data set will compress differently, but in general LZ4 has the least effect on
  performance, while zlib will compress to smallest data sizes. Bitshuffle
  encoded columns are always LZ4 compressed.
  
  [[primary-keys]]
  == Primary Keys
  
  Each Kudu table must declare a primary key comprised of one or more columns.
  Primary key columns must be non-nullable, and may not be a boolean or
  