前言
年，转眼Lindorm已经在阿里发展了十年的时间，从基于HBase深度改造的Lindorm1.0版本，到全面重构，架构大幅升级的Lindorm2.0版本；从单一的宽表引擎，到支持搜索、时序、文件等多种结构化数据处理的多模引擎，Lindorm始终保持着快速迭代和升级的速度，以满足阿里集团各类业务的数据存储需求。目前，Lindorm是公司内部数据体量最大，覆盖业务最广的数据库产品之一。
去年，在让广大用户看得见、存得起的理念下，Lindorm再次做了品牌升级，率先提出了多模超融合数据库概念。Lindorm不单单是宽表、时序、搜索等引擎的简单堆叠，而是在统一的分布式存储引擎之上，各个引擎之间互通融合，并由统一的SQL入口来实现多模数据库的统一访问。
在Lindorm一个数据库中，用户就可以实现流式计算，宽表存储，列式索引、时空索引、时序预测、数据订阅，以及在各个模型上的复杂分析等多种功能。面对复杂多变的业务，以及百花齐放的应用，业务不需要面临选型和运维多个复杂数据库的难题，数据的整个生命周期都可以在Lindorm内部各个组件中完成，满足用户写入，查询，分析，监控各种需求。
年双11，Lindorm为手淘互动营销、智能风控、媒体大屏、生意参谋、花呗决策、消费记录等核心系统保驾护航，提供集群水位和状态透传产品化能力，业务可自行按需伸缩，提升备战效率，业务支持成本降低80%。云原生Serverless架构升级，大促资源按需弹性伸缩，资源管理效率提升10倍+，降本增效。基于存储池化及透明压缩技术，最高降低53%存储成本。分布式3AZ架构，实现秒级恢复的跨机房强一致容灾能力，支撑金融级高可用场景。
而作为Lindorm多模数据库中重要一环的宽表引擎，目前已经完整经历了Lindorm十年的发展，其功能、性能、稳定性等方面的诸多创新历经了长时间的大规模实践考验。服务了包括淘宝、天猫、蚂蚁、菜鸟、妈妈、优酷、高德、大文娱等数十个BU。
Lindorm宽表融合了阿里巴巴过去十年在大规模宽表技术领域的技术能力和经验，并在上云后，利用云基础设施，实现了云原生化，向低成本等方向又有了一些创新和突破，进一步构建了海量数据处理场景的竞争力。十年的演进过程中，我们实现了跨AZ容灾，支持了多一致性满足各种业务的需求。支持一体化冷热分离，高压缩算法降低用户成本。实现了分布式全局二级索引，并和搜索引擎结合推出SearchIndex满足用户各种复杂查询需求。十年来，我们团队聚焦在宽表领域，不断打磨Lindorm宽表引擎，可谓是十年磨一剑。今年我们又对Lindorm宽表的一些功能进行了升级和改造，推陈出新，真正践行了把简单留给客户，把复杂留给自己的理念。
更加易用的功能
Lindorm宽表积攒了一大批面向各类用户的功能，比如说SQL，二级索引等等。这些功能方便了用户的使用。但是随着业务场景的增加，用户对这些功能又提出了一些新的需求。比如之前SQL不支持orderby等功能，用户在使用时有比较大的局限。面对用户这些槽点，Lindorm宽表对功能又做了进一步的增强。
更强大的SQL能力
Lindorm宽表引擎在很早的时候就已经支持了SQL访问，相比使用API，SQL语言更加简单容易上手，深受广大Lindorm开发者的喜爱。并且，Lindorm的宽表引擎支持将指定列在搜索引擎中建立倒排索引，使用统一的SQL去访问。但是，之前的LindormSQL还只支持一些简单的SQLDML操作，像orderby，groupby和join等语法都不支持。今年，我们把整个SQL模块都进行了重构，重构后的SQL模块将成为Lindorm各个引擎统一的SQL入口，并且通过引入了复杂执行器（ComplexExecutor）模块，把之前不支持的groupby等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的自愈能力，解放运维人员的压力，加强系统稳定性。
OffloadCompaction
基于LSM-Tree架构的分布式数据库，对于数据写入并不会原地更新，而是先写入内存，然后周期将内存中的数据刷新为只读的存储文件。因此读取数据时往往需要遍历多个文件找到当前生效的正确值。随着存储文件不断增加，读性能会因为IO增多而下降。对此实现中通常会周期性执行Compaction操作将多个文件合并，使文件个数基本稳定，进而稳定读取的IO次数，将延迟控制在一定范围内。
在Lindorm现有架构中，Compaction任务的执行和读写请求服务是耦合在一个进程当中的，因为Compaction任务会产生很大的带宽、IO压力，同时也会消耗CPU和内存资源，因此容易影响读写请求的响应时长。其次不同业务对