【建议】增加存储（组表、集文件）元数据管理

[Jetol]

SPL极致性能需结合自己设计的组表和集文件存储方式，那么随着所有采集同步以及加工的数据都转化/生成组表，对组表/集文件（元数据）的管理目前是怎么操作的？是否有类似数据库的元数据管理那样，有专门存储所有组表元数据信息的地方，是否有相应的访问接口可以实时获取组表/集文件的信息（包括有哪些组表、具体某个组表的大小，该组表有哪些列，组表上面创建了哪些索引...）

[jbx1279]

SPL的思路和RDB不同，它是开放的计算体系，没有“库”的概念，只要能访问到的数据都能计算，无非是访问性能不同。组表和其它文本文件以及从RDB/NoSQL中读出来的数据，在计算功能上，并没什么本质不同。”有哪些组表“这个问题对SPL并没有意义，自己到文件系统下看就可以了，甚至网络文件系统以及远程对象存储也可。
至于组表的数据结构（以及索引），有函数可以读出来。大小之类的信息，问文件系统就可以了。

没有元数据，才会有开放性，这是个基本理念。这个体系做成云原生后，也非常轻，很容易做到serverless和弹性扩展。
后面会逐步提供一些方便的编辑与管理工具，但仍然是对着文件系统的，没有“库”。数据计算无处不在，不需要“库”这个概念。

[Jetol]

远程分布式对象（minIO）存储之后，试了使用file（）和httpFile（）读取函数出来数据都是乱码，是否有现成的读取分布式存储上面的组表的函数接口？请问能否研发新函数读取对象存储的组表数据；

[jbx1279]

file要求是文件系统的协议（POSIX的一部分）。httpfile就是HTTP的协议了。对象存储是它独特的协议，肯定不能直接用这个了。
对象存储目前还不直接支持，后续的外部库会支持S3等协议，把对象存储映射成一个文件对象，提供类似s3file这样的函数，之后再生成组表等动作都是一样的。
完善的S3接口要考虑缓存，否则性能比较差，这会比较麻烦，有一些开发工作量。本地或网络文件系统不用管这个。
也可以使用第三方的文件系统，有不少开源产品已经能把S3这类对象存储封装成满足POSIX协议的文件系统了，就可以直接用file函数了。不过会在架构上又多一层，复杂化了