这可能是支持数据源最多的计算技术
今天，企业的数据来源已经从原来的“就几张表”发展到数据库、文件、接口、流式数据、对象存储、NoSQL……五花八门。能不能搞定“多数据源混算”，已经成了数据计算技术的重要标准之一。
说起多源混算，“逻辑数据仓库”大概是最主流的做法了。而且听起来很美：不用提前同步数据、不用折腾传统 ETL，还能用 SQL 跨库查询。
但理想丰满，现实骨感。这些逻辑数仓，以为能连天接地，真落地用的时候，发现不过是支持几个主流关系库、几个文件格式，稍微冷门一点的数据源立马就抓瞎。想搞点跨源混算？配置半天还跑不通，最后还得靠 Python 打补丁。
esProc：真正在“多数据源支持”上做对了的技术
相比于逻辑数仓那套复杂建模的“重”思路，esProc 走的是：不用建模、不隐藏数据源的“轻”机制，明确地告诉你——每个数据源我都能连，我直接读取原始数据，然后用一套统一的脚本语言 SPL 来混合计算。
听上去朴素，但效果非常强悍。
支持的数据源真多，不是“吹”出来的
esProc 的连接能力确实覆盖极广，主流数据源基本都有原生支持，按类型来看：
关系数据库：Oracle、MySQL、SQL Server、PostgreSQL、SQLite、DB2……只要支持 JDBC 的，基本都能直接用；
非关系数据库：MongoDB、Redis 等，不走关系模型也能玩；
各种文件格式：CSV、Excel、JSON、XML、Parquet、ORC，不管结构规不规整，都能读；
消息队列和流数据：Kafka 直接对接，处理流式数据也不在话下；
大数据平台与对象存储：Hive、HDFS、S3 等；
HTTP / Web API：支持 JSON、XML 格式解析，直接从接口拉数据；
其他奇奇怪怪的：Elasticsearch、InfluxDB 等也有现成封装。
比起一些“自称支持多源”的技术，esProc 这个列表不仅长，而且用起来也顺手。
不只是能连，还能混合计算，语法还挺爽
很多技术是“能连不能算”，比如某些逻辑数仓系统，Connector 接上了，但做个跨库关联写一大堆 SQL 子查询还不一定跑得通；有的嵌入式数据库像 DuckDB，虽然也能查 CSV、Parquet，但连数据库反倒犯难，像 Oracle、SQL Server 这些企业常用库却不支持；至于 Python，库虽然多，但用法乱七八糟，每种都要单独学习，根本谈不上统一接口。
而 esProc 就清爽很多：
比如做 MySQL 和 Oracle 的跨库关联：
| A | |
| 1 | =oracle.query("select EId,Name from employees") |
| 2 | =mysql.query("select SellerId, sum(Amount) subtotal from Orders group by SellerId") |
| 3 | =join(A1:O,SellerId; A2:E,EId) |
再比如 MongoDB 混查 MySQL，结构更复杂也能轻松搞：
| A | |
| 1 | =connect("mysql") |
| 2 | =A1.query@x("SELECT o.order_id, o.user_id, o.order_date, oi.product_id, oi.quantity, oi.price FROM orders o JOIN order_items oi ON o.order_id = oi.order_id WHERE o.order_date >= CURDATE()- INTERVAL 1 MONTH") |
| 3 | =mongo_open("mongodb://127.0.0.1:27017/raqdb") |
| 4 | =mongo_shell@d(A3, "{'find':'products', 'filter': { 'category': {'$in': ['Tablets', 'Wearables', 'Audio'] } }}” ) |
| 5 | =A2.join@i(product_id,A4:product_id,name,brand,category,attributes) |
| 6 | =A5.groups(category;sum(price*quantity):amount) |
使用对应数据源的原生语法，不仅更简单，还能充分保留原有数据源的优势。
对于习惯 SQL 的用户，esProc 还贴心提供了 SQL 支持。简单情况可以直接用 SQL，复杂情况就切回 SPL，二者混用，灵活度更高。
扩展新数据源，自己动手也不难
让 esProc 真正不同的是在“扩展数据源”这件事上做得特别轻巧。
逻辑数仓要扩展新数据源，得专门开发一个 Connector，这不是简单写个配置文件那么轻松，而是要对目标数据源的访问机制、查询语言、数据格式深度理解，再嵌入逻辑数仓框架里去对接、解析、转换，复杂度极高。用户想要基于源码自己扩展几乎不可能，需要等待厂商的支持。
而 esProc 则是统一使用 Native 接口 + 简单封装的方式来做：
对于关系型数据库，直接使用 JDBC，拿来即用；
对于 MongoDB、Kafka 这类非关系数据源，也是在官方驱动基础上做了轻封装。
esProc 还提供了扩展接口机制，不需要掌握底层架构，只要知道目标数据源怎么读数据、怎么格式化，基本就能做一个“Connector”级别的功能。这就意味着：esProc 本身支持的已经够多，但如果你还想支持更奇葩的数据源，自己动手也完全没压力。
不追求“透明”，但灵活度更高
逻辑数仓讲究“透明”：你写一条 SQL，底层自动调度多个数据源。但这种“透明”代价非常大，Connector 必须非常强大，很多时候一旦数据结构稍微复杂或者不规则，系统就跪了。
esProc 走的是“明确”：每个数据源你自己接，数据你自己拿回来，然后 SPL 统一处理。虽然不那么“优雅”，但灵活得多，特别适合处理非结构化、半结构化、甚至动态结构数据，逻辑复杂也能 hold 住。
透明化有好处，但也限制扩展能力； SPL 则是把“灵活可扩展”放在第一位。
融得进主流应用系统
有些计算引擎虽然好用，但难嵌入。比如 Python 库再多，在 Java 主导的企业系统里总归是“外来户”，调用不顺。
esProc 则是纯 Java 开发，部署灵活，既可以嵌入做内存计算引擎，也可以作为微服务独立运行。该集成时能集成，该独立时能独立，对企业系统友好度极高。
多，不只是种类多，更是扩展轻、用得爽
说到底，数据源支持得多，不只是“数量多”那么简单。关键是：
esProc 原生支持种类多，覆盖全；
扩展能力强，轻封装、低门槛；
写法统一，逻辑清晰，还能混合 SQL；
适合各种结构数据，灵活高效；
跟主流系统集成顺滑，不惹麻烦。
这几条加起来，才能撑起这句话：
esProc，可能是目前支持数据源最多的计算技术。
不仅支持得多，还支持得好、扩展得快、用得舒服。
英文版