Most integrations working with Kudu will eventually need to access partition information when scanning so that data locality can be preserved.
We should provide an API which takes scan parameters (start/stop primary key and predicates) and returns a set of scan descriptors, each of which is associated with a data location. Partition pruning should be built in to this API so that each integration does not have to reinvent that particular wheel.
The API should also allow a descriptor to be split into further pieces, so that higher-level integrations can increase parallelism without client-side filtering.
Finally, the descriptors should be serializable so that they can be passed between the C++ and Java clients (mostly to allow Impala to construct the query plan in Java and execute it in C++).