双11峰值每秒8.8亿次请求！Lindorm数据库：让数据存得起，看得见

 今天为大家带来五号武器--云原生多模数据库Lindorm。

 

■ 一、引言 

2020双十一顺利落下帷幕，这也是云原生多模数据库Lindorm参与的第九个双十一，其作为阿里经济体的核心数据库产品之一，全面支撑了淘宝、天猫、蚂蚁、菜鸟、阿里妈妈、高德、优酷、钉钉、大文娱等经济体业务的结构化、半结构化数据存储需求，今年更是为申通这样的公有云用户保驾护航。

在今年的双十一中，Lindorm整体峰值请求达到了8.8亿次每秒，全天吞吐25万亿次，平均响应时间低于3ms，数据存储量达400+PB，平均压缩率达5:1，应用在阿里集团、蚂蚁集团、菜鸟、大文娱等各个业务板块，是目前为止公司内部数据体量最大、覆盖业务最广的数据库产品。

 

■ 二、云原生多模数据库Lindorm 

面对多模数据管理的应用需求和云原生的技术趋势，着眼于集团云原生战略、5G/IoT时代的未来发展，Lindorm在2020年全新升级为适用于任何规模、多种模型的云原生数据库服务，支持海量数据的低成本存储处理和弹性按需伸缩，提供宽表、时序、搜索、文件等多种数据模型，兼容HBase、Cassandra、Phoenix、OpenTSDB、Solr、SQL等多种开源标准接口，是互联网、IoT、车联网、广告、社交、监控、游戏、风控等场景首选数据库。

 

Lindorm融合了阿里巴巴过去十年在大规模宽表、时序存储等领域的技术能力和经验，同时今年重点在云原生、多模融合、低成本等方向创新突破，进一步构建海量数据存储处理场景的竞争力，并通过集团云原生上云战役，实现了一套产品同时服务内外客户，提供稳定、高效、经济的基础数据库服务。

■ 三、Lindorm面临的双十一挑战 

 

3.1 拥抱云原生

 

云原生上云带来的基础设施的云化共池，不仅很好的解决成本与库存孤岛问题，也极大的提升了我们的运维效率，免去了过去复杂的IaaS运维开销。同时云原生三机房强一致容灾能力首次上线，并在过去一年进行了10+次的断网演习，确保了机房级别的容灾快恢能力，夯实了底盘能力的同时，内外一致的产品技术栈也增强了我们服务公用云客户的信心。

 

物理机转变到ECS的形态：ECS具备极强的故障自检测恢复能力，借助于ECS的主动运维事件透传，结合数据库云管控平台以及Lindorm内核的联动，提前感知潜在的ECS节点故障并自动处理下线，减小ECS宕机对我们服务的影响。同时针对NC故障多台同集群ECS受影响宕机，我们提前感知拓扑以及巡检进行ECS的反亲和性打散，避免NC故障导致的故障半径放大。

 

大规模上云也面临着海量数据搬迁的效率和稳定性挑战，Lindorm在经济内是众多离线、在线业务数据互通很好的一个载体。业务搬迁透明无感知、服务不中断是我们的原则，在这过程中我们通过磨炼LTS（Lindorm Tunnel Service）产品能力解决多种异构产品之间无缝迁移的问题，使lindorm中存储的海量数据真正的灵动起来。

 

3.2 存储成本的挑战

 

在Lindorm全面拥抱云原生过程中，我们看到了基于云存储技术的多样化的块存储、对象存储等原子存储能力，我们期望基于云存储资源构建新的数据库存储技术的形态，通过云原生技术的虚拟化、弹性、按需使用等特质，实现存储计算分离解耦，提高资源使用率，降低Lindorm的总体TCO。

 

同时，我们看到数据往往呈现出一定的活跃周期规律。将访问频率低，生命周期长的的数据沉淀到低成本存储中，并辅以更高压缩比的压缩策略来降低总体存储成本。我们基于不同种类的云存储能力，将冷热温冰不同性价比的存储资源集成到一套系统中，构建一体化的存储体验。并提供基于用户规则、基于智能判断的策略，使得数据在Lindorm中可以自动进行冷热分离。

 

3.3 核心链路高可用、稳定性的挑战

 

目前Lindorm在集团生态体系下服务了大量核心场景，包括支付宝交易风控、花呗决策、消费记录，GMV媒体大屏，Sunfire监控，手淘消息，阿里小蜜，物流详情等核心系统。与此同时，Lindorm也服务了大量的中小用户，这些用户成本更加敏感，业务的不可控性更多，很容易出现大查询打爆物理资源，多业务相互影响等情况，造成用户体验变差。

 

过去HBase提供的容灾恢复能力，单机宕机时产生的影响会在3~5分钟左右，在目前内部的可用性要求下，核心业务很容易出现故障。过去一年，我们从技术演进，部署形态和业务改造三方面全面推进Lindorm的高可用建设：

 

技术上：Lindorm持续进行可用性改造和演练，利用数据多内存副本能力，在故障发生时进行自动容灾切换。双机房最终一致场景实现10秒内自动容灾，三机房强一致场景实现30s自动恢复。针对用户经常出现的大请求，分区倾斜，单行热点等场景，Lindorm内核侧也开发了大请求调度，单region并发flush，热点识别等能力，大大降低了因为用户请求不合理造成的业务影响。

 

部署上：推进云原生三机房强一致容灾，在用户成本无增加的情况下保证了机房级断网0 RPO，60s RTO。同时推出Serverless服务模式，多业务在资源上共享降低成本，通过限流，调度，弹性扩缩容等方式进行逻辑隔离，减少用户之间的相互影响。

 

业务侧：推动Hbase核心业务全面向Lindorm升级，目前全网的Lindorm规模10000+节点，全域的SLA服务能力大幅提升。

3.4 海量离线数据的批量导入性能的挑战

 

如何在有限资源情况下支撑数倍流量增长是Lindorm数据回流场景在双十一面临的最大挑战。一方面很多重要业务的批量导入任务在大促峰值期间会执行降级预案并持续数小时，业务峰值过后，导入任务在双十一当天的产出时间仍然需要保障，因此很多任务需要以数倍的速度去追。另一方面导入集群的日常水位已经接近饱和，CPU使用率超过80%，但整体上资源预算已经非常紧张，扩容所需资源缺口太大。为了应对这一挑战Lindorm团队打响性能攻坚战役，对导入全链路进行优化迭代，最终实现4倍性能提升。特别的在大促当天，风控导入集群资源不变，总量上涨百分之50的情况下，任务运行时间缩短为三分之一。

 

Lindorm支撑Velocity 2.0架构平稳度过双十一，批量回流链路的极致性能优化，为下一代风控业务发展保驾护航。在整个性能优化过程中团队也沉淀了RowAwareHfileWriter，MultiClusterFSDataOutputStream等专利，陆续还会在CPU cache、异步化等方面发布新的优化版本。

 

■ 四、Lindorm全新关键技术 

 

4.1 融合多模

 

过去原生的HBase只支持KV结构的查询，对于一些复杂的业务场景，如二级索引、搜索、时序等需求，需要借用第三方组件组合实现，大幅增加业务的复杂度。

 

Lindorm支持宽表、时序、搜索、文件四种模型，提供统一联合查询和独立开源接口两种方式，模型之间数据互融互通，帮助应用开发更加敏捷、灵活、高效。提供一处写入，处处可用的能力。同时，Lindorm为开发者提供CQL Driver、Phoenix Driver、HBase API、HDFS API、OpenTSDB API、Solr API、Lindorm API、Lindorm SQL等多种访问方式，方便存量业务无缝切换至Lindorm，其核心能力由四大引擎提供，包括：

• 宽表引擎，面向海量KV、表格数据，具备全局二级索引、多维检索、动态列、TTL等能力，适用于元数据、订单、账单、画像、社交、feed流、日志等场景，兼容HBase、Phoenix(SQL)、Cassandra(CQL)等开源标准接口。
• 时序引擎，面向IoT、监控等场景存储和处理量测数据、设备运行数据等时序数据。提供HTTP API接口(兼容OpenTSDB API)、支持SQL查询。针对时序数据设计的压缩算法，压缩率最高为15:1。支持海量数据的多维查询和聚合计算，支持降采样和预聚合。
• 搜索引擎，面向海量文本、文档数据，具备全文检索、聚合计算、复杂多维查询等能力，同时可无缝作为宽表、时序引擎的索引存储，加速检索查询，适用于日志、账单、画像等场景，兼容开源Solr标准接口。
• 文件引擎，面向海量非结构化数据，具备弹性低成本、100%HDFS协议的文件存储能力，与多模引擎共享存储，同时支持外部系统直接访问多模引擎的底层文件，适用于大数据分析、数据湖等场景，可使用开源HDFS客户端直接访问。

 

Lindorm支持多个模型之间的融合打通，包括数据同步、模型转换、统一访问、统一管理、资源共享等能力，从而将多个系统组合使用的解决方案下沉为数据库内置能力。对于目前使用类HBase+ElasticSearch或HBase+OpenTSDB+ES的应用场景，比如监控、社交、广告等，利用Lindorm的原生多模能力，将很好地解决架构复杂、查询痛苦、一致性弱、成本高、功能不对齐等痛点，让业务创新更高效。

4.2 让数据存得起-极致性价比

 

4.2.1 智能压缩

 

基于LSM-Tree的数据存储，如HBase，在组织文件内容时经常使用数据分块编码压缩的方式，降低数据文件的空间占用以减少存储成本。Lindorm在这项技术上更进一步，Compaction前提取数据样本进行采样分析，根据数据特质，智能选择合适的编码、压缩参数，并提取公共字典，降低压缩算法中的字典结构带来的额外开销，进一步提升了数据的压缩比率与压缩速度。

4.2.2 冷热数据一体化存储

 

对于类似账单这种永久保存的场景，每年数倍的存储增长，无论是分库分表后扩容或者历史库冷数据的搬迁，都存在较大的运维成本、一致性风险、并且对业务的侵入性较大。

 

云原生的场景下，Lindorm在同一张表里实现了数据的冷热分离，系统会自动根据用户设置的冷热分界线自动将表中的冷数据归档到冷存储（SSD、高效、OSS等多层存储）中。在用户的访问方式上和普通表几乎没有任何差异，在查询的过程中，用户只需配置查询Hint或者TimeRange，系统根据条件自动地判断查询应该落在热数据区还是冷数据区。对用户而言始终是一张表，对用户几乎做到完全的透明。成本最低化。

4.2.3 容量型存储

 

容量型存储是Lindorm今年新推出的一种虚拟化存储形态。基于对象存储的低成本特质，我们将对象存储作为一块共享磁盘看待，将对象存储能力融合到LindormStore的内部数据库块管理机制中，在上层依然保持文件系统的全部功能以及API语义，在保持HDFS通信协议兼容的同时，使得对象存储的低成本能力被无缝集成到Lindorm。相比云盘双副本存储方案，容量型存储降低了80%的存储成本。更加适合历史日志、历史订单等冷数据归档场景。

4.2.4 共享块存储降副本

 

云盘技术是云原生存储的代表之一，云盘以块设备为交互界面，提供了强大的按需使用的弹性扩展能力。但是原生HDFS没有很好的和云盘结合，HDFS本身的多副本与云盘底层的多副本技术重叠，造成了实际存储资源的浪费。LindormStore基于共享块存储（DBFS）开发了一写多读共享技术，使得LindormStore在块存储上只需写入一份数据，就可以保证数据可靠性与可用性。共享块存储的弹性扩展，动态挂载/卸载等能力，助力Lindorm实现存储计算分离解耦，使得Lindorm在不搬运数据的基础上实现计算与存储资源配比动态调整成为可能。

4.2.5 存储计算解耦

 

基于4.2.3与4.2.4的云原生存储技术，我们使得计算资源与存储资源彻底解耦，存储资源与计算资源的独立扩容成为可能。我们不再困惑于传统HDFS生态中的买多少计算节点，每个节点配多少存储的资源规划问题。LindormStore相当于一个云原生存储网关，数据实际存放在虚拟化的云存储资源池中，LindormStore提供HDFS兼容的功能语义与访问接口。业务可以根据自身需要调节Lindorm的存储与计算比例。存储计算解耦带来了更高的资源利用比例，减少了传统IDC时代的机器资源存算比浪费。存储与计算按需配置，为业务带来更高性价比的资源规划能力。

 

4.2.6 ServerLess

 

单纯的独享部署和资源售卖的形态无法满足所有用户的需求。特别对于请求量特别低或者波峰波谷非常明显的用户，他们希望有比ECS物理资源更细粒度的弹性能力。因此，我们推出了全新的Serverless模式，Serverless是体现云计算按需计费，极致弹性的最好形式。利用Serverless，用户可以使用申明式的API定义对数据库资源的要求，不需要为未知的业务流量去预估存储和计算资源。同时，Serverless可以真正实现全托管，用户无需再关心容量水位，软件版本等集群管理问题，让用户的精力完全收敛于业务开发。

 

在Serverless模式下，用户可以做到0请求0费用，而当业务流量突然增加时，Lindorm自身的弹性能力和Serverless大资源池共享的模式可以为用户提供极致的弹性体验。而在多租户隔离上，Lindorm原生的多租户，Quota限流能力能够保证各个Serverless各个租户能够不会相互影响。使用户的成本，稳定性，弹性达到一个完美的平衡。

4.3 让数据看得见-丰富索引

 

4.3.1 二级索引

 

Lindorm表天然具备主键索引，可以很好的满足主键匹配，主键前缀模式的查询需求。为了解决了绝大多数NoSQL系统查询非主键条件效率低下的问题，在诞生之初Lindorm就引入了全局二级索引，并对TTL，多版本等松散Schema结构提供了很好的支持。Lindorm二级索引目前除了可以通过SQL-like API访问，也可以通过Cassandra Query Language，Lindorm SQL等多种方式读写，大大降低了用户的使用成本。

 

4.3.2 全文索引

 

全局二级索引很好的解决了用户固定访问模式的查询需求，但对于多维组合查询存在成本高，不够灵活的缺点。过去很多用户自行搭建HBase+ES/Solr的解决方案，通过搜索引擎查询rowkey，再通过rowkey返查获取完整数据。这套方案尽管较好的解决了查询的问题，但依然存在数据同步复制延迟不可控（极端情况下丢数据），查询方式复杂，DDL变更导致数据错乱等问题。

Lindorm推出原生全文检索能力，利用Lindorm Tunnel Service可以全自动完成DDL，数据的同步异步构建。与此同时Lindorm CQL还提供了统一查询能力，基于用户查询条件在编译时决定是否需要通过搜索进行加速，无需用户自行判断，大幅优化了用户的使用体验。

4.4 智能化服务

 

目前lindorm服务了经济体以及公有云上万的开发者，过去的一年我们也围绕着服务自助化、运维智能化、运营数据化的目标，全新打造LDInsight工具产品服务，降低使用lindorm的门槛以及提升运维效率。LDInsight具备了信息透视、系统管理、智能诊断等功能，帮助应用开发者/DBA轻松掌握系统运行状态，白屏化完成常见系统管理和数据访问操作，以及自动诊断使用过程中的常见问题，让用户和维护者更加简单、高效地使用Lindorm，减少服务对人的依赖。

 

4.4.1 智能诊断

 

为了让应用开发者/DBA更放心的使用lindorm，LDInsight 提供了7*24小时的数据库异常诊断功能，自动诊断生产运维过程中的常见问题、排除潜在风险，比如慢请求、热点、性能诊断、Schema设计、索引推荐等，让用户和DBA更加简单、透明、高效地使用Lindorm。

 

LDInsight 会秒级收集各项关键指标信息作为某个时间点的性能数据快照，我们会先结合DBA 的专家经验将关键指标进行分类，接着分析出每个指标的规律性（周期性、平稳性、还是趋势性等），最后根据指标的不同规律，应用混合模式的时序数据异常检测模型对指标进行智能化的分析与归纳，从而增强异常发现的成功率。

目前LDInsight已在全网部署对所有开发者开放使用。

 

4.4.2 热点识别与自愈

 

在支持海量数据在线高并发查询的场景中，业务中天然存在着突发的热点商品促销、大V直播带货等场景，在热点的识别设计上，我们运用Sketch-Counting算法统计高频访问的Key，其核心思想是抛弃低概率的key的详细信息，仅保留高概率访问的信息并进行Sketch树状扩展，层层逼近真正热点，无需对每个输入key采样收集，可以极小内存与计算开销统计出热点，通常运行时单机单表仅占用500B内存，运行时常态开启实时监测热点。同时再结合Insight控制系统，自动快速隔离热点，避免影响全局服务。

4.5 数据链路生态-LTS

 

LTS（Lindorm Tunnel Service）是面向Lindorm业务场景特点深度定制的数据生态服务。支持简单易用的数据交换、处理、订阅等能力，满足用户的数据迁移、实时订阅、数湖转存、数仓回流、单元化多活、备份恢复等需求，实现面向Lindorm的一站式数据生态服务。

在集团内部，Lindorm拥有全网前列的离在线数据同步流量。依赖LTS(Lindorm Tunnel Service)服务，每天有接近670+TB，约3.2万亿条记录来源于其他数据源的导入Lindorm。同时每天有接近549TB数据实时导出到TT、MetaQ、ODPS等其他系统，用于实时、离线计算、数据订阅、算法训练、数据备份等场景。

 

4.5.1 数据生态总览

 

下图展示了LTS功能总览，其生态覆盖了关系型数据库、消息队列、NoSQL数据库、数仓/数据湖、搜索引擎等等。典型场景包含了互联网账单、低成本历史库、离线系统加速、大数据画像、数据订阅（CDC)、数据入湖等等。

4.5.2 企业级特性

 

本节介绍LTS三大企业级特性：Bulkload、Streams、全球多活，打造大数据场景下基于Lindorm的数据闭环最佳实践。

 

4.5.2.1 Bulkload

 

Lindorm Bulkload是由LTS(Lindorm Tunnel Service)提供的低成本、高可靠、高性能的企业级批量导入服务，支持将MaxCompute、Hive等数据源中的数据导入Lindorm/HBase。

Lindorm Bulkload的优势
• 低成本：Bulklaod模式天然比API模式节省资源，无需日志、事务、RPC等方面的开销。同时利用外部生成SSTable的特殊性，我们对SSTable Writer进行了优化，使其性能提升2倍以上
• 一致性提升：我们把表切换的逻辑做到系统内部，对客户透明，支持强一致覆盖写（即将上线）。对于同城多活的实例，我们支持多个Zone同时Load数据。
• 防导入抖动：我们提供了多级限速、本地化率、缓存更新优化等多种手段减少导入时的性能波动
• 反数据倾斜：可以自动检测数据分布，实时调节目标表的分区，并做到分布式导入下的负载均衡
• 易用性：白屏化接入
• 可靠性：系统高可用，有完善的监控报警体系

4.5.2.2 实时数据变更通道（Streams）

 

Lindorm Streams提供对Lindorm数据变更的实时、保序、高并发的处理能力，同时具备水平扩展、高可用、低成本等特点。可以基于Streams实现数据订阅、实时流处理、数据备份、异地复制等功能

 

Lindorm Streams的优势
• 实时捕获数据变更：非保序模式下百毫秒延迟，保序模式下秒级延迟
• 保序：支持主键级别的保序，同一行的变更有序处理，基于时间戳进行排序
• 易用性：白屏化接入
• 可靠性：系统高可用，有完善的监控报警体系

4.5.2.3 全球多活

 

Lindorm 全球多活的优势
• 多云支持：支持IDC与公有云混布
• 多点写入：单元化读写，异步复制，支持最终一致性
• 智能路由：客户端根据延迟自动选择接入点
• 按需多活：可选择部分表全球同步，部分表不同步
• 易用性：白屏化接入，拓扑关系展示
• 可靠性：系统高可用，有完善的监控报警体系

■ 五、总结 

2020年，是全面云化的一年，核心链路完全云化，业务形态从Cloud Hosting走向Cloud Native，Lindorm的多模形态也在快速发展，双十一核心支撑的业务也从阿里经济体内部，走向了公共云企业级客户。面向未来，我们将继续往云原生、多模型、低成本方向奔赴，重点在多模融合查询、Serverless隔离调度、低成本海量存储、实时Stream、智能化等技术突破，向着“让数据存得起，看得见”的使命，全力以赴。

 

作者：阿里云数据库技术专家 昊尘

 

文章转自公众号：阿里云数据库