其中最主要的部分是kubesql-connector。presto插件开发指南可以参考https://prestodb.io/docs/current/develop.html。我没有选择从零开始，而是基于已有的localfile插件https://github.com/prestodb/presto/tree/0.234.2/presto-local-file进行的开发。如何进行presto的插件开发，后面我再写文章来解读。
由于所有数据都缓存在内存中，因此几乎无磁盘需求。但是也需要根据集群的规模来提供较大的内存。
以pod数据为例，pod中主要数据分成三部分，metadata，spec和status。
metadata中比较难以处理的部分是label和annotation。我将label这个map进行展平，每个key都作为一列。比如
labels: app: mysql owner: xxx我使用labels作为前缀，拼合labels里面的key作为列名。从而得到两条数据为：
labels.app: mysql labels.owner: xxx对于pod A存在app的label但是pod B并没有该标签，则对于pod B来说，该列labels.app的值则为null。
类似的annotations也是类似的处理方式。从而让annotations也就可以成为可以用于筛选pod的条件了。
对于spec来说，最大的困难在于containers的处理。因为一个pod里面可能有若干个containers，因此我直接将containers作为一张新的表。同时在containers表里增加一个uid的列，用来表明该行数据来自于哪个pod。containers里面的字段也对应都加入到containers表中。containers中比较重要的关于资源的如request和limit，我直接使用requests.作为前缀，拼合resource作为列名。比如requests.cpu，requests.memory等。这里cpu的单独处理为double类型，单位为核，比如100m这里会转化为0.1。内存等则为bigint，单位为B。
对于status中，比较难于处理的是conditions和containerStatus。conditions是一个列表，但是每个condition的type不相同。因此我将type作为前缀，用来生成conditon的列名。比如：
conditions: - lastProbeTime: null lastTransitionTime: 2020-04-22T09:03:10Z status: "True" type: Ready - lastProbeTime: null lastTransitionTime: 2020-04-22T09:03:10Z status: "True" type: ContainersReady那么在pod表中，我对应可以得到这些列：
Column Type Extra Commentcontainersready.lastprobetime timestamp
containersready.lasttransitiontime timestamp
containersready.message varchar
containersready.reason varchar
containersready.status varchar
ready.lastprobetime timestamp
ready.lasttransitiontime timestamp
ready.message varchar
ready.reason varchar
ready.status varchar
这样我就可以通过"ready.status" = "True" 来筛选condition里type为ready且status为True的pod了。
containerStatus因为与containers一一对应，因此我将containerStatus合并到containers表里，并且根据container name一一对应起来。
后记本次重构后kubesql我直接发布为1.0.0版本，并且已经在日常使用了。且借助于内存和presto的高性能，我测试过5万pod的集群，查询时间为毫秒级。目前暂未发现明显的bug。大家有发现bug或者新的feature也可以提issue给我。我后期也会再维护该项目。
因为目前只有pods和nodes资源，相对于k8s庞大的资源来说，还只是冰山一角。但是增加每个资源要加入相当数量的代码。我也在考虑如何使用openapi的swagger描述来自动生成代码。
部署上现在是用docker来部署，马上也会增加kubernetes的部署方式，这样会更加便捷。
同时我在考虑，在未来，让presto的每个worker负责一个集群的cache。这样一个presto集群可以查询所有的k8s集群的信息。该功能还需要再做设计和考虑。