Q1 运行环境

esProc 目前是纯 Java 软件，只要有 JDK1.8 及以上版本的 JVM 环境的任何操作系统都可以运行，包括常见的 VM 和 Container。

esProc 正常安装后占用空间不到 1G，但绝大多数都是引用的第三方外部数据源驱动包。其核心包不足 15M，甚至可以在 Android 上运行。

除 JVM 外，esProc 对运行环境没有其它硬性要求。对硬盘和内存的容量要求和计算任务相关，不同计算任务相差很大。执行同样计算任务时，esProc 需要的硬件资源通常小于传统数据库（特别是针对分布式数据库时会远小于）。加大内存、选用更高主频和核数的 CPU 以及使用 SSD 通常对提升计算性能都有提升作用。

Q2 数据存储与交换

esProc 没有传统数据仓库中“库“的概念，没有元数据概念，不对某个主题的数据进行统一管理。对 esProc 来讲，数据没有“库内”和“库外”的区分，也没有明确的“入库”和“出库”的动作。

任何可访问到的数据源都可以看作 esProc 的数据，并可被直接计算。计算前不需要先“入库”，计算后也可以用接口写出目标数据源中，不需要刻意“出库”。

esProc 对常见的数据源都封装了访问接口，如各种关系数据库（使用 JDBC）、MongoDB、HBase、HDFS、Cassandra、ElasticSearch、Kafka、HTTP/Restful、…，甚至 SalesForces、SAP BW、…。

各种数据源在逻辑上地位基本相同，不同之处仅仅在于访问接口以及不同接口表现出来的性能，这些接口是数据源厂商提供的，esProc 无法干预其功能和性能。

esProc 设计了特殊格式的文件来存储数据以获得更多的功能和更好的性能，这些数据文件存放在文件系统中，QDBsae 在技术上并不占有这些数据文件。esProc 已经将文件格式公开（访问代码开源），可以被任何能访问到这些数据文件的应用程序按照公开规范（或基于开源代码）读写，当然更方便的是直接使用 SPL 语写。

从这样意义上讲，esProc 与外部的数据交换没有“入库”“出库”的动作，但可能会有“转换”的动作，即把外部数据转转换成 esProc 格式的文件以获得更多功能和更好性能，也可以把 esProc 格式的文件转换成外部数据供其它应用继续使用。这些转换工作都可以使用 SPL 完成。

Q3 可处理数据类型

esProc 擅长的数据包括常规结构化数据、多层结构化数据（json/xml 等）、以及字符串文本数据和矩阵向量等数学数据。esProc 不擅长处理音频图像视频等数据。

特别地，esProc 对 json,xml 等多层结构化数据有强大的支持能力，远远超过传统数据库。所以 esProc 可以很好地和 mongodb 以及 kafka 等类 json 数据源配合，也能方便地和 HTTP/Restful 以及微服务交换数据并提供计算服务。

esProc 还能方便地计算 Excel 文件中的数据，但不擅长处理 Excel 的格式。

Q4 框架集成与流式计算

esProc 可以像传统数据库一样运行成独立服务进程，对外提供了标准的 JDBC 驱动和 HTTP 服务供应用程序调用。Java 应用程序可以通过 JDBC 发出 SPL 语句就可以执行，调用 esProc 上的脚本代码相当于调用关系数据库中的存储过程。非 Java 应用程序可以使用 HTTP/Restful 机制访问 esProc 提供的计算服务。

对于 Java 开发的应用程序，esProc 还提供了完全嵌入的方式，即在 JDBC 驱动中封装了所有计算功能，和主应用程序在同一进程内运行，不依赖于外部的独立服务进程。

因为 esProc 是纯 Java 软件，也可以嵌入式运行，所以可以完全无缝地集成进各种 Java 框架和应用服务器中，比如 Spring,Tomcat,…，可以被这些框架调度和运维，对于这些框架而言，esProc 的逻辑地位和用户写的 Java 应用程序完全相同。

需要指出的是，对于计算型框架（比如 Spark），虽然 esProc 能被无缝集成，但并没有实际意义。esProc 要求把数据转换成 SPL 特有的数据对象才能实施计算，不仅转换消耗时间，而且原计算框架中的数据对象都将失去意义，两类数据对象的优点不能融合。这些计算框架的关键点主要就是其数据对象（比如 Spark 的 RDD），如果不能继续使用，则计算框架本身也将失去意义。esProc 的计算能力远远超过常见的计算框架，也没有必要再使用这些框架。

特别地，对于流计算框架（比如 Flink），esProc 即使能集成也不能发挥作用。esProc 独立服务过多次流式计算案式，完全不需要流计算框架的支持，完成同样计算量消耗的资源通常会比这些流计算框架低一个数量级，而且功能更丰富。

Q5 功能扩展

esProc 是 Java 写的软件，提供了接口调用 Java 写的静态函数，这样可以扩充 esProc 的功能。esProc 也开放了自定义函数的接口，应用程序员可以用 Java 编写新的函数挂载到 esProc 中，使用就可以在 SPL 中使用。

Q6 弹性计算和计算可靠

esProc 支持分布式计算，可以多节点配合工作，但实际应用中很少用到，因为除高并发场景外，绝大多数任务的数据量和响应期望，esProc 都可以用单机实现。

esProc 即将发布的云版本（可支持私有化部署）将支持自动的弹性计算，请求量变大时会自动启用新的 VM 实施计算，请求量变小时将自动关闭闲置的 VM。

嵌入式的 esProc 仅上主应用程序提供计算服务，不能对外提供服务，也不能负责对外服务的可靠性，这由主应用程序以及框架来负责。

独立进程的 esProc 支持热备机制，JDBC 会在当前仍可工作的服务进程中选择负担较轻的来实施计算。esProc 的分布式计算也提供了容错能力，但 esProc 设计目标不是大规模集群，计算任务过程中发现节点故障后，该任务将被宣布失败。esProc 容错程度仅到发现节点故障时还允许集群能接受新任务，仅适合小规模集群。

esProc 的服务进程目前也没有提供故障后自动恢复的功能，需要管理人员来处理，不过做个监控进程来实现这个自动功能也并不难。

esProc 云版本的弹性计算机制在分配 VM 时会避开当前失效的节点，一定程度地实现高可用性。

Q7 数据安全和可靠

参见 2，esProc 原则上并不管理数据，也不对数据的安全负责。一定程度上可以说，esProc 没有与没必要有安全机制。

持久化数据的安全性原则上数据源本身负责。对于 esProc 格式的数据文件，很多文件系统或 VM 都提供了完善的安全机制（访问控制、加密等），可以直接利用。esProc 的云版本也支持从 S3 等对象存储服务上获取数据再计算，也可以利用它们的安全机制。

嵌入式的 QDBse 和主 Java 应用是同一个进程，仅向主程序提供计算服务，没有外部服务接口，不存在安全和权限问题。独立服务进程的 esProc 使用标准的 TCP/IP 和 HTTP 通信，可以被专业的网络安全产品监控和管理，具体安全措施将由这些产品负责。

esProc 专注于计算，对持久化存储的可靠性也不负责，这些方面同样的专业的技术和产品，esProc 尽量使用标准的规范，从而可以和这些技术和产品配合工作。比如可以将数据持久化到高可靠的对象存储上，esProc 实现了这些存储方案的接口，可以访问这些数据源实施计算。

esProc 是专业的计算技术，不拥有专业的安全能力，esProc 的理念是和其它专业技术配合。

Q8 SQL 兼容性

esProc 不是 SQL 体系的计算引擎，目前仅支持不涉及大数据量的简单 SQL，且不保证性能。在大数据需求场景下，可以认为 esProc 不支持 SQL，当然也不会和任何 SQL 存储过程兼容。

esProc 未来会发展出支持 SQL 的双引擎，但仍然很难保证高性能和大数据，仅仅是让存量的 SQL 代码易于迁移到 esProc。