jbx1279
jbx1279
操作系统通常都有定时调度机制，spl可以用命令行执行，再由操作系统来调度。 自己做的调度可能还不如操作系统做得好，所以暂时还没有计划搞这个功能。 数据文件工具中的ETL功能目前还是在尝试阶段，重点也是完善ETL本身的数据处理能力。
这个不太好搞。SPL有空序表对象，可以create一个返回。 但通常出现这种情况是计算结果就是空集（比如select后是空的），没有记录也就没有数据结构了。而且SPL支持混合数据结构，不像SQL那样要求结果集的数据结构是唯一的，也就不合适指定某种数据结构。 不过，大部分情况直接返回null问题也不大的，null可以继续后面的各种操作（new,derive,.... )，也不会报错，反正进一步结果还是null，只是没法有一个标题出现了。
这个还不太容易做，工作量有点大，目前开发重点还放在进一步性能优化，IDE的主要工作放在云版本的远程调度功能上。 现在版本也有些辅助编辑功能，在上面编辑框（不是下面网格中），输入函数比如 A.select(...)，光标落在函数文本中时，按Alt-Down能列出函数参数和选项。 SPL的函数比较多且参数规则复杂（要干的事也比较多），不是天天用的总要去查资料，这样辅助一下也会方便一点。
不直接支持。可以读成blob再转成整数序列，会较麻烦且速度慢。 常见的文件格式可以用Java写成自定义函数处理，再常见也可以开发外部库
这个在调研中...
世界是复杂的。 开放SPL的原则是尽量减少约束，正确性要自己负责。
SPL的思路和RDB不同，它是开放的计算体系，没有“库”的概念，只要能访问到的数据都能计算，无非是访问性能不同。组表和其它文本文件以及从RDB/NoSQL中读出来的数据，在计算功能上，并没什么本质不同。”有哪些组表“这个问题对SPL并没有意义，自己到文件系统下看就可以了，甚至网络文件系统以及远程对象存储也可。 至于组表的数据结构（以及索引），有函数可以读出来。大小之类的信息，问文件系统就可以了。 没有元数据，才会有开放性，这是个基本理念。这个体系做成云原生后，也非常轻，很容易做到serverless和弹性扩展。 后面会逐步提供一些方便的编辑与管理工具，但仍然是对着文件系统的，没有“库”。数据计算无处不在，不需要“库”这个概念。
file要求是文件系统的协议（POSIX的一部分）。httpfile就是HTTP的协议了。对象存储是它独特的协议，肯定不能直接用这个了。 对象存储目前还不直接支持，后续的外部库会支持S3等协议，把对象存储映射成一个文件对象，提供类似s3file这样的函数，之后再生成组表等动作都是一样的。 完善的S3接口要考虑缓存，否则性能比较差，这会比较麻烦，有一些开发工作量。本地或网络文件系统不用管这个。 也可以使用第三方的文件系统，有不少开源产品已经能把S3这类对象存储封装成满足POSIX协议的文件系统了，就可以直接用file函数了。不过会在架构上又多一层，复杂化了
组表是大数据，需要整理的数据，不适合在应用运行过程中维护数据，通常要在专门的ETL过程来更新数据。提供随时更新数据能力会降低读取和运算性能，权衡的结果是暂不提供（看情况可以考虑增加选项）。 不能把组表完全当数据库用（至少在写的方面），设计适应它的存储机制。我们不推荐在应用端加锁避开这个问题后实现并发写（读）。
ETL过程还会有并发写？没考虑过这种场景。 多进程并发，SPL就识别不了，也没法加锁（除非加到硬盘上，那成本确实高了）。多线程时可以用lock函数加锁控制并发。自动加锁的事，要再权衡一下成本（导致读和算的性能损失）和收益。 另外，组表通常要有序，并发写不可能保证这个了，即使提供这种能力，似乎也用处不大。