feat(java): introduce Compact Row Codec

[stevenschlansker]

What does this PR do?

Introduce alternate "compact" row encoding that better uses knowledge of fixed-size types and sacrifices alignment to save space.

Introduce new Builder pattern to avoid explosion of Encoders static methods as more features are added to row format.

Optimizations include:

• struct stores fixed-size fields (e.g. Int128. FixedSizeBinary) inline in fixed-data area without offset + size
• struct of all fixed-sized fields is itself considered fixed-size to store in other struct or array
• struct skips null bitmap if all fields are non-nullable
• struct sorts fields by fixed-size for best-effort (but not guaranteed) alignment
• struct can use less than 8 bytes for small data (int, short, etc)
• struct null bitmap stored at end of struct to borrow alignment padding if possible
• array stores fixed-size fields inline in fixed-data area without offset+size
• array header uses 4 bytes for size (since Collection and array are only int-sized) and leaves remaining 4 bytes for start of null bitmap

Fixups include:

• toString better handles varbinary / fixed-binary (hex dump of first 256 bytes)
• start making Javadoc for row format

Compromises:

• less alignment could increase access time, but this is opt-in. and I think on modern processors it is not such a big deal.
• increased complexity of offset lookup, try to pre-compute in an array when possible and use StableValue when it is GA

Not compatible with existing row format.

Related issues

Fixes #2337

Does this PR introduce any user-facing change?

New API for new Compact codec. Existing codec unchanged.

[stevenschlansker]

Hi @chaokunyang , I believe this PR is ready for review now. No rush, I know it is a lot to go through. Happy to explain or change anything that does not make sense.

We run this now in our testing environment successfully with about a 30% - 50% space savings on our datasets. Will be taking compact codec to production over the coming weeks.

[chaokunyang]

@stevenschlansker Great! 30% - 50% space savings is a huge gain! I will review this PR ASAP, and release it in 0.13.0

[chaokunyang]

this looks like a method return boolean, how abouting naming it as nullabilityBitmapOffset/nullBitmapOffset

[chaokunyang]

Will the name Encoding better align with Encoder?

[chaokunyang]

LGTM overall, I left some minor comments. And could we also add some documents to row_format_guide.md in later PR.

Another thing for compact is to inline string. For string less that 7 bytes, we can put it into fixed-size region. Many string are less than 7 bytes, I think this can also brings some space savings

[chaokunyang]

Is it possible to merge bareEncode and encode into one method?

[chaokunyang]

this is only called on map/struct/array, merge into one method and use a branch don't introduce lots of runtime cost, but we can make the interface more simple

[chaokunyang]

Could we add some documents to clarify the situations when we need to use this and the difference between this and BaseMapEncoder

[chaokunyang]

BaseXXX looks like an abstract parent class, could we use a different name?

[chaokunyang]

How about BinaryMapEncoder to relfect the relationship with BinaryRow, BinaryArray naming in codebase

similiar naming for other encoders

[chaokunyang]

And since we have different kinds of encoder for same type, we'd better to add some javadoc to document the distinctions

[stevenschlansker]

Thank you for your review, I will make changes in the coming days.