2017做网站赚钱,网站建设的总体目标,智慧团建登录,网站建设好的前言
2021 年#xff0c;转眼 Lindorm 已经在阿里发展了十年的时间#xff0c;从基于 HBase 深度改造的 Lindorm 1.0 版本#xff0c;到全面重构#xff0c;架构大幅升级的 Lindorm 2.0 版本#xff1b;从单一的宽表引擎#xff0c;到支持搜索、时序、文件等多种结构化数…前言
2021 年转眼 Lindorm 已经在阿里发展了十年的时间从基于 HBase 深度改造的 Lindorm 1.0 版本到全面重构架构大幅升级的 Lindorm 2.0 版本从单一的宽表引擎到支持搜索、时序、文件等多种结构化数据处理的多模引擎Lindorm 始终保持着快速迭代和升级的速度以满足阿里集团各类业务的数据存储需求。目前Lindorm是公司内部数据体量最大覆盖业务最广的数据库产品之一。
去年在让广大用户看得见、存得起的理念下Lindorm 再次做了品牌升级率先提出了多模超融合数据库概念。Lindorm 不单单是宽表、时序、搜索等引擎的简单堆叠而是在统一的分布式存储引擎之上各个引擎之间互通融合并由统一的 SQL 入口来实现多模数据库的统一访问。
在 Lindorm 一个数据库中用户就可以实现流式计算宽表存储列式索引、时空索引、时序预测、数据订阅以及在各个模型上的复杂分析等多种功能。面对复杂多变的业务以及百花齐放的应用业务不需要面临选型和运维多个复杂数据库的难题数据的整个生命周期都可以在Lindorm 内部各个组件中完成满足用户写入查询分析监控各种需求。 2021年双11Lindorm为手淘互动营销、智能风控、媒体大屏、生意参谋、花呗决策、消费记录等核心系统保驾护航提供集群水位和状态透传产品化能力业务可自行按需伸缩提升备战效率业务支持成本降低80%。云原生Serverless架构升级大促资源按需弹性伸缩资源管理效率提升10倍降本增效。基于存储池化及透明压缩技术最高降低53%存储成本。分布式3AZ架构实现秒级恢复的跨机房强一致容灾能力支撑金融级高可用场景。 而作为 Lindorm 多模数据库中重要一环的宽表引擎目前已经完整经历了 Lindorm 十年的发展其功能、性能、稳定性等方面的诸多创新历经了长时间的大规模实践考验。服务了包括淘宝、天猫、蚂蚁、菜鸟、妈妈、优酷、高德、大文娱等数十个 BU。 Lindorm 宽表融合了阿里巴巴过去十年在大规模宽表技术领域的技术能力和经验并在上云后利用云基础设施实现了云原生化向低成本等方向又有了一些创新和突破进一步构建了海量数据处理场景的竞争力。十年的演进过程中我们实现了跨 AZ 容灾支持了多一致性满足各种业务的需求。支持一体化冷热分离高压缩算法降低用户成本。实现了分布式全局二级索引并和搜索引擎结合推出 SearchIndex 满足用户各种复杂查询需求。十年来我们团队聚焦在宽表领域不断打磨 Lindorm 宽表引擎可谓是十年磨一剑。今年我们又对 Lindorm 宽表的一些功能进行了升级和改造推陈出新真正践行了把简单留给客户把复杂留给自己的理念。
更加易用的功能
Lindorm宽表积攒了一大批面向各类用户的功能比如说SQL二级索引等等。这些功能方便了用户的使用。但是随着业务场景的增加用户对这些功能又提出了一些新的需求。比如之前SQL不支持order by等功能用户在使用时有比较大的局限。面对用户这些槽点Lindorm宽表对功能又做了进一步的增强。
更强大的SQL能力
Lindorm宽表引擎在很早的时候就已经支持了SQL访问相比使用APISQL语言更加简单容易上手深受广大Lindorm开发者的喜爱。并且Lindorm的宽表引擎支持将指定列在搜索引擎中建立倒排索引使用统一的SQL去访问。但是之前的Lindorm SQL还只支持一些简单的SQL DML操作像order bygroup by和join等语法都不支持。今年我们把整个SQL模块都进行了重构重构后的SQL模块将成为Lindorm各个引擎统一的SQL入口并且通过引入了复杂执行器Complex Executor模块把之前不支持的group by等SQL语法都已经支持。现在这套新的SQL引擎还在继续演进我们的目标是在使用统一的SQL接入层访问Lindorm各个模型将不同负载的请求路由到合适的组件中。 更加安全的数据
数据安全是企业的生命线Lindorm上的很多客户在Lindorm宽表内存储了很多敏感数据特别是金融客户由于监管需求所有涉及到用户和订单的数据都必须加密传输和加密存储。因此Lindorm在已有的用户名密码权限的基础上又加入了多重加密功能以及审计日志等功能满足这类企业级用户需要。
透明加密
云上客户和集团客户的区别之一就在于其丰富的行业特性。金融领域和国家机构这两类客户在进行数据库产品选型时都对数据库的安全性表现出了强烈的兴趣。并且纵观云计算领域Azure 的 cosmosDBAWS 的 DynamoDB阿里云的 OSSRDS 都具备静态数据加密的能力缺乏安全方面的功能特性有时会直接失去进入某个行业的入场券。
当今数据库面临的安全威胁大致可以分为 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 自研了一套分布式限流体系其具有以下独特之处
使用 Quota 作为限流单位用户请求需要处理的数据量越多消耗 Quota 越多因此对比 QPSQuota 更能真实反映请求对系统产生的压力中心式 QuotaCenter 统一管理 Quota 消耗即使用户的流量在机器上分布不均匀也能够正常执行限流逻辑Quota 消耗由 QuotaProxy 异步定期汇报QuotaCenter 不会成为系统的单点QuotaCenter 的压力与用户请求量无关用户请求过程中不直接与 QuotaCenter 交互每次请求只会检查 QuotaProxy 本地缓存的信息不影响用户的请求响应时间QuotaCenter 弱依赖QuotaCenter 宕机不会影响用户请求未来展望
我们抱着十年磨一剑的心态从 0 开始打造 Lindorm 这个产品。今年是 Lindorm 在阿里的第十个年头Lindorm正当壮年业务驱动是 Lindorm 宽表引擎不变的演进原则。我们将持续为用户提供无缝扩展、高吞吐、持续可用、毫秒级稳定响应、强弱一致性可调、低存储成本、丰富索引的数据实时离线混合存取能力。未来Lindorm 宽表引擎会在以下几个方向继续前进。
更低的使用成本 使用成本低是云原生数据库 Lindorm 的一个关键特征。没有最低的成本只有更低的成本我们还将继续在低成本这方面深耕继我们引入 OSS 标准型存储做为冷存后我们还会引入 OSS 的归档存储进一步满足用户对更冷数据的存储查询需求。另外Lindorm 多 AZ 部署给用户带来了跨可用区高可用的能力但是目前多可用区之间的分片副本数据并没有共享我们希望利用 Region Replica 的技术使多可用区共享底层存储部分进一步降低使用成本。
更易用的使用体验目前Lindorm 已经全面拥抱 SQL我们希望使用 SQL 能够给用户带来更加统一的易用的使用体验。Lindorm 宽表将继续完善 SQL 能力将宽表已有的能力比如 FeedStreamWideColumn 等全部接入 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 产品众志成城、不忘初心、砥砺前行
原文链接 本文为阿里云原创内容未经允许不得转载。
