api 原生hbase_深度干货｜让数据存得起 看得见，云原生Lindorm技术解析

一 背景

作为面向大数据场景的半结构化、结构化存储系统，云原生多模数据库Lindorm已经在阿里发展了近十年，并始终保持着快速的能力更新和技术升级，是目前支撑阿里经济体业务的核心数据库产品之一。在过去的岁月，伴随着经济体内部对于海量结构数据存储处理的需求牵引，其在功能、性能、稳定性等方面的诸多创新历经了长时间的大规模实践考验，被全面应用于阿里集团、蚂蚁集团、菜鸟、大文娱等各个业务板块，成为目前为止公司内部数据体量最大、覆盖业务最广的数据库产品。

与此同时，面对技术商业化、集团云化的推进，我们看到了更多百花齐放的应用数据需求和开放生态，以及Lindorm在此过程中的问题与挑战。如何适应云原生、5G/IoT时代的发展趋势，如何解决一套产品同时服务好内外客户，让以内养外成为产品商业化的竞争力源泉，是Lindorm在过去一年的主要思考和发展方向，希望通过本文向大家做一个综合介绍，分享我们过去面临的问题挑战、解决思路及Lindorm的新定位、新演进，文章有点长，感谢大家的阅读和建议。

二 问题与挑战

2.1 多样化的数据需求

Lindorm的架构起源于Bigtable，其核心是LSM引擎+存储计算分离，并融入了类CosmosDB的多副本多一致性设计和二级索引、数据Schema等能力，适合于互联网通用场景的海量半结构、结构化数据的在线存储与简单处理。

然而，现代应用场景的玩法和功能越来越丰富，除了高扩展、低延时、高可用、低成本等核心需求之外，简单分析、多维检索等高级数据处理正在成为越来越多应用的基本需求。为此，我们看到lindorm之上的用户，通常会有两个选择：

1. 直接基于Lindorm进行数据检索或分析，通过系统本身的扩展并发能力，来保障处理效率满足应用需求。这种方式最大的优点是使用简单、开发便捷，但不可避免在规模和成本制约下，会存在瓶颈；
2. 通过数据通道，部分数据转存到搜索系统(如ES、Solr等)，满足多维检索的需求；部分数据转到OLAP或数仓系统，满足统计分析的需求。这种方式最大的优点，是集合各个系统的优势能力，在扩展性上可以支撑很大的业务规模，但不可避免带来维护的复杂和数据的冗余。并且，对于异构系统之间的数据模型差异和一致性问题，通常需要业务层做针对性处理，再加上多套系统的学习理解，使得应用开发成本大幅升高，让中小规模企业的用户群体望而却步。

除了通用数据处理需求的多样化之外，在部分垂直场景下，业务期待专用的数据处理能力，使得在开发效率、运行成本等方面能有数量级的提升，以应对更大规模的数据增长。比如，在监控场景，公司内部的监控系统大部分都基于lindorm进行构建，应用期望将指标数据的降采样、预聚合、预测分析等常见能力可以下沉到数据库系统，因此，TSDB、OpenTSDB、InfluxDB等时序数据库应运而生，专注于解决如Metric指标的时序数据存储问题，大幅提升了监控/IoT场景中的设备时序数据处理能力。但是，应用也面临着新的烦恼，专用时序数据库的引入，提升了指标Metric数据的处理能力，但并不能去除系统中的其他数据库，如Log、Tracing、设备元数据库等通用数据仍需要存储在Lindorm中，部分场景可能还需要引入搜索系统来加速查询，系统的架构和维护变得越来越复杂。

类似情景还有不少，比如社交场景的消息推送、内容存储、聊天搜索等，游戏场景的道具、聊天、关系、录像等存储，广告场景的画像、点击日志、物料等存储，这些数据的多样化需求带动了多类型的存储系统的发展，在面对复杂场景时，相比于传统的单一存储选型，基于多套系统的存储解决方案大幅提升了系统的运行效率。但为此所付出的是，复杂数据库组合选型以及多系统架构维护下的业务时间成本和人力成本，我们不禁想问，下一站的架构该是什么？

2.2 业务流量的不可预测

互联网场景中业务流量的快速变化和不可预测是数据库维护者一直以来的痛点，在过去的日子里，我们面对的生产稳定性问题，很多是可以扩容解决的，但由于成本的约束，又不得不限制容量，使得成本与稳定性这两个问题被耦合在一起。这种计划式的资源管理模式，不仅浪费大量时间精力去进行容量规划预测、资源调度搬迁等工作，也无法保障资源的充分利用，更时刻承受着资源不足导致问题的稳定性风险。

云计算的兴起，唤醒了业务对于资源按需即时获取的强烈需求，弹性能力(区别于扩展性)也成为云上开发者对于云产品的默认理解，Lindorm需要重新思考这个方向的解决思路和挑战，我们期望在不久的某一天，大家不用再时刻担心容量水位，只需要异步地去统计和控制资源使用量，让资源利用率提升和系统稳定性风险成为两个相互独立的问题。

2.3 面向成本的存储碎片化

数据驱动是互联网业务的基础特征，通过数据进行拉新、推广、统计等几乎是所有应用的常规需求，让我们看到了数据给业务带来的价值，但另一方面，业务数据化过程中依赖的海量数据的存储成本，使得业务不得不仔细权衡数据维护的经济效益。如何降低数据的单位存储成本，是过去所有数据化应用都在考虑的核心问题，并逐渐形成了冷温热的多系统异构混合方案。比如，常见的是热数据存于MySQL，温数据存于HBase，全量冷数据归档到对象存储OSS或数仓中，由此产生的数据同步、查询维护、生命周期管理、冷热数据的业务差异化等给所有应用带来了很大的痛苦。

低成本存储是用户选择Lindorm的重要因素，也是持续不断的要求，但我们在过去也看到了部分业务因成本压力而分拆极冷数据转存OSS的应用复杂改造，甚至是业务侧自身的结构化数据编码压缩和缓存加速等，给系统维护和数据正确保障带来了复杂的挑战。这种因数据价值差异产生的异构化数据存储是一种通用的诉求，如何原生解决好这个问题，不让用户在低成本和复杂之间做纠结的选择，是Lindorm面对成本诉求的一个重要挑战。

2.4 开放的标准接口

从去年开始，Lindorm以"HBase企业增强版"的方式服务于阿里