双11特刊｜十年磨一剑，云原生多模数据库Lindorm 2021双11总结

Posted 2021-12-29 阿里云云栖号

前言

2021 年，转眼 Lindorm 已经在阿里发展了十年的时间，从基于 HBase 深度改造的 Lindorm 1.0 版本，到全面重构，架构大幅升级的 Lindorm 2.0 版本；从单一的宽表引擎，到支持搜索、时序、文件等多种结构化数据处理的多模引擎，Lindorm 始终保持着快速迭代和升级的速度，以满足阿里集团各类业务的数据存储需求。目前，Lindorm是公司内部数据体量最大，覆盖业务最广的数据库产品之一。

去年，在让广大用户看得见、存得起的理念下，Lindorm 再次做了品牌升级，率先提出了多模超融合数据库概念。Lindorm 不单单是宽表、时序、搜索等引擎的简单堆叠，而是在统一的分布式存储引擎之上，各个引擎之间互通融合，并由统一的 SQL 入口来实现多模数据库的统一访问。

在 Lindorm 一个数据库中，用户就可以实现流式计算，宽表存储，列式索引、时空索引、时序预测、数据订阅，以及在各个模型上的复杂分析等多种功能。面对复杂多变的业务，以及百花齐放的应用，业务不需要面临选型和运维多个复杂数据库的难题，数据的整个生命周期都可以在Lindorm 内部各个组件中完成，满足用户写入，查询，分析，监控各种需求。

 2021年双11，Lindorm为手淘互动营销、智能风控、媒体大屏、生意参谋、花呗决策、消费记录等核心系统保驾护航，提供集群水位和状态透传产品化能力，业务可自行按需伸缩，提升备战效率，业务支持成本降低80%。云原生Serverless架构升级，大促资源按需弹性伸缩，资源管理效率提升10倍+，降本增效。基于存储池化及透明压缩技术，最高降低53%存储成本。分布式3AZ架构，实现秒级恢复的跨机房强一致容灾能力，支撑金融级高可用场景。

而作为 Lindorm 多模数据库中重要一环的宽表引擎，目前已经完整经历了 Lindorm 十年的发展，其功能、性能、稳定性等方面的诸多创新历经了长时间的大规模实践考验。服务了包括淘宝、天猫、蚂蚁、菜鸟、妈妈、优酷、高德、大文娱等数十个 BU。

Lindorm 宽表融合了阿里巴巴过去十年在大规模宽表技术领域的技术能力和经验，并在上云后，利用云基础设施，实现了云原生化，向低成本等方向又有了一些创新和突破，进一步构建了海量数据处理场景的竞争力。十年的演进过程中，我们实现了跨 AZ 容灾，支持了多一致性满足各种业务的需求。支持一体化冷热分离，高压缩算法降低用户成本。实现了分布式全局二级索引，并和搜索引擎结合推出 SearchIndex 满足用户各种复杂查询需求。十年来，我们团队聚焦在宽表领域，不断打磨 Lindorm 宽表引擎，可谓是十年磨一剑。今年我们又对 Lindorm 宽表的一些功能进行了升级和改造，推陈出新，真正践行了把简单留给客户，把复杂留给自己的理念。

更加易用的功能

Lindorm宽表积攒了一大批面向各类用户的功能，比如说SQL，二级索引等等。这些功能方便了用户的使用。但是随着业务场景的增加，用户对这些功能又提出了一些新的需求。比如之前SQL不支持order by等功能，用户在使用时有比较大的局限。面对用户这些槽点，Lindorm宽表对功能又做了进一步的增强。

更强大的SQL能力

Lindorm宽表引擎在很早的时候就已经支持了SQL访问，相比使用API，SQL语言更加简单容易上手，深受广大Lindorm开发者的喜爱。并且，Lindorm的宽表引擎支持将指定列在搜索引擎中建立倒排索引，使用统一的SQL去访问。但是，之前的Lindorm SQL还只支持一些简单的SQL DML操作，像order by，group by和join等语法都不支持。今年，我们把整个SQL模块都进行了重构，重构后的SQL模块将成为Lindorm各个引擎统一的SQL入口，并且通过引入了复杂执行器（Complex Executor）模块，把之前不支持的group by等SQL语法都已经支持。现在，这套新的SQL引擎还在继续演进，我们的目标是在使用统一的SQL接入层访问Lindorm各个模型，将不同负载的请求路由到合适的组件中。

更加安全的数据

数据安全是企业的生命线，Lindorm上的很多客户在Lindorm宽表内存储了很多敏感数据，特别是金融客户，由于监管需求，所有涉及到用户和订单的数据，都必须加密传输和加密存储。因此，Lindorm在已有的用户名密码权限的基础上，又加入了多重加密功能，以及审计日志等功能，满足这类企业级用户需要。

透明加密

云上客户和集团客户的区别之一就在于其丰富的行业特性。金融领域和国家机构这两类客户在进行数据库产品选型时都对数据库的安全性表现出了强烈的兴趣。并且纵观云计算领域，Azure 的 cosmosDB，AWS 的 DynamoDB，阿里云的 OSS，RDS 都具备静态数据加密的能力，缺乏安全方面的功能特性有时会直接失去进入某个行业的入场券。

当今数据库面临的安全威胁大致可以分为 8 类，而静态数据加密并不是全家桶式的安全解决方案，其主要致力于解决众多威胁中的一类 —— 不安全的存储介质。持久化数据库中的数据最终会以文件的形式保存在硬盘等存储介质当中，如果数据以明文的形式保存，通过直接解析文件可以轻易获取用户的业务数据。

数据库透明加密（TDE）是实现静态数据加密的一种方式，对比客户端加密，数据库透明加密的优势在于整个加密由数据库内部完成，数据库的使用者不感知这一过程，因此无需改动。对比文件系统加密，数据库透明加密的优势在于可以更细粒度的控制加密的范畴，在安全和性能之间取得一个较好的平衡。

Lindorm 在设计的过程中，兼顾考虑了实现复杂度，性能开销，以及使用门槛等因素，选择以表为颗粒度支持透明加密，同时在加密算法上，支持了国际公认的分组加密算法 AES 和国家商密算法 SMS4。欢迎对数据安全性有需求的业务联系我们使用。

其他加密支持

除了Lindorm宽表内核支持的透明加密，Lindorm还支持了一些其他的加密方式，比如云盘加密，基于块存储对整个数据盘进行加密，即使数据备份泄露也无法被解密，保护数据安全。另外，我们还基于Thrift协议加SSL的方式，实现了传输加密，使用户整个访问链路都是加密状态，进一步保证了用户的安全。接下来，我们还会实现Lindorm自身协议的加密功能。

审计日志

有很多非常在意生产安全的企业需要记录每一次操作Lindorm的记录，比如建表，删表操作，用户授权等等。有一些存储了敏感数据的企业，甚至要求记录每一条记录的访问日志，看什么时候，什么人读取了哪个用户的信息，用来做合规审计和事后追查。面对这些客户的需求，Lindorm宽表引擎研发了审计日志功能。能够详细记录每个DDL，甚至DML的操作信息。目前，我们的审计日志正在与SLS打通，打通后，我们的审计日志可以通过LogTail投递到用户指定的SLS中，用户可以自行定制审计日志保留时间，以及查询需求。

更加高效的运维

Lindorm在集团内有上万台机器，在云上也有上千个实例。运行在这些实例上的业务千差万别，负载和模型各不一样，很难做到一套配置满足所有用户的需求。比如在写入流量比较大的集群上，默认的Compaction配置可能会造成Compaction积压，小文件增多影响性能。Compaction的调参需要资深的内核同学进行，这项工作费时费力。另外，虽然说Lindorm是一个分布式数据库，但用户在设计表结构时，或者突发流量来临时，往往会有热点问题打爆单机，这些都需要SRE手工去处理，不仅速度慢，而且会造成稳定性问题。因此，今年Lindorm选取了线上出现问题比较多的Compaction积压和热点问题，进行了专项优化，让这些问题能够自动的解决掉，提升Lindorm的自愈能力，解放运维人员的压力，加强系统稳定性。

Offload Compaction

基于 LSM-Tree 架构的分布式数据库，对于数据写入并不会原地更新，而是先写入内存，然后周期将内存中的数据刷新为只读的存储文件。因此读取数据时往往需要遍历多个文件找到当前生效的正确值。随着存储文件不断增加，读性能会因为 IO 增多而下降。对此实现中通常会周期性执行 Compaction 操作将多个文件合并，使文件个数基本稳定，进而稳定读取的 IO 次数，将延迟控制在一定范围内。

在 Lindorm 现有架构中，Compaction 任务的执行和读写请求服务是耦合在一个进程当中的，因为 Compaction 任务会产生很大的带宽、IO 压力，同时也会消耗 CPU 和内存资源，因此容易影响读写请求的响应时长。其次不同业务对 compaction 的需求存在较大差异，读多写少的场景，compaction 任务压力小（元数据存储场景），写多读延迟敏感的场景（风控场景），compaction 任务压力重。难以统一和管理 compaction 任务相关的参数设定。当文件发生大量积压时，因为耦合的因素，无法独立扩容快速消化文件来降低业务风险，展现了当前设计缺乏灵活性的一面。

可以将 Compaction 任务看做周期执行的离线任务，而读写服务是实时在线服务，问题的根节在于离线任务和实时在线任务强耦合在一起，导致两者相互影响，扩缩容不灵活。基于这个洞察，Lindorm 实现了 Offload Compaction 功能，支持 Compaction 任务以独立的进程运行在独立的机器上，一方面服务读写请求的机器不会再因为 compaction 任务的运行产生抖动，另一方面运行 Compaction 任务的机器可以充分利用机器资源，无需担心影响在线服务，更值得一提的是，db 运维可以搭建巨大的 Compaction 任务集群进行统一管理，根据任务的多少按需扩缩容，极大地简化了运维成本。

 Quota 限流

对于数据库系统来说，无论是单机的 mysql 还是分布式的 Lindorm，在底层服务器硬件规模一定的情况下，服务的能力一定是有限的，在多租户的场景下，如果某个租户的请求流量超过数据库的承受极限，很可能会造成数据库服务能力下降，影响该数据库上的其他租户，严重时甚至会造成服务器宕机，这个是非常危险的。因此，一般的数据库系统都有对应的限流方案，当租户的请求流量超过服务能力的时候，对其进行限流，防止影响其他租户。

在不考虑分布式的情况下，限流是比较简单的，限流系统不需要在各个机器间进行协调，只需要记录访问本机的请求，超过阈值就开启限流即可。而在分布式系统中，限流的方案往往比较复杂，涉及到分布式协调等问题。同时，对于一个像 Lindorm 一样的大吞吐的分布式系统，怎么在限流的情况下，不影响正常的请求响应，也是一个难点。

Lindorm 自研了一套分布式限流体系，其具有以下独特之处：

1. 使用 Quota 作为限流单位，用户请求需要处理的数据量越多，消耗 Quota 越多，因此对比 QPS，Quota 更能真实反映请求对系统产生的压力
2. 中心式 QuotaCenter 统一管理 Quota 消耗，即使用户的流量在机器上分布不均匀也能够正常执行限流逻辑
3. Quota 消耗由 QuotaProxy 异步定期汇报，QuotaCenter 不会成为系统的单点，QuotaCenter 的压力与用户请求量无关
4. 用户请求过程中不直接与 QuotaCenter 交互，每次请求只会检查 QuotaProxy 本地缓存的信息，不影响用户的请求响应时间
5. QuotaCenter 弱依赖，QuotaCenter 宕机，不会影响用户请求

未来展望

我们抱着十年磨一剑的心态，从 0 开始打造 Lindorm 这个产品。今年是 Lindorm 在阿里的第十个年头，Lindorm正当壮年，业务驱动是 Lindorm 宽表引擎不变的演进原则。我们将持续为用户提供无缝扩展、高吞吐、持续可用、毫秒级稳定响应、强弱一致性可调、低存储成本、丰富索引的数据实时离线混合存取能力。未来，Lindorm 宽表引擎会在以下几个方向继续前进。

更低的使用成本： 使用成本低是云原生数据库 Lindorm 的一个关键特征。没有最低的成本，只有更低的成本，我们还将继续在低成本这方面深耕，继我们引入 OSS 标准型存储做为冷存后，我们还会引入 OSS 的归档存储，进一步满足用户对更冷数据的存储查询需求。另外，Lindorm 多 AZ 部署给用户带来了跨可用区高可用的能力，但是目前多可用区之间的分片副本数据并没有共享，我们希望利用 Region Replica 的技术使多可用区共享底层存储部分，进一步降低使用成本。

更易用的使用体验：目前，Lindorm 已经全面拥抱 SQL，我们希望使用 SQL 能够给用户带来更加统一的，易用的使用体验。Lindorm 宽表将继续完善 SQL 能力，将宽表已有的能力，比如 FeedStream，WideColumn 等全部接入 SQL。同时像慢请求查询，热点 key 查询，集群运维等相关能力，也计划通过 SQL 的方式暴露给用户，让Lindorm 真正成为一款面向用户的数据库。

更丰富的功能：随着 Lindorm 承载业务的多元化，Lindorm 面对的业务场景也越来越复杂，面对这些业务给Lindorm 带来的挑战，我们必须不断去丰富 Lindorm 的功能去满足这些客户的需求。比如说我们会实现 Blob 存储解决 Lindorm 之前宽表模型在大 kv 存储场景性能不佳的问题，引入 bitmap 类型满足用户画像，人群圈选等场景。支持表快照以满足用户一体化查询分析的需求。

更强的弹性能力：Lindorm 存储分离的架构加上云基础设施的灵活性已经给 Lindorm 带来了非常强的弹性能力，在线扩缩容和升降配能力已经能满足大部分用户需求，但是受限于 ECS 的启停速度，云盘的扩缩容限制，Lindorm 弹性能力并没有达到我们心中“秒级”的标准。因此，Lindorm 在构架新一代部署架构，希望利用大存储池，借助 ECI和 ACK 的力量，真正实现秒级的弹性能力。

另外，我在这里预告一下，Lindorm 宽表引擎即将开源，开源能够将 Lindorm 宽表的技术积累推广到业界，让更多人能使用到 Lindorm 先进的技术。我们也希望能够通过开源的方式，去吸引更多的人来共建 Lindorm，发展技术。Lindorm 即将迈入一个开源的新时代，但是 Lindorm 宽表的初心一直没变：致力于做最好的宽表数据库产品，欢迎对技术感兴趣的各位通过开源的方式一起参与进来。

结束语

梅花香自苦寒来，宝剑锋从磨砺出，Lindorm 每一个功能研发方向都来自于业务真实的需求输入，你们的理解和信任是我们不断前进的动力，没有你们的陪伴和支持，就没有 Lindorm 今天的成果。感谢所有帮助、支持、信任、鼓励、鞭策过我们的同学。我们一定努力做最好的大数据 NoSQL 产品，众志成城、不忘初心、砥砺前行！

原文链接
本文为阿里云原创内容，未经允许不得转载。