一、问题与挑战
1.1 多样化的数据需求
Lindorm的架构起源于Bigtable，其核心是LSM引擎+存储计算分离，并融入了类CosmosDB的多副本多一致性设计和二级索引、数据Schema等能力，适合于互联网通用场景的海量半结构、结构化数据的在线存储与简单处理。
然而，现代应用场景的玩法和功能越来越丰富，除了高扩展、低延时、高可用、低成本等核心需求之外，简单分析、多维检索等高级数据处理正在成为越来越多应用的基本需求。为此，我们看到lindorm之上的用户，通常会有两个选择：
直接基于Lindorm进行数据检索或分析，通过系统本身的扩展并发能力，来保障处理效率满足应用需求。这种方式最大的优点是使用简单、开发便捷，但不可避免在规模和成本制约下，会存在瓶颈；
通过数据通道，部分数据转存到搜索系统(如ES、Solr等)，满足多维检索的需求；部分数据转到OLAP或数仓系统，满足统计分析的需求。这种方式最大的优点，是集合各个系统的优势能力，在扩展性上可以支撑很大的业务规模，但不可避免带来维护的复杂和数据的冗余。并且，对于异构系统之间的数据模型差异和一致性问题，通常需要业务层做针对性处理，再加上多套系统的学习理解，使得应用开发成本大幅升高，让中小规模企业的用户群体望而却步。
除了通用数据处理需求的多样化之外，在部分垂直场景下，业务期待专用的数据处理能力，使得在开发效率、运行成本等方面能有数量级的提升，以应对更大规模的数据增长。比如，在监控场景，公司内部的监控系统大部分都基于lindorm进行构建，应用期望将指标数据的降采样、预聚合、预测分析等常见能力可以下沉到数据库系统，因此，TSDB、OpenTSDB、InfluxDB等时序数据库应运而生，专注于解决如Metric指标的时序数据存储问题，大幅提升了监控/IoT场景中的设备时序数据处理能力。但是，应用也面临着新的烦恼，专用时序数据库的引入，提升了指标Metric数据的处理能力，但并不能去除系统中的其他数据库，如Log、Tracing、设备元数据库等通用数据仍需要存储在Lindorm中，部分场景可能还需要引入搜索系统来加速查询，系统的架构和维护变得越来越复杂。
类似情景还有不少，比如社交场景的消息推送、内容存储、聊天搜索等，游戏场景的道具、聊天、关系、录像等存储，广告场景的画像、点击日志、物料等存储，这些数据的多样化需求带动了多类型的存储系统的发展，在面对复杂场景时，相比于传统的单一存储选型，基于多套系统的存储解决方案大幅提升了系统的运行效率。但为此所付出的是，复杂数据库组合选型以及多系统架构维护下的业务时间成本和人力成本，我们不禁想问，下一站的架构该是什么？
1.2 业务流量的不可预测
互联网场景中业务流量的快速变化和不可预测是数据库维护者一直以来的痛点，在过去的日子里，我们面对的生产稳定性问题，很多是可以扩容解决的，但由于成本的约束，又不得不限制容量，使得成本与稳定性这两个问题被耦合在一起。这种计划式的资源管理模式，不仅浪费大量时间精力去进行容量规划预测、资源调度搬迁等工作，也无法保障资源的充分利用，更时刻承受着资源不足导致问题的稳定性风险。
云计算的兴起，唤醒了业务对于资源按需即时获取的强烈需求，弹性能力（区别于扩展性）也成为云上开发者对于云产品的默认理解，Lindorm需要重新思考这个方向的解决思路和挑战，我们期望在不久的某一天，大家不用再时刻担心容量水位，只需要异步地去统计和控制资源使用量，让资源利用率提升和系统稳定性风险成为两个相互独立的问题。
1.3 面向成本的存储碎片化
数据驱动是互联网业务的基础特征，通过数据进行拉新、推广、统计等几乎是所有应用的常规需求，让我们看到了数据给业务带来的价值，但另一方面，业务数据化过程中依赖的海量数据的存储成本，使得业务不得不仔细权衡数据维护的经济效益。如何降低数据的单位存储成本，是过去所有数据化应用都在考虑的核心问题，并逐渐形成了冷温热的多系统异构混合方案。比如，常见的是热数据存于MySQL，温数据存于HBase，全量冷数据归档到对象存储OSS或数仓中，由此产生的数据同步、查询维护、生命周期管理、冷热数据的业务差异化等给所有应用带来了很大的痛苦。
低成本存储是用户选择Lindorm的重要因素，也是持续不断的要求，但我们在过去也看到了部分业务因成本压力而分拆极冷数据转存OSS的应用复杂改造，甚至是业务侧自身的结构化数据编码压缩和缓存加速等，给系统维护和数据正确保障带来了复杂的挑战。这种因数据价值差异产生的异构化数据存储是一种通用的诉求，如何原生解决好这个问题，不让用户在低成本和复杂之间做纠结的选择，是Lindorm面对成本诉求的一个重要挑战。
1.4 开放的标准接口
从去年开始，Lindorm以"HBase企业增强版"的方式服务于阿里云上的企业客户，凭借其多年内部实践沉淀出的性能、成本、稳定性等企业级优势，快速形成了阿里云HBase产品与友商、开源自建的差异化竞争力。通过兼容开源标准接口，使得Lindorm快速切入商业化，但同时也面临着能力被约束的瓶颈，比如用户无法很好用到Lindorm的二级索引、多一致性、数据Schema等能力，使得整体产品的能力定位和市场规模很大程度上取决于开源的发展，而Hadoop和HBase社区这几年处于较为明显的下坡趋势，我们需要一个相对独立的发展思路和市场方向，来解决开源红利变现后期的市场挑战。
但这并不意味着，我们要去推出Lindorm在公司内部使用的私有标准接口。相反，存量业务上云仍然是很长一段时间内的主节奏，应用平滑迁移是上云过程中的核心诉求，私有标准无疑于背离市场。所以，如何包容更多的开放标准接口，如何无缝对接开放技术生态，如何兼顾内部使用的私有标准，是Lindorm自研技术商业化过程面临的又一大挑战。
二、趋势与思路
2.1 融合的多模数据管理
随着业务的多样化，应用对于数据的多类型处理能力提出了新的要求，而传统多套系统组合解决方案又有架构复杂、维护成本、起步门槛高等痛点，使得用户对于数据库系统提供Multi-model能力的诉求越来越明显。同时，Multi-model也作为一个技术趋势热词，频繁出现在近几年的Gartner等前沿报告中。通过db-engines网站，我们可以看到已经有大量流行的数据库系统打上了Multi-model的能力标签，反映了各个厂商和市场在此领域的实质性响应。
虽然大家普遍认为支持多模型是数据库，尤其是NoSQL数据库的重要趋势，但是对其具体的技术理解和实施却不尽相同。大部分系统基于通用KV/Table模型，构建出更多的垂直模型，如HBase基础之上的OpenTSDB，从而在数据库开发与运行效率之间取得一个折中，但受限于数据引擎的唯一性，无法在各个垂直场景取得最佳效率，所以无法从本质上替换多套系统组合的解决方案，更多是去减缓使用。还有部分云厂商的产品，在数据库平台和产品宣传侧形成统一，而在应用开发侧，各个模型独立资源、独立部署、独立使用，更多是一种对多套系统组合方案的体验优化。
与现有多模数据库的部分解决不同，Lindorm希望通过多模能力的构建，即满足应用数据的多样化处理需求，又拥有简单统一的应用开发体验，还具备垂直场景的高效运行效率，从而真正释放用户所需要的多模优势。与传统分库分表方案升级到分布式数据库内置Sharding能力相似，Lindorm希望将应用在面对多套系统组合方案中的复杂数据处理下沉到数据库，如多模数据同步、多模关联查询、统一读写接口等，并提供简单、高效、稳定的一体化多模能力。
Lindorm期望探索和实践一种真正的多模原生的数据库，基于融合的多模数据管理思想，面向用户提供统一的产品体验、统一的数据存储、统一的查询访问、统一的系统架构、统一的数据交换，内置垂直专用的数据引擎，犹如内置CPU、GPU、 NPU等多处理器的计算机，取得高效、简单的双赢。
2.2 云原生
在过去几年，云原生技术和理念得到了广泛接受和快速发展，虽然相关定义更新很快和对其理解也不尽相同，但从开发者角度而言，云原生是一种最大化享受云计算红利的技术理念，包括但不限于弹性伸缩、按量付费、开放标准、Serverless化等能力，将推动软件重塑生命周期。
Lindorm的未来是全面拥抱云原生，逐步从构建于传统IT架构环境，走向云基础设施；从整租式的数据库服务，走向弹性按需使用；从阿里私有协议接口，走向业界开放标准生态。重点打造以下能力：
Serverless，Serverless是体现云计算的按需使用、极致弹性的最好表现形式，用户可以通声明式API定义对数据库资源的要求，包括可用性、延迟、一致性、部署位置等，并且不再需要为不确定的业务流量去评估存储、请求等资源，完全收敛精力到业务的开发，加速数据应用创新。实现真正的数据库Serverless能力的核心关键是隔离和调度，前者需要解决共享资源下的稳定性问题，确保租户之间不会产生影响；后者需要解决资源的按需供应和高效利用，确保集群负载均衡，并能根据业务流量快速弹性伸缩。
IaaS云化，通过云基础设施的共池资源，不仅可以解决库存与成本的问题，免除基础IaaS的维护开销，为弹性Serverless提供联动的物理资源；同时，其永不下线和按需取用的特点，也将促使软件架构进化，打破节点宕机不可恢复和资源固定的假设，借助于可扩容、可重启的外力，软件的稳定性体系建设将拥有更多的手段和策略。最后，云上丰富的基础资源形态，如多类型算力(CPU/GPU/FPGA)、多样化存储(ESSD/高效云盘/OSS)，使得Lindorm针对数据的存储处理可以更加多元化，比如冷热分层、Compaction Offload等。
开放标准，数据库领域的标准接口主要是两类，一类是开源数据库的事实标准，另一个就是通用的SQL标准。Lindorm将同时提供两种方式，即承载好外部存量业务的平滑迁移，也具备差异化能力的输出窗口。
智能化，虽然智能与云原生是两个平行的词，但智能是实现云原生技术理念的重要手段，弹性伸缩、无人运维、按需使用、低成本等能力的建设都离不开智能化，比如基于流量的统计分析和预测，做更加准确的资源调度，从而提供更好的弹性；比如数据冷热的智能识别，从而分离存储降低成本；比如通过智能诊断、智能索引，大幅提升系统自我稳定性，减少运维投入。所以，云原生的Lindorm，一定是内置智能。
2.3 冷热数据一体化存储
面对数据价值的差异化和海量数据的存储成本压力，冷热分离是过去时间里业界解决此问题的主要思路，虽然在各个系统和解决方案中的实施各有差异和不足，但我们看到了业务对于冷热数据底层分离和上层统一的思想认可和强烈需求，用户希望获得一种理论可行的最低存储成本，而无需担心冷热的界定和双向转换、冷数据的查询降级、一致性语义等问题。
Lindorm期望原生提供冷热数据的一体化存储，并确保冷数据存储成本达到业界最低标准，让业务不再疲于数据的搬挪腾转，重点构建以下能力：
统一读写访问，冷热温数据的差异只存在于存储侧，而在与业务对接的查询写入侧保持一致。不同数据之间拥有不同的性能和成本，但拥有相同的数据视图和功能，从而使得终端用户保持一致的数据体验。
冷热自动识别，对于随着时间流逝、数据逐渐由热转冷的常见场景，系统将根据物理时间点自动识别和分离冷热数据；对于没有时间属性的场景，系统将借助于机器学习，判断数据的冷热特征和访问预测。无论哪种方式，数据的冷热转换都是双向的，从而匹配业务的灵活变化。
冷热异构处理，针对冷数据系统将使用更高压缩比的算法、更低成本的存储介质和更加懒惰的数据清理策略等，使得冷数据的综合存储成本仅有1/10以下。
自由的冷存储介质，如何构建极低成本的冷存储是一件需要软硬件+机房设施协同的大工程，而这并不是Lindorm的重心方向，所以在具体的冷存储介质上，我们Lindorm选择聚焦于此的OSS存储(在部分环境受限的场景，则继续使用传统的HDD磁盘），并结合面向数据结构的高压缩、数据缓存、生命周期管理等，其整体性能、成本会远优于业务直存OSS。
冷温热多层，虽然冷热是大部分业务对数据的快速分离策略，但也存在冷、温、热、极速等更多层次的需求，系统支持用户定义多层存储和异构处理方式，进一步满足业务的灵活性。
2.4 引擎垂直化
在上文中，我们提到基于通用KV引擎构建多模的解决方案，这是一种快速实现多模能力的扩展方式，但却是一种相对中间的状态。面向表、时序、时空、图等各个垂直场景，其数据的特点和应用需求差异明显，比如对于时序场景，数据生而自带时间属性，并且沿着时间线生成新数据，所以通过时间维度进行数据分区的方式就显得非常简单高效，并且数据的组织设计也可以去匹配这些特点。目前时序和图数据库的Top1产品(InfluxDB、Neo4j)都是运用了时序原生引擎、图原生引擎的思想，来打造各自在垂直领域的技术优势，我们也认为这是垂直模型被规模化应用的趋势选择。
除了多模混合场景之外，在面对垂直场景的独立数据存储与处理时，Lindorm期望具备不亚于任何专用数据库的能力，所以，多模型的Lindorm，选择引擎垂直化的架构，从而使得各个数据引擎均拥有优秀的可创新性和灵活性，在专用场景也保持技术竞争力。
三、云原生多模数据库Lindorm
面对多模数据管理的应用需求和云原生的技术趋势，着眼于集团云原生战略、5G/IoT时代的未来发展，我们正式升级Lindorm为云原生多模数据库，融合原Lindorm和TSDB过去的技术积累，支持多类型、任意规模数据的低成本存储处理和自适应弹性伸缩，服务于互联网、IoT、车联网、广告、社交、监控、游戏、风控等场景。
新Lindorm将重点围绕云原生、多模型、低成本持续打造海量数据存储处理场景的竞争力，并通过集团云原生上云战役，实现一套产品同时服务好内外客户，提供更稳定、更高效、更经济的基础数据库服务，在以下能力获得新的飞跃：
3.1 融合多模
系统支持宽表、时序、搜索、文件四种模型，提供统一联合查询和独立开源接口两种方式，模型之间数据互融互通，帮助应用开发更加敏捷、灵活、高效。多模型的核心能力由四大数据引擎提供，包括：
宽表引擎，面向海量KV、表格数据，具备全局二级索引、多维检索、动态列、TTL等能力，适用于元数据、订单、账单、画像、社交、feed流、日志等场景，兼容HBase、Phoenix(SQL)、Cassandra(CQL)等开源标准接口。
时序引擎，面向IoT、监控等场景存储和处理量测数据、设备运行数据等时序数据。提供HTTP API接口(兼容OpenTSDB API)、支持SQL查询。针对时序数据设计的压缩算法，压缩率最高为15:1。支持海量数据的多维查询和聚合计算，支持降采样和预聚合。
搜索引擎，面向海量文本、文档数据，具备全文检索、聚合计算、复杂多维查询等能力，同时可无缝作为宽表、时序引擎的索引存储，加速检索查询，适用于日志、账单、画像等场景，兼容开源Solr标准接口。
文件引擎，提供共享存储底座的服务化访问能力，从而加速多模引擎底层数据文件的导入导出及计算分析效率，兼容开源HDFS标准接口。
对于目前使用类HBase+ElasticSearch或HBase+OpenTSDB+ES的应用场景，比如监控、社交、广告等，利用Lindorm的原生多模能力，将很好地解决架构复杂、查询痛苦、一致性弱、成本高、功能不对齐等痛点，让业务创新更高效。
3.2 云原生弹性
Lindorm基于存储计算分离的架构，支持计算资源、存储资源的独立弹性伸缩，并将全新提供Serverless服务，实现按需即时弹性、按使用量付费的能力。Lindorm Serverless基于多租户隔离、智能调度、弹性IaaS底座构建，具备企业级SLA保障，满足内部大部分业务的可用性要求，从而让一线同学大幅降低容量管理的运维负担，消除因流量波动导致的稳定性风险。
面对互联网场景的持续波动和不可预测的业务流量，弹性是Lindorm渴望已久的能力，也将是未来持续重点聚焦的方向。
3.3 极致性价比
Lindorm面向海量数据场景而生，低成本是业务的普遍需求和产品的持续追求。在存储上，将新上线三大核心能力：
a) 支持透明存储到低成本介质，目前默认为OSS标准型，后续将支持低频型、归档型。同时，系统内置缓冲加速层，让查询实时性仍有较大的保障，适合读并发不大的数据；
b) 支持智能冷热分离，针对数据随着时间线逐渐热变冷的场景，典型如监控、社交聊天、交易账单等，Lindorm内部将自动识别数据的冷热，并进行分离存储到高性能介质和低成本介质（两者之间的单价成本差可高达10:1），而用户读写访问保持完全透明，并且热数据的访问性能还能有所加速。
c) 支持自适应压缩，针对数据的不同类型和特点，系统将自动选择混合的字典、前缀、Delta、熵编码等压缩算法，相比业界通用算法，整体压缩率提升10%~30%。
在性能上，Lindorm宽表引擎在吞吐延迟上做了非常多的突破，其基准性能是开源HBase的7倍（下图为参考报告）；Lindorm时序引擎面向数据天然顺序写入和近线访问的特点，融入了许多创新型的高性能结构设计，其基准性能在目前的信通院榜单中处于第一的位置，大幅领先于其他专用时序数据库。
3.4 丰富检索
数据的多条件查询检索正在成为越来越多应用的基本需求，新Lindorm将大幅增强索引能力，满足面向海量数据的快速查询检索需求，提供全局二级索引（支持全局分布式、强一致、按需索引和冗余等特性，完美兼容Schemaless模型，并可以自动利用索引加速非主键查询）、全文检索（通过倒排索引的方式，支持多条件随机组合查询，应用侧透明查询，自动索引优化）、全文索引（支持分词、搜索、排序等）、时序索引（支持时序数据的高效查询、聚合）等功能。
3.5 智能化服务
面向服务自助化、运维智能化、运营数据化的目标，Lindorm全新LDInsight工具，具备信息透视、系统管理、智能诊断等功能，帮助应用开发者/DBA轻松掌握系统运行状态，白屏化完成常见系统管理和数据访问操作，以及自动诊断使用过程中的常见问题，比如慢请求、热点、性能诊断、Schema设计、索引推荐等，让用户和维护者更加简单、高效地使用Lindorm，减少服务对人的依赖。
3.6 开放数据生态
作为数据全域处理的一环，如何与关系数据库、批流计算平台、日志采集平台等系统无缝打通和一体化使用是Lindorm重点建设的方向。新Lindorm原生提供LTS(Lindorm Tunnel Service，原BDS)，支持简单易用的数据交换、处理、订阅等能力，满足用户的数据迁移、实时订阅、数湖转存、数仓回流、单元化多活、备份恢复等需求，实现面向Lindorm的一站式数据生态服务。
除此之外，Lindorm将继续完善多一致性、跨机房容灾、扩展性、稳定性等能力，成为云计算时代的"大多数选择"。
四、架构解析
Lindorm系统基于存储计算分离架构设计，以适应云计算时代资源解耦和弹性伸缩的诉求。其中云原生存储引擎LindormStore为统一的存储底座，向上构建各个垂直专用的多模引擎，包括宽表引擎、时序引擎、搜索引擎、文件引擎。在多模引擎之上，Lindorm既提供统一的SQL访问，支持跨模型的联合查询，又提供多个开源标准接口(HBase/Phoenix/Cassandra、OpenTSDB、Solr、HDFS)，满足存量业务无缝迁移的需求。最后，统一的数据Stream总线负责引擎之间的数据流转和数据变更的实时捕获，以实现数据迁移、实时订阅、数湖转存、数仓回流、单元化多活、备份恢复等能力。下文，我们将对各个组件的关键技术和能力做一个简单介绍。
4.1 存储引擎
LindormStore是面向公共云基础存储设施（如云盘、DBFS、OSS）设计、兼容HDFS协议的分布式存储系统，并同时支持运行在本地盘环境，以满足部分专有云、专属大客户的需求，向多模引擎和外部计算系统提供统一的、与环境无关的标准接口，其整体架构如下：
LindormStore支持四种软件定义的存储资源形态，分别满足不同场景下的性能与成本差异需求：
a) 性能型，通过DBFS的共享存储技术，一块云盘可以被挂载到多个ECS节点，并同时读写云盘上的数据，从而在ECS节点宕机时，保障数据的高可用访问。相比基于普通云盘集群的至少存储6个副本（云盘本身底下是3副本，基于云盘部署的分布式存储系统仍然需要设置2副本），数据的总副本数可以减少50%，有效消除上云之后的存储膨胀问题。但受限于DBFS的设计，其本身并不是无限扩展的，单个DBFS的磁盘空间、IOPS、可挂载节点数存在上限，并且由于分布式锁与通信的关系，共享挂载节点数越少则性能越好。所以，LindormStore负责将多个DBFS融合，重点解决文件分块、数据块分配及共享、均衡调度等问题，形成统一目录的、无限扩展的分布式存储，提供HDFS协议的数据服务。基于此技术，采用ESSD作为介质，Lindorm对外向用户提供性能型存储形态。
b) 标准型，整体技术方案与性能型一致，其存储介质采用高效云盘。
c) 容量型，针对海量数据低成本存储的诉求，我们通过分布式Buffer+OSS的方式，构建了弹性、低成本的容量型存储形态。其核心思想是数据同步写入到分布式Buffer层，然后异步迁移到OSS存储，可按需设置一定的读缓存。分布式Buffer层可以保障数据的持久化和可靠性，并具备Log Sync语义，所以其写入能力与性能型/标准型一致，特别适合海量数据下的低成本存储、高吞吐写入、弱查询要求的场景需求。
d) 本地型，针对部分无法提供云基础存储设施的环境，LindormStore也支持基于本地盘构建，通过数据的三副本机制保障数据的高可靠，适合于专有云、轻量化输出场景。
面对真实场景的数据冷热特点，LindormStore支持性能型/标准型、容量型多种存储混合使用的形态，结合多模引擎的冷热分离能力，以及云基础存储OSS/DBFS的按需弹性特点，实现冷热存储空间的自由配比，让用户的海量数据进一步享受云计算的低成本红利。
4.2 宽表引擎
LindormTable是面向海量半结构化、结构化数据设计的分布式NoSQL系统，兼容HBase、Phoenix(SQL)、Cassandra等开源标准接口。其基于数据自动分区+分区多副本+LSM的架构思想，具备全局二级索引、多维检索、动态列、TTL等查询处理能力，支持单表百万亿行规模、千万级并发、毫秒级响应、跨机房强一致容灾等，高效满足业务大规模数据的在线存储与查询需求，整体架构如下：
LindormTable的数据持久化存储在LindormStore中，表的数据通过自动Sharding分散到集群中的多台服务器上，并且每一个Parition可以拥有1至N个副本，这N个副本拥有主、从两种角色，主从副本可以加载在不同的Zone，从而保障集群的高可用和强一致。针对不同的一致性模式，主从副本之间的数据同步和读写模式如下：
a) 强一致模式，只有主副本提供读写，数据会异步回放到从副本,主副本所在节点故障，从副本晋升为主（晋升之前会保障数据同步完成，从副本拥有所有最新数据，整体过程由Master协调负责）
b) 最终一致模式，主从副本都提供读写，数据会相互同步，保证副本之间的数据最终一致。
LindormTable的多副本架构基于PACELC理念设计，每一个数据表都支持单独支持设置一致性模式，从而拥有不同的可用性和性能。在最终一致模式下，服务端会对每一个读写请求在一定条件下触发多副本并发访问，从而大幅提升请求的成功率和减少响应毛刺。该并发机制建立在内部的异步访问框架上，相比于启动多线程，额外资源消耗可以忽略不计。对于并发访问的触发条件，主要包括两个类型：其一是限时触发，对于每一个请求，都可以单独设置一个GlitchTimeout，当请求运行时间超过该值未得到响应后，则并发一个请求到其他N-1个副本，最终取最快的那个响应；其二是黑名单规避，服务端内部会基于超时、抛错、检测等机制，主动拉黑存在慢、Hang、死等问题的副本，使得请求能够主动绕开受软硬件缺陷的节点，让服务最大可能保持平滑。对于像掉电Kill这样的Hang死场景，在节点不可服务至失去网络心跳往往会存在一两分钟的延迟，利用LindormTable的这种多副本协同设计，可以将影响控制在10秒以内，大幅提升服务的可用性。
LindormTable的LSM结构面向冷热分离设计，支持用户的数据表在引擎内自动进行冷热分层，并保持透明查询，其底层结合LindormStore的冷热存储混合管理能力，大幅降低海量数据的总体存储成本。
LindormTable提供的数据模型是一种支持类型的松散表结构。相比于传统关系模型，LindormTable除了支持预定义字段类型外，还可以随时动态添加列，而无需提前发起DDL变更，以适应大数据灵活多变的特点。同时，LindormTable支持全局二级索引、倒排索引，系统会自动根据查询条件选择最合适的索引，加速条件组合查询，特别适合如画像、账单场景海量数据的查询需求。
4.3 时序引擎
LindormTS是面向海量时序数据设计的分布式时序引擎，兼容开源OpenTSDB标准接口，其基于时序数据特点和查询方式，采用Timerange+hash结合的分区算法，时序专向优化的LSM架构和文件结构，支持海量时序数据的低成本存储、预降采样、聚合计算、高可用容灾等，高效满足IoT/监控等场景的测量数据、设备运行数据的存储处理需求，整体架构如下：
TSCore是时序引擎中负责数据组织的核心部分，其整体思想与LSM结构相似，数据先写入Memchunk，然后Flush到磁盘，但由于时序数据天然的顺序写入特征，定向专用的时序文件TSFile的结构设计为以时间窗口进行切片，数据在物理和逻辑上均按时间分层，从而大幅减少Compaction的IO放大，并使得数据的TTL、冷热分离等实现非常高效。
TSCompute是负责时序数据实时计算的组件，重点解决监控领域常见的降采样转换、时间线聚合、时序值预测等需求，其通过Lindorm Stream进行数据订阅，并完全基于内存计算，所以，整体非常的轻量、高效，适合系统已预置的计算功能。针对部分灵活复杂的分析需求，用户仍可以通过对接Spark、Flink等系统实现，从而支撑更多场景和适应业务变化。
4.4 搜索引擎
LindormSearch是面向海量数据设计的分布式搜索引擎，兼容开源Solr标准接口，同时可无缝作为宽表、时序引擎的索引存储，加速检索查询。其整体架构与宽表引擎一致，基于数据自动分区+分区多副本+Lucene的结构设计，具备全文检索、聚合计算、复杂多维查询等能力，支持水平扩展、一写多读、跨机房容灾、TTL等，满足海量数据下的高效检索需求，具体如下：
LindormSearch的数据持久化存储在LindormStore中，通过自动Sharding的方式分散到多台SearchServer中，每一个分片拥有多个副本，支持一写多读，提升查询聚合的效率，同时这些副本之间共享存储，有效消除副本之间的存储冗余。
在Lindorm系统中，LindormSearch既可以作为一种独立的模型，提供半结构化、非结构化数据的松散文档视图，适用于日志数据分析、内容全文检索；也可以作为宽表引擎、时序引擎的索引存储，对用户保持透明，即宽表/时序中的部分字段通过内部的数据链路自动同步搜索引擎，而数据的模型及读写访问对用户保持统一，用户无需关心搜索引擎的存在，跨引擎之间的数据关联、一致性、查询聚合、生命周期等工作全部由系统内部协同处理，用简单透明的方式发挥多模融合的价值。
4.5 文件引擎
LFS是基于LindormStore轻量封装的分布式文件模型服务，其核心是提供安全认证、限流保护、多网络访问等服务化能力，从而使得外部系统可以直接访问多模引擎的底层文件，大幅提升备份归档、计算分析等场景的效率。同时，用户可以在离线计算系统直接生成底层数据格式的物理文件，通过LFS入口，将其快速导入到LindormStore中，以减少对在线服务的影响。对于部分存储计算的混合场景，用户可以将计算前的源文件存在LFS，计算后的数据结果存在LindormTable，结合Spark/DLA等大规模计算引擎，实现简单高效的数据湖分析能力。