产品架构

业务背景

伴随着信息技术的飞速发展，各行各业在业务生产中产生的数据种类越来越多，有结构化的业务元数据、业务运行数据、设备或者系统的量测数据，也有半结构化的业务运行数据、日志、图片或者文件等。按照传统方案，为了满足多种类型数据的存储、查询和分析需求，在设计IT架构时，需要针对不同种类的数据，采用不同的存储分析技术，如下图：

这种技术方案，是一种典型的技术碎片化的处理方案。针对不同的数据，使用不同的数据库来处理。有如下几个弊端：

• 涉及的技术组件多且杂

• 技术选型复杂

• 数据存取、数据同步的链路长

这些弊端会对信息系统建设带来巨大的问题，对技术人员要求高、业务上线周期长、故障率高、维护成本高。更进一步，技术碎片化导致技术架构割裂，不利于技术架构的演进和发展，最终导致技术架构无法跟进业务前进的步伐。举个简单的例子，当业务发展，需要支持跨可用区高可用、全球同步或者降低存储成本时，各技术组件都需要独立演进和发展，耗时耗人耗力，是一件非常痛苦的事情。并且随着业务的发展，数据的类型会越来越多，对不同种类数据的差异化处理需求会日渐增加，会导致数据存储碎片化更加严重。

当前信息化技术发展面临的一个主要矛盾是"日益多样的业务需求带来的多种类型数据与数据存储技术架构日趋复杂成本快速上升之间的矛盾"。伴随5G、IoT、智能网联车等新一代信息技术的逐步普及应用，这个矛盾会越来越突出。为了解决这个问题，阿里云自研了云原生多模数据库Lindorm，满足多模型数据的统一存储、查询和分析需求。如下图所示，与传统方案相比，Lindorm系统极大地简化数据存储技术架构设计，大幅度提升系统稳定性，降低建设成本投入。

总体架构

Lindorm创新性地使用存储计算分离、多模共享融合的云原生架构，以适应云计算时代资源解耦和弹性伸缩的诉求。其中云原生分布式文件系统LindormDFS为统一的存储底座，向上构建各个垂直专用的多模数据引擎，包括宽表引擎、时序引擎、搜索引擎、流引擎等。在多模引擎之上，Lindorm既提供统一的SQL访问，支持跨模型的联合查询，又提供多个开源标准接口（HBase/Cassandra、OpenTSDB/InfluxDB、Kafka、HDFS），满足存量业务无缝迁移的需求。最后，数据通道服务（LTS）负责引擎之间的数据流转和数据变更的实时捕获，以实现数据迁移、实时订阅、数湖转存、数仓回流、单元化多活、备份恢复等能力。

分布式文件系统

LDFS（Lindorm DFS，也称为Lindorm文件引擎）是面向云基础存储设施设计、兼容HDFS协议的分布式存储系统，并同时支持运行在本地盘环境，以满足部分大客户的需求，向多模引擎和外部计算系统提供统一的、与环境无关的标准接口，整体架构如下：

LDFS提供性能型、标准型、容量型等多种规格，并且面对真实场景的数据冷热特点，支持性能型/标准型、容量型多种存储混合使用的形态，以适应真实场景的数据冷热特点，可结合多模引擎的冷热分离能力，实现冷热存储空间的自由配比，让用户的海量数据进一步享受云计算的低成本红利。

在计算分析、备份归档、数据导入等场景，Lindorm支持外部系统通过LDFS直接访问多模数据引擎的底层文件，从而大幅提升数据的读写效率。例如用户可以在离线计算系统直接生成底层数据格式的物理文件，导入至Lindorm中，以减少对在线服务的影响。

宽表引擎

LindormTable是面向海量半结构化、结构化数据设计的分布式NoSQL系统，适用于元数据、订单、账单、画像、社交、feed流、日志等场景，兼容HBase、Cassandra等开源标准接口。其基于数据自动分区+分区多副本+LSM的架构思想，具备全局二级索引、多维检索、动态列、TTL等查询处理能力，支持单表百万亿行规模、高并发、毫秒级响应、跨机房强一致容灾，高效满足业务大规模数据的在线存储与查询需求。面向海量半结构化、结构化数据设计的分布式NoSQL系统，能够兼容HBase、Cassandra等开源标准接口。整体架构如下：

LindormTable的数据持久化存储在LDFS中，表的数据通过自动Sharding分散到集群中的多台服务器上，并且每一个分区可以拥有1至N个副本，这N个副本拥有主、从两种角色，主从副本可以加载在不同的Zone，从而保障集群的高可用和强一致。针对不同的一致性模式，主从副本之间的数据同步和读写模式如下：

• 强一致模式。只有主副本提供读写，数据会异步回放到从副本，主副本所在节点故障，从副本晋升为主副本。晋升之前会保障数据同步完成，从副本拥有所有最新数据，整体过程由Master协调负责。

• 最终一致模式。主从副本都提供读写，数据会相互同步，保证副本之间的数据最终一致。

LindormTable的多副本架构基于PACELC理念设计，每一个数据表都支持单独支持设置一致性模式，从而拥有不同的可用性和性能。在最终一致模式下，服务端会对每一个读写请求在一定条件下触发多副本并发访问，从而大幅提升请求的成功率和减少响应毛刺。该并发机制建立在内部的异步访问框架上，相比于启动多线程，额外资源消耗可以忽略不计。对于并发访问的触发条件，主要包括两个类型：

• 限时触发，对于每一个请求，都可以单独设置一个GlitchTimeout，当请求运行时间超过该值未得到响应后，则并发一个请求到其他N-1个副本，最终取最快的那个响应。

• 黑名单规避，服务端内部会基于超时、抛错、检测等机制，主动拉黑存在慢、停止响应等问题的副本，使得请求能够主动绕开受软硬件缺陷的节点，让服务最大可能保持平滑。比如在掉电断开的场景下，在节点不可服务至失去网络心跳往往会存在一两分钟的延迟，利用LTable的这种多副本协同设计，可以大幅提升服务的可用性。

LindormTable的LSM结构面向冷热分离设计，支持用户的数据表在引擎内自动进行冷热分层，并保持透明查询，其底层结合LStore的冷热存储混合管理能力，大幅降低海量数据的总体存储成本。

LindormTable提供的数据模型是一种支持数据类型的松散表结构。相比于传统关系模型，LindormTable除了支持预定义字段类型外，还可以随时动态添加列，而无需提前发起DDL变更，以适应大数据灵活多变的特点。同时，LindormTable支持全局二级索引、倒排索引，系统会自动根据查询条件选择最合适的索引，加速条件组合查询，特别适合如画像、账单场景海量数据的查询需求。

时序引擎

LindormTSDB是面向海量时序数据设计的分布式时序引擎，兼容开源OpenTSDB等标准接口，其基于时序数据特点和查询方式，采用Timerange+hash结合的分区算法，时序专向优化的LSM架构和文件结构，支持海量时序数据的低成本存储、预降采样、聚合计算、高可用容灾等，高效满足IoT/监控等场景的测量数据、设备运行数据的存储处理需求，整体架构如下：

TSCore是时序引擎中负责数据组织的核心部分，其整体思想与LSM结构相似，数据先写入Memchunk，然后Flush到磁盘，但由于时序数据天然的顺序写入特征，定向专用的时序文件TSFile的结构设计为以时间窗口进行切片，数据在物理和逻辑上均按时间分层，从而大幅减少Compaction的IO放大，并使得数据的TTL、冷热分离等实现非常高效。

TSCompute是负责时序数据实时计算的组件，重点解决监控领域常见的降采样转换和时间线聚合需求，通过Lindorm Stream进行数据订阅，并完全基于内存计算，所以，整体非常的轻量、高效，适合系统已预置的计算功能。针对部分灵活复杂的分析需求，用户仍可以通过对接Spark、Flink等系统实现，从而支撑更多场景和适应业务变化。

搜索引擎

LindormSearch是面向海量数据设计的分布式搜索引擎，兼容开源Solr标准接口，同时可无缝作为宽表、时序引擎的索引存储，加速检索查询。其整体架构与宽表引擎一致，基于数据自动分区+分区多副本+Lucene的结构设计，具备全文检索、聚合计算、复杂多维查询等能力，支持水平扩展、一写多读、跨机房容灾、TTL等，满足海量数据下的高效检索需求，具体如下：

LindormSearch的数据持久化存储在LDFS中，通过自动Sharding的方式分散到多台SearchServer中，每一个分片拥有多个副本，支持一写多读，提升查询聚合的效率，同时这些副本之间共享存储，有效消除副本之间的存储冗余。

在Lindorm系统中，LindormSearch既可以作为一种独立的模型，提供半结构化、非结构化数据的松散文档视图，适用于日志数据分析、内容全文检索；也可以作为宽表引擎、时序引擎的索引存储，对用户保持透明，即宽表/时序中的部分字段通过内部的数据链路自动同步搜索引擎，而数据的模型及读写访问对用户保持统一，用户无需关心搜索引擎的存在，跨引擎之间的数据关联、一致性、查询聚合、生命周期等工作全部由系统内部协同处理，用简单透明的方式发挥多模融合的价值。

流引擎

LindormStream是面向流式数据处理的引擎，提供了流式数据的存储和轻计算功能，兼容Kafka API和Flink SQL，帮助业务基于Lindorm快速构建基于流式数据的处理和应用。

LindormStream内部包含流存储、流计算两大组件，通过两者的一体化部署和深度融合，支持流数据的高性能实时处理。其中，流存储负责消息日志数据的写入和订阅，兼容开源Kafka API，并且数据持久化存储在底层LDFS中，具备高吞吐、低成本、弹性等优势。流计算负责消息日志的实时处理，兼容Flink SQL语法，计算结果数据可以同步至Lindorm宽表引擎、时序引擎等。

计算引擎

计算引擎是基于云原生架构提供的分布式计算服务，计算节点运行在阿里云Serverless Kubernetes（简称ASK）容器服务中。计算引擎支持社区版计算模型以及编程接口，同时深度融合Lindorm存储引擎特性，充分利用底层数据存储特征以及索引能力，高效地完成分布式作业任务。在数据生产、交互式分析和机器学习等场景中，提供高性能计算服务。Spark作业执行中，计算引擎提供了作业管理接口，您可以通过Spark Web UI（简称SparkUI）界面对Spark作业进行完整的监控运维。

AI引擎

AI引擎是Lindorm在数据库内集成AI能力对多模数据（时序、文本、图像、音视频等）进行一站式智能分析和处理的引擎，包括LLM、文生图、图生图、图片识别等。其支持用户使用SQL从开源模型平台（包括ModelScope、HuggingFace）灵活导入预训练模型，也支持用户上传自己的模型，轻松实现在Lindorm内的模型部署和推理。

Lindorm AI引擎采用云原生架构，支持弹性部署云上多种规格的推理节点，且推理节点支持多种机型（CPU和GPU），有效提升模型推理的性能。此外，推理节点和多模引擎存储共享，在减少数据传输成本的同时实现了靠近数据的推理优化。