Currently both the catalogd and the impalad use the same implementation classes for catalog objects such as Table, Function, HdfsPartition, etc. Those implementations are fairly tightly coupled to the current design of the catalog.
For the new catalog design, it will be easier to have a new set of classes rather than attempting to reuse or modify the existing ones for a few reasons:
- the existing ones are mutable in the catalogd and thus have to worry quite a bit about synchronization, whereas the new design uses immutable catalog objects
- the existing ones assume "all or nothing" loading whereas the new design involves lazy-loading relevant bits of info
- we don't want to destabilize the existing implementation, so we want to avoid any nontrivial modifications of the existing code.
Extracting a set of interfaces such as 'FeTable', 'FeDb', etc, will help decouple the frontend from the particular catalog implementation.