【大数据】Linkis：打通上层应用与底层计算引擎的数据中间件

Linkis：打通上层应用与底层计算引擎的数据中间件 

Linkis 是微众银行开源的一款 数据中间件，用于解决前台各种工具、应用，和后台各种计算存储引擎间的连接、访问和复用问题。

1.引言

Linkis，一个打通了多个计算存储引擎如

Spark

、

TiSpark

、

Hive

、

Python

和

HBase

等，对外提供统一

REST

/

WebSocket

/

JDBC

接口，提交执行

SQL

、

Pyspark

、

HiveQL

、

Scala

等脚本的数据中间件。

Linkis 基于微服务架构，提供了金融级多租户隔离、资源管控、权限隔离等企业级特性，支持统一变量、UDF、函数、用户资源文件管理，具备高并发、高性能、高可用的大数据作业 / 请求全生命周期管理能力。

2.背景

大数据技术的广泛应用，催生出层出不穷的上层应用和下层计算引擎。

通过引入多个开源组件来实现业务需求，不断更新和丰富大数据平台架构，几乎是现阶段所有企业的通用做法。

如下图所示，当我们的上层应用、工具系统，和底层的计算存储组件越来越多时，整个数据平台的情况就会变成如上图的网状结构。

不断引入新组件来实现业务需求，越来越多的痛点也随之产生：

• 业务需求变化多端，上层组件各具特色，用户使用起来割裂感强烈，学习成本高昂。
• 数据种类繁多，存储和计算非常复杂，一个组件一般只解决一个问题，开发人员必须具备完善的技术栈。
• 新组件的引入，在多租户隔离、用户资源管理、用户权限管理等无法兼容原有数据平台，自上而下的定制化开发，不仅工程浩大，而且重复造轮子。
• 上层应用直接对接底层计算存储引擎，一旦底层环境发生任何改变，都会直接影响业务产品的正常使用。

3.设计初衷

如何提供统一的数据中间件，对接上层应用工具，屏蔽掉底层的各种调用和使用细节，真正做到让业务用户只需关注业务实现，就算底层平台机房扩建、整体搬迁都不受影响，是 Linkis 的设计初衷！

4.技术架构

如上图所示，我们基于 SpringCloud 微服务技术，新建了多个微服务集群，来打造 Linkis 的中间件能力。

每个微服务集群都承担系统的一部分功能职责，我们对其进行了如下明确的划分。如：

• 统一作业执行服务（UJES）：一个分布式的 REST / WebSocket 服务，用于接收上层系统提交的各种访问请求。 - 目前支持的计算引擎有：Spark、Python、TiSpark、Hive 和 Shell 等。- 支持的脚本语言有：SparkSQL、Spark Scala、Pyspark、R、Python、HQL 和 Shell 等；
• 资源管理服务（RM）： 支持实时管控每个系统和用户的资源使用情况，限制系统和用户的资源使用量和并发数，并提供实时的资源动态图表，方便查看和管理系统和用户的资源。 - 目前已支持的资源类型：Yarn 队列资源、服务器（CPU 和内存）、用户并发个数等。
• 统一存储服务（Storage）：通用的 IO 架构，能快速对接各种存储系统，提供统一调用入口，支持所有常用格式数据，集成度高，简单易用。
• 统一上下文服务（CS）：统一用户和系统的资源文件（用户脚本、JAR、ZIP、Properties 等），用户、系统、计算引擎的参数和变量统一管理，一处设置，处处自动引用。
• 物料库服务（BML）：系统和用户级物料管理，可分享和流转，支持全生命周期自动管理。
• 元数据服务（Database）：实时的 Hive 库表结构和分区情况展示。

依赖这些微服务集群的相互协作，我们改善了整个大数据平台对外服务的方式和流程。

5.业务架构

• Gateway 网关：基于 Spring Cloud Gateway 进行了插件化功能增强，新增了前端 Client 与后台多 WebSocket 微服务 1 1 1 多 N N N 支持，主要用于解析和路由转发用户的请求到指定微服务。
• 统一入口：统一入口是用户某一类引擎作业的 Job 生命周期管理者。从接收作业、作业提交给执行引擎、到作业执行信息反馈给用户，再到作业完成，Entrance 管理了一个作业的全生命周期。
• 引擎管理器：引擎管理器负责管理引擎的全生命周期。负责向资源管理服务申请和锁定资源，并实例化新的引擎，也负责监控引擎的生命状态。
• 执行引擎：执行引擎是真正执行用户作业的微服务，它由引擎管理器启动。为了提升交互性能，执行引擎直接跟统一入口进行交互，实时推送执行的日志、进度、状态和结果集给统一入口。
• 资源管理服务：实时管控每个系统和每个用户的资源使用情况，管理引擎管理器的资源使用和实际负载，限制系统和用户的资源使用量和并发数。
• Eureka：Eureka 是 Netflix 开发的服务发现框架，SpringCloud 将它集成在其子项目 spring-cloud-netflix 中，以实现 SpringCloud 的服务发现功能。每个微服务都内置了 Eureka Client，可以访问 Eureka Server，实时获得服务发现的能力。

6.处理流程

Linkis 如何处理上层系统提交的一条 SparkSQL？

• 上层系统的用户提交一个 SQL，先经过 Gateway，Gateway 负责解析用户请求，并路由转发给合适的统一入口 Entrance。
• Entrance 会先寻找该系统的该用户是否存在可用的 Spark 引擎服务，如果存在，则直接将请求提交给 Spark 引擎服务。
• 不存在可用 Spark 引擎服务，开始通过 Eureka 的服务注册发现功能，拿到所有的引擎管理器列表，通过请求 RM 实时获取引擎管理器的实际负载。
• Entrance 拿到负载最低的引擎管理器，开始要求引擎管理器启动一个 Spark 引擎服务。
• 引擎管理器接收到请求，开始询问 RM 该系统下的该用户，是否可以启动新引擎。
• 如果可以启动，则开始请求资源并锁定；否则返回启动失败的异常给到 Entrance。
• 锁定资源成功，开始启动新的 Spark 引擎服务；启动成功后，将新 Spark 新引擎返回给 Entrance。
• Entrance 拿到新引擎后，开始向新引擎请求执行 SQL。
• Spark 新引擎接收 SQL 请求，开始向 Yarn 提交执行 SQL，并实时推送日志、进度和状态给 Entrance。
• Entrance 将获取的日志、进度和状态实时推送给 Gateway。
• Gateway 回推日志、进度和状态给前端。
• 一旦 SQL 执行成功，Engine 主动将结果集推给 Entrance，Entrance 通知前端拿取结果。

如何保证高实时性

众所周知，Spring Cloud 集成了

Feign

来作为微服务之间的通信工具。

基于

Feign

的微服务之间 HTTP 接口调用，只支持 A 微服务实例根据简单规则随机访问 B 微服务的某个实例。

但 Linkis 的执行引擎，却可以直接主动推送日志、进度和状态给请求它的统一入口，Linkis 是如何做到的？

Linkis 基于

Feign

实现了一套自己的底层

RPC

通信方案。

如上图所示，我们在

Feign

的基础上，封装出了

Sender

和

Receiver

。

Sender

作为发送端直接可用，用户可以指定访问某个微服务实例，也可以随机访问，还支持广播。

Receiver

作为接收端，需要用户实现

Receiver

接口，用于处理真正的业务逻辑即可。

Sender

提供三种访问方式，如下：

• ask 方法为同步请求响应方法，要求接收端必须同步返回响应。
• send 方法为同步请求方法，只负责同步将请求发送给接收端，不要求接收端给出答复。
• deliver 则为异步请求方法，只要发送端的进程不异常退出，在稍后会通过其它线程将请求发送给接收端。

7.如何支撑高并发

Linkis 设计了

     5 
    
   
  
    5 
   
  
5 大异步消息队列和线程池，Job 每次占用线程不到  
 
  
   
   
     1 
    
   
  
    1 
   
  
1 毫秒，保证每个统一入口可承接超  
 
  
   
   
     10000 
    
   
  
    10000 
   
  
10000+ TPS 常驻型 Job 请求。

• 如何提高上层的请求吞吐能力？- Entrance 的 WebSocket 处理器，内置一个处理线程池和处理队列，接收 Spring Cloud Gateway 路由转发的上层请求。
• 如何保证不同系统不同用户的执行请求，互相隔离？- Entrance 的 Job 调度池，每个系统的每个用户，都有一个专用线程，保证隔离度。
• 如何保证 Job 执行高效？- Job 执行池，只用于提交 Job，一旦 Job 提交给了 Engine 端，则立马放入 Job 执行队列，保证每个 Job 占用执行池线程的时间不超过 1 1 1 毫秒。- RPC 请求接收池，用于接收和处理 Engine 端推来的日志、进度、状态和结果集，并实时更新 Job 的相关信息。
• 如何实时将 Job 的日志、进度和状态推给上层系统？- WebSocket 发送池，专门用于处理 Job 的日志、进度和状态，将信息推给上层系统。

8.用户级隔离度和调度时效性

Linkis 设计了 Scheduler 模块 —— 可智能监控扩展的分组调度消费模块，用于实现 Linkis 的高并发能力。

每个系统的每个用户，都会单独分组，来保证系统级和用户级的隔离度。

每个消费器均有一个独立的监控线程，统计消费器中等待队列的长度、正在执行的事件数量、执行时间的增长比例等指标。

消费器所对应的分组对象，会对这些指标设置阈值和告警比例，一旦某个指标超过阈值，或多个指标间的比例超过限定范围（比如监控到平均执行时间大于分发间隔参数，即认为超过阈值），监控线程就会立即对消费器进行相应的扩展。

扩展时，会充分利用上述的调参过程，具有针对性的调大某个参数，其它参数会自动随之得到扩展。

9.总结

Linkis 作为数据中间件，为实现对下层调用细节的屏蔽，做了许多的尝试和努力。

比如：Linkis 如何实现统一存储服务？Linkis 如何统一 UDF、函数和用户变量？

由于篇幅所限，本文不再详细论述，如您感兴趣，欢迎您访问官网：https://linkis.apache.org

有没有一套真正基于开源，经过金融级生产环境和场景的自研打磨完善，再回到开源社区的数据中间件，让人能相对放心的拿去服务于生产，支持金融级业务，具备企业级特性保障？

我们希望 Linkis 成为答案。