一、Linkis 出现的背景
大数据平台早期通常以单个引擎或单类任务为中心建设：离线 SQL 依赖 Hive，交互分析依赖 Spark SQL 或 Presto，实时计算依赖 Flink，脚本任务依赖 Python 或 Shell。随着平台能力扩展，应用层需要分别适配不同引擎的认证、提交协议、参数格式、日志获取、状态查询、资源控制和结果集管理，调用链路会变得复杂。
这种方式在小规模平台中可行，但在多租户、高并发、多引擎共存的场景下会出现几个典型问题：接口重复开发、任务治理分散、资源隔离困难、上下文难以复用、排障路径不统一。Linkis 的设计目标就是在应用层和引擎层之间建立统一计算中间件，解耦上层应用与底层引擎，降低复杂网络调用关系带来的开发和维护成本 。
二、架构总览
Linkis 将微服务分为三类：计算治理服务、公共增强服务和微服务治理服务。这三个层次对应了任务从提交到执行、从公共能力复用到服务注册网关的完整链路。
计算治理服务是 Linkis 的核心，计算治理服务覆盖任务处理的三个主要阶段：提交、准备、执行；公共增强服务包括物料库、上下文服务和数据源服务；微服务治理服务包括 Spring Cloud Gateway、Eureka 和 OpenFeign。
三、核心组件
Linkis 的组件命名初看有些复杂，但可以从任务链路倒推它们的职责。用户的任务先进入 Gateway，再到 Entrance，随后由 Orchestrator 编排，向 LinkisMaster 申请 EngineConn，最终由 EngineConnManager 拉起或管理 EngineConn，EngineConn 再对接 Spark、Hive、Flink 等底层引擎。
| 组件 | 作用 | 理解方式 |
|---|---|---|
| Gateway | HTTP、WebSocket 请求入口与路由 | 平台统一入口 |
| Entrance | 任务入口、任务调度、状态控制、日志与结果推送 | 任务接待员 |
| Orchestrator | 任务编排与计算策略 | 任务计划器 |
| LinkisMaster | AppManager、ResourceManager、LabelManager 等管理能力 | 资源与引擎调度中心 |
| EngineConnManager | 管理 EngineConn 生命周期 | 引擎进程管家 |
| EngineConn | 连接具体底层引擎并执行任务 | 真正干活的执行连接 |
| PublicService | 历史任务、公共能力、配置等 | 公共服务层 |
| Context Service | 管理上下文、变量、资源等 | 跨系统上下文容器 |
| DataSource Service | 数据源与元数据管理 | 数据源目录 |
其中 EngineConn 是理解 Linkis 的关键，EngineConn 负责接收任务，并提交给 Spark、Hive、Flink、Presto、Trino 等底层引擎执行；EngineConnManager 则负责 EngineConn 的启动和停止等生命周期控制 。
四、任务执行链路
Linkis 的任务执行可以拆成四个阶段：提交、准备、执行、结果返回。任务执行过程分为 submission、preparation、execution、result return 四个阶段，并描述了 Entrance、Orchestrator、LinkisMaster、EngineConnManager、EngineConn 等组件在各阶段中的职责。
yaml
阶段 1：提交
用户 / 应用
|
| REST / WS / JDBC
v
Gateway
|
v
Entrance
|
| 持久化任务、参数解析、变量替换、拦截器处理
v
Scheduler
阶段 2：准备
Scheduler
|
v
Orchestrator
|
| 根据 Label 选择引擎类型、版本、租户、资源策略
v
LinkisMaster
|
| 判断是否复用 EngineConn，或创建新的 EngineConn
v
EngineConnManager
阶段 3：执行
EngineConnManager
|
v
EngineConn
|
| 调用 Spark / Hive / Flink / Presto / Trino 等底层引擎
v
Underlying Engine
阶段 4：返回
Underlying Engine
|
v
EngineConn
|
| 推送状态、日志、进度、资源使用、结果集
v
Entrance
|
v
调用方这个链路的价值在于：应用层不再需要直接管理每一种计算引擎的执行细节。它只需要按照 Linkis 的协议提交任务，并通过统一接口查询状态、获取日志和结果。
五、功能特性与适用场景
Linkis 的功能不只是"提交任务"。它更像是一个面向多引擎的大数据计算治理层，核心能力可以概括为五类。
| 能力 | 说明 | 价值 |
|---|---|---|
| 多引擎接入 | 支持 Spark、Hive、Python、Shell、Flink、JDBC、Presto、Trino、SeaTunnel 等 | 减少上层应用重复适配 |
| 多语言支持 | 支持 SparkSQL、HiveSQL、Python、Shell、PySpark、Scala、JSON、Java 等 | 覆盖开发、查询、脚本和计算场景 |
| 计算治理 | 提供基于多级标签的任务路由、负载均衡、多租户、流控、资源控制 | 支撑多团队共享平台 |
| 上下文统一 | 跨用户、系统和计算引擎管理变量、UDF、资源文件、结果集等 | 提高跨工具协作与复用能力 |
| 数据源管理 | 管理 Hive、Elasticsearch、MySQL、Kafka、MongoDB 等数据源信息、版本、连接测试和元数据 | 让平台具备统一数据源目录 |
Linkis 的优势可以从"平台工程"的角度理解，它并不是替代 Spark、Hive、Flink，而是让这些引擎在一个统一的平台治理体系中被使用。
第一，Linkis 降低上层应用接入成本。Linkis 通过 REST、WebSocket、JDBC 等标准接口让上层应用访问 MySQL、Spark、Hive、Presto、Flink 等底层引擎 。这意味着数据开发 IDE、调度系统、Notebook 或自研平台可以围绕 Linkis 接口集成，而不是逐个适配引擎。
第二，Linkis 强化多租户资源治理。高并发、多租户隔离、上下文统一、高可用、日志进度实时推送、多类型任务提交等这些问题都是 Linkis 任务执行架构演进的动因 。
第三，Linkis 让计算资源可以复用。LinkisMaster 在收到申请 EngineConn 的请求后，会判断是否存在可复用的 EngineConn；如果有则直接返回，如果没有再创建新的 EngineConn 。这对交互式 SQL、Notebook、数据开发 IDE 等场景尤其重要，因为频繁拉起引擎会增加延迟和资源消耗。
第四，Linkis 提供统一排障入口。Linkis 提供错误码能力，便于用户定位常见任务错误 。FAQ 中也整理了 publicservice 未启动、Eureka 首次启动自动停止、资源不足、依赖包冲突、MySQL ONLY_FULL_GROUP_BY 等问题及处理建议 。
Linkis 适合放在"多应用、多引擎、多租户"的大数据平台中，而不是作为单一计算引擎使用。它的强项是连接、治理、复用和平台化。
| 场景 | 是否适合 | 原因 |
|---|---|---|
| 数据开发平台统一提交 Spark、Hive、Shell、Python 任务 | 适合 | Linkis 提供统一任务提交和多引擎接入 |
| Notebook 或交互式分析平台复用 SparkSession 类能力 | 适合 | EngineConn 可被复用，适合交互式计算 |
| 企业内部多租户共享大数据集群 | 适合 | 支持标签、资源控制、并发控制和多租户治理 |
| 自研调度系统统一接入多类引擎 | 适合 | 可通过 REST/JDBC 等接口提交和管理任务 |
| 只需要运行单机 Python 脚本 | 不一定适合 | Linkis 的微服务和治理能力可能过重 |
| 只使用单一 Hive 查询且没有平台化需求 | 不一定适合 | 直接使用 HiveServer2 或现有查询服务可能更简单 |
| 替代 Spark、Flink 作为计算引擎 | 不适合 | Linkis 是计算中间件，不是底层计算引擎 |
六、部署使用
标准单机部署的基本流程如下：
yaml
准备环境
|
| JDK / MySQL / Python / Nginx / Hadoop / Spark / Hive
v
创建部署用户
|
| 通常示例使用 hadoop 用户，并配置免密 sudo
v
下载并解压 Linkis 安装包
|
v
修改 deploy-config/db.sh
|
| 配置 Linkis 业务库、Hive Meta 等信息
v
修改 deploy-config/linkis-env.sh
|
| 配置部署用户、工作目录、HDFS 路径、YARN 地址、组件环境变量
v
执行 sh bin/install.sh
|
| 首次安装需要初始化数据库
v
补充 MySQL Driver
|
| Apache 发布包默认不包含 mysql-connector-java
v
启动服务
|
| sh linkis-start-all.sh
v
提交测试任务并查看日志、结果、状态在单机（All-in-One）模式下，默认会启动 6 个核心微服务，每个微服务默认 JVM-Xmx为 512M。
| 顺序 | 微服务名称 | 核心功能 |
|---|---|---|
| 1 | mg-eureka | 微服务注册中心，所有服务启动后都会向它注册。 |
| 2 | mg-gateway | API 网关，所有外部请求的统一入口，负责路由和认证。 |
| 3 | ps-publicservice | 公共服务，提供文件系统等基础公共服务。 |
| 4 | cg-linkismanager | 计算治理管理服务，负责应用、资源和标签的管理。 |
| 5 | cg-entrance | 计算治理入口服务，接收并调度用户提交的任务。 |
| 6 | cg-engineconnmanager | 引擎管理服务，负责启动和管理各类计算引擎。 |
还有一个linkis-cg-engineconn服务（引擎连接器），它是在具体任务提交时才启动的，因此不会在服务启动时出现。
初学 Linkis 时，可以先不要陷入所有微服务细节，而是记住三个问题。
rust
问题 1：任务从哪里进来？
答案：Gateway -> Entrance
问题 2：任务由谁决定怎么跑？
答案：Entrance Scheduler -> Orchestrator -> LinkisMaster
问题 3：任务最终在哪里执行？
答案：EngineConn -> Spark / Hive / Flink / Trino / Shell 等再把任务对象理解为"四件套"：
sql
+---------------------+
| executionContent | 代码和运行类型，例如 SQL、Shell、Python
+---------------------+
| params | 变量、运行参数、启动参数
+---------------------+
| source | 来源信息，例如脚本路径
+---------------------+
| labels | 引擎类型、用户、创建者、路由等标签
+---------------------+Linkis 的很多治理能力都围绕labels展开，Gateway 可根据routeLabel转发请求，Entrance 会按标签分组调度任务，LinkisMaster 也会通过任务 Label 做资源管理和引擎版本选择。
七、选型建议
如果你的团队正在建设统一数据开发平台、Notebook 平台、自研调度平台或多引擎查询平台，Linkis 值得重点评估。它的优势不在单点性能，而在平台化接入和治理能力：统一接口、多引擎适配、任务状态与日志管理、资源控制、上下文复用、数据源管理。
但如果你的场景只需要"跑一个 Spark 作业"或"提交一条 Hive SQL"，Linkis 可能不是最轻的选择。它引入了 Gateway、Entrance、LinkisMaster、EngineConnManager、PublicService、Eureka 等多个服务，部署和维护成本高于直接访问单个引擎。因此，Linkis 更适合已有大数据平台基础、需要治理多引擎任务的团队。