降本增效创未来——云原生多模数据库Lindorm 2022双11总结

1. 前言

2022年是多模数据库 全面支撑集团双11大促的第五个年头。在这五年中， 架构从基于 HBase 深度改造的 1.0 架构版本演进到了当前统一在同一个分布式文件系统之上融合了多种存储引擎、数据模型的 2.0 架构版本。目前 也在朝着云原生、一体化、更紧密的多模融合方向孕育着新一代架构演进。

过去十多年，得益于内部业务对 持续的需求牵引，推动了 不断的技术演进和体验提升，全面服务于淘宝、天猫、支付宝、网商、菜鸟、阿里妈妈、高德、优酷、钉钉、大文娱等各个业务板块，满足应用对于海量结构化、半结构化数据的存储处理需求，目前 在内部已部署超4万个节点，数据规模超500PB。

在2022年双11中， 全天平稳运行，日吞吐量39.1万亿次，平均响应时间低于3毫秒，其中读请求峰值3.68亿次/秒，写请求峰值2.22亿次/秒，有效支撑了双11指挥室大屏、手淘消息、物流轨迹等核心场景。同时，今年是 在云上商业化的第二个年头，在诸多外部客户的双11战役中也逐渐发挥越来越大的作用。

纵观整个2022年，内外大环境都发生了剧烈的变化。同时随着阿里云数据库“四化”战略的提出，作为一款阿里云自研的云原生多模数据库产品，将如何向着“云原生化”，“平台化”，“一体化”，“智能化”进一步演进，也是 当今发展过程中需要不断去抬头对齐的目标，希望通过本文的梳理总结，可以有助于我们更清晰地向未来前进。

2. 问题与挑战

2022年全年的经济形势呈现出不稳定的态势，这迫使整个互联网行业都要从以往大开大合式的发展逐步走向精耕细作式的发展。因此在经济大环境的影响下，整个2022年可以很明显地感受到来自以下几个方面的重点需求：

2.1 业务降低成本的需求

互联网的精耕细作首先体现在对降低成本的追求上。在大规模数据库的运用中，通常数据存储成本便会占到整个数据库使用成本的50%以上；同时，在追求低成本的压力之下，客户业务也会追求以成本更低的CPU、内存资源完成与以往同等水平的运算能力。

以集团业务为例，2022年开年开始，各个BU的成本压力都很巨大，很多 使用方都表达了降低成本的诉求，代表性需求如下：

出于2022年整体经营需要降本增效的目标，希望使用 的场景可以做到在线服务能力不变的情况下，成本下降20%以上。

IoT 平台重度依赖时序数据库的使用，满足亿级设备的高并发吞吐写入需求，在新财年的成本压力下，需要在承接住日益增长的线上负载以及新增功能需求的同时，将使用成本降到原先的1/2以下。

2.2 企业提高效率的需求

随着人力资源的吃紧，越来越多的客户希望更加聚焦于自身业务的开发，而减少对基础设施使用和维护的人力投入，内外客户也开始将搬站上云当成一种增效降本的选择。典型地，在大数据存储与处理领域，许多互联网公司都会首选 HBase、/Spark 作为它们的大数据解决方案，但是 HBase 以及 生态的技术复杂度，使得企业的应用维护难度较大，期望能在云端找到平滑替换方案，提升效率，代表性需求如下：

作为全集团采集&流量分析一站式服务平台，为了更好的升级A+产品，对老A+进行全新升级，解决老A无法迭代、运维困难等问题。特别是原本数据存储使用 HBase+ 的架构由于社区不够活跃，迭代和维护难以为继。迫切希望能够寻找新的方案既能无缝迁移已有的HBase 数据，又能提供足够的SQL能力支撑平台后续的功能迭代。

不少互联网客户过去投入大量研发资源支撑起大规模自建 HBase 和 集群的运用与维护，但随着整体公司研发战略的调整，人力投入大幅减少，同时在遇到问题时很难从社区获取的足够技术支持，期望能有一种更高人效的方案支撑现有业务。

2.3 技术上的挑战

在阿里内部经过十多年的历练打磨，其成熟稳定的能力能够很好匹配业务对于海量数据管理的高效、低成本的需求，一方面， 脱胎于 HBase 的底层技术，加入了大量的自研核心技术使得能以更优的性价比去引导客户将应用从自建的 HBase 搬迁到云上 ；另一方面， 的多模融合设计理念能够有效降低业务的研发使用成本以及运维难度。

但同时，上述两类业务需求也对 提出了更高的要求与挑战：

如何通过技术手段进一步切实地降低大规模数据的存储成本。如何满足外部互联网企业上云的同时兼容开源标准避免锁定在特定云厂商的苛刻要求。如何让业务更加简单便捷地接入从而提升效率。如何提升在不同业务场景下的吞吐性能。

3. 的能力演进回顾

围绕着上文中提出的技术挑战， 在整个2022年度针对降本、提效两个方面进行了一系列能力建设：

3.1 降本方面的能力建设

3.1.1 字典压缩实现无感降本

宽表是基于 LSM-Tree 引擎构建数据存储。在单个 文件内部，天然就适合使用压缩算法压缩分块，降低空间占用节省成本。 宽表引擎在通用压缩算法上更进一步，结合 ZSTD 深度定制，推出了字典压缩能力。

内部会自动提取数据样本采样分析，根据数据特质，智能选择合适的编码压缩参数，并提取公共字典，消除压缩算法中的字典结构带来的额外开销，进一步提升了数据的压缩比率与压缩速度。同时，字典压缩的开启对业务无感，无需业务改造，用户只需要变更表配置，即可获得更高的压缩率。字典压缩在集团内与公共云上被大量应用，帮助业务降低成本。

落地案例

3.1.2 本地盘HDD与ESSD异构副本

面向海量数据(>100TB)低成本存储的需求，通过 HDD本盘 ECS 构建 实例，仍然是业务最具性价比的选择。本地盘大数据型 ECS 的存储与计算可被 完全使用，资源利用率更高。

始终坚持云原生，充分挖掘云的弹性能力，催生出了新的 存储形态：本地盘 ECS 上挂载 ESSD，通过 异构副本实现1副本 ESSD+2HDD 冗余，并结合多模引擎层冷热分离的内核能力，实现业务成本的显著优化。

举一个具体点的应用例子：业务每天产生800G轨迹信息，需要保存1年，总数据量约300T。最近1周内的数据作为热数据，会被频繁地在线查询；而一周后的数据则视作冷数据，查询频率较低。在 本地盘实例上其存储机制如下：

落地案例

宽表通过多种开源标准API支持开源日志系统Loki的数据存储。日志包数据以 Blob形式存放，通过 S3 API 访问。索引数据以表格行存形式存放，通过CQL协议访问。面对 Loki最近一小时数据的突发海量数据拖取查询，利用 ESSD云盘异构副本能力对一小时内写入数据进行加速，解决HDD带宽和iops能力不足的问题。峰值流量翻倍。

3.1.3 时序数据专用压缩算法

时序引擎内核层借助 TSM 架构（面向时序数据特征设计的类似 LSM Tree 架构）实现了时序数据的高效写入，并采用定制的时序压缩算法达到了更优的数据压缩比。

在 TSM 架构中，用户数据会先写入WAL文件和内存 中，一旦 写满后，会开启一个新的 来写入新的数据，同时旧的 会 flush 到磁盘，成为 。 是一种时序定制化的文件格式，通过 Delta-of-Delta、Xor、、RLE等压缩算法对时序数据进行高效压缩，随着 的进行，数据的压缩率也便会进一步提升，最高可达15:1的压缩率比。

落地案例

在阿里云物联网平台的应用场景中，底层的时序数据存储由早先的 TSDB 2.0 架构升级到 时序引擎后，得力于专用时序压缩算法的高压缩率，整个方案的成本节省了50%以上。

3.1.4 面向海量时间线的性能提升

时序场景中一个常见的课题是随着时间的推移往往会产生海量的时间线，给时序数据库的查询带来巨大挑战。具体而言，会体现在以下三种典型场景：

对于时序引擎，如何解决监控场景下海量时间线的索引效率、长周期查询、海量时间线实时聚合问题一个业界共通的挑战。

时序引擎提供了如下几个技术手段来应对这些难题：

借助上述能力的建设，实现了海量时间线业务中查询性能的提升，解决了时序应用场景中一类共性问题。

落地案例

某互联网社交平台的业务监控场景中，用户有3-4亿的活跃时间线实时写入，单次查询命中多达百万时间线秒级返回。用户由自建的 Durid 迁移到 后，查询响应延时大幅降低，成本节省50%以上。

3.2 提效方面的能力建设

3.2.1 深度兼容HBase通信协议

是发源于 HBase 的自研 NoSQL 数据库产品，并最终在性能、成本、稳定性上都优于原生的 HBase。不过 HBase 仍是开源技术领域中提供海量数据存储服务的代表性 NoSQL产品， 为了更好的服务这个市场，在产品研发的早期便通过客户端兼容的方式提供了一个兼容 HBase 标准API 的 SDK 满足基于 HBase API 的应用低成本接入 的需求。

这个技术方案对于习惯 HBase 技术栈的开发人员编写新的业务是一个绝佳的方案，但是在搬山上云的场景下也逐渐暴露出若干缺点：

针对这些需求， 设计并实现了协议级别的深度兼容，通过增加一个 HBase Proxy 模块完全支持 HBase 的原生协议。

该方案相对于 的原生客户端，读写链路上新增了一个代理，因此整体链路会多一个环节。但是得益于 多年以来持续的性能优化，并且通过短路优化技术，将兼容开源HBase 客户端直连场景的性能优化至与使用 原生客户端的场景持平。帮助用户在实现 HBase 无缝搬站的同时，也可享受到 在阿里集团内沉淀多年的性能优势。

落地案例

3.2.2 更加高效易用的SQL能力

的 SQL 能力经过这两年的发展已经初具规模，随着 各个引擎之间的融合程度越来越高， 的 SQL 引擎也将作为 产品的统一接口去承接对各个引擎的数据访问。

但是 SQL 作为执行 OLTP 型业务的接口，其能力的完备度早先存在一些不足。比如，对于在线业务中常见的小范围 ORDER BY、GROUP BY 这样的计算时常会触发全表扫描，导致性能不高。针对这样的问题， 的 SQL 与存储引擎紧密结合，基于存储引擎提供的数据近端计算能力，在优化器中进行了深度的优化，实现了大量计算能力的下推。比如在与宽表引擎协同时实现排序、分组聚合的下推；在与时序引擎协同时实现了时间线扫描、降采样等特色计算能力的下推，使得查询中流入 SQL 引擎的结果量级大幅下降、SQL引擎查询计划的节点深度减少，实现了查询性能的提升。

落地案例

集团A+业务的架构升级项目中，基于 SQL 的 Ads 结果存储场景选择了使用 替换原有的 + HBase 的方案。同等计算资源下查询性能得到了提升的同时，成本降低为原先的1/2。同时，全面采用 SQL 能力，支撑了平台迭代开发分析洞察、URL 搜索、留存分析等能力。

3.2.3 更加丰富的数据类型

随着万物互联时代的到来，智能互联化是一个不可逆转的趋势，存在了百年之久的汽车行业在以下哪个场景中推荐使用wisp，也在物联网时代焕发出新生。在新兴的车联网领域中有以下三类不同的参与者，他们都面临着不同的痛点：

在这些需求的背景下， 通过融合多种引擎的能力，提供了以下功能，很好地解决了上面的问题：

此外， 使用 SQL 统一了结构化、半结构化、非结构化数据的使用体验，用户只需要在 中建立一张宽表，通过指定不同列的类型在以下哪个场景中推荐使用wisp，即可完成对不同结构数据的写入、查询和检索。比如在下面的例子中，在一张表里就可以同时使用基础类型、JSON、BLOB、Geo 等多种类型。

CREATE TABLE vehicle_data ( vehicle_id VARCHAR, vtime BIGINT, vender VARCHAR, vevent JSON, vloc GEOMETRY(POINT), blf_data BLOB, PRIMARY KEY (vehicle_id, vtime)) WITH (NUMREGIONS='256');

落地案例

3.2.4 更加高效的离线数据导入

从 Hive 等离线数仓导入数据至 是业务高频使用的一个场景，在早期预置资源的模式下， 导入服务所需的资源规模的评估对客户来讲是一个头疼的问题，买少了任务跑的时间长，买多了资源浪费。这是因为离线导入通常是周期性的任务，比如 T+1 或者 H+1，在预置资源的模式下，相当一部分时间资源在空转。

在此背景下我们上线了新版本的通用导入服务，它基于 弹性计算引擎可以做到按量付费，当没有导入任务时不计费，只有任务启动后才根据资源使用计费。另一方面，极致弹性也提升了单个任务的运行效率，原来可能需要100个CPU运行10个小时，现在1000个CPU只需跑1小时，在成本不变的情况下靠弹性提升了10倍的性能。整体看，新版本的 导入服务 LTS，通过按量付费+弹性计算的能力，实现离线数据导入的降本增效。

落地案例

在某社区搜索场景，业务需要每日执行数据的离线导入。LTS 基于 计算引擎提供的云原生弹性能力，可以按需配置资源以整体较低的成本高性能地完成数据导入。

4. 未来的展望

新的一年， 将继续围绕“云原生化”，“平台化”，“一体化”，“智能化”战略，将 内的各引擎和数据模型融合处理的统一性更加完善，同时落实新一代的 架构设计，推动 DB4AI 技术在 产品上的实现。为集团内外的客户提供更低的成本，更便捷的使用体验，更高的业务构建效率。真正做到“存得起，看得见”。

5. 结束语

的发展，离不开所有客户的鼓励与鞭策，也离不开技术同仁的宣传与推广。感谢各位的支持，也欢迎大家继续给我们提出各种建议，我们一定努力做最好的大数据 NoSQL 产品，众志成城、不忘初心、砥砺前行！

云原生多模数据库多模数据库_工业物联网_数据库-阿里云

本文到此结束，希望对大家有所帮助。