分久必合的Lindorm传奇

Posted 2021-06-28 阿里云云栖号

简介： 2009年，阿里巴巴首先提出用分布式架构替代传统商业数据库，成功用自主开源的AliSQL支撑双11数据洪流；2016年，为应对超大规模业务场景，阿里云开始自研分布式数据库。十余年间，阿里巴巴数据库完成了从商用、开源到自研的发展路径，并以迅猛之势形成山河，但其在技术上的投入从未停止。

作者 | 津辰
来源 | 阿里技术公众号

《三国演义》第一回：“话说天下大势，分久必合，合久必分。”

这是阿里云原生多模数据库负责人天梧最喜欢的一句话。“就像我们数据库的研发一样，从集中式到分布式，再到多模的出现和发展。”

2009年，阿里巴巴首先提出用分布式架构替代传统商业数据库，成功用自主开源的AliSQL支撑双11数据洪流；2016年，为应对超大规模业务场景，阿里云开始自研分布式数据库。十余年间，阿里巴巴数据库完成了从商用、开源到自研的发展路径，并以迅猛之势形成山河，但其在技术上的投入从未停止……

不久前的阿里云开发者大会上，阿里云带来了其自研云原生多模数据库Lindorm的最新应用及其背后的故事。

一 互联网时代，数据井喷式增长

上世纪70年代末到90年代初是数据库从理论到实践逐渐成熟的黄金时代。

数据库是承载数据的基础，好比数字化社会的交通设施，概念不新但是刚需。

最开始，数据库部署在小型机上，解决一些企业内部的信息管理问题。随着互联网web2.0网站的兴起，传统关系数据库在处理超大规模和高并发场景时已显力不从心。

同时，数据时代，管理业务数据已经不是对数据库唯一的诉求了。

从海量数据中挖掘价值成为新的方向，数据需求变得多元，非关系型数据库NoSQL应运而生。

NoSQL数据库种类繁多，最大的特点是——不再局限于关系数据库的事务约束和关系模型。

在这些数据库中，有些特别擅长处理文档类数据，有些偏向于KV类数据……大神们一个个登场，产品越来越垂直和多样。

当然，伴随着多样性，一个令人头疼的问题也出现了。

比如今天要开发一个应用，可能需要四五个数据库来满足需求。对于任何一个应用，它会变得很重，开发的敏捷度也会变低，成本也很高。

类似于过去家里既要买一台电话机，又要买台照相机，可能还要买专业影机，乌压压一大堆，不仅笨重还占地方，掌握所有设备更是令人抓狂。

到物联网时代，产生数据的设备指数级增长，应对业务所需的数据库种类也越来越多，这种抓狂到了难以忍受的地步。

物联网数据的特点

 

在这样的背景下，多模数据库横空出世。

“多模数据库”的概念，最早起源于2012年的全球NoSQL大会上，设想一个系统可处理多种类型数据，以简化应用数据架构，减少开发维护成本。

“业务使用的多套数据库之间有些数据是需要联动的，简单看多模就是在其上再封装一层，统一调动不同数据引擎，来承接最上面的业务。”天梧说。

就这样，拥有不同能力的葫芦娃合体，成了全能选手——金刚葫芦娃。

二 “用户需要一个智能电视机，你却给他一个全家桶”

“我们希望自己把复杂的多套数据库组合封装的业务逻辑做掉，打造一个智能的多模数据库。”天梧举了个例子：

以前，相机拍好照，需要通过电脑上传后，再用社交软件发出去。有了智能手机，拍照后立马就能分享，这背后，就是IM通信跟摄像的融合。

在天梧的设想里，多模数据库要做的，就是成为数据库里的智能手机。

当然，理想很丰满，现实很骨感。

想要把并不糅合的两类数据放在一起，并不容易。

对于数据库来说，融合相当于自己理解数据特点和需求，自己融合数据。

所以，原来应用层会碰到的问题，都下沉给了数据库团队。

比如，光是一个一致性的问题，就搞得天梧愁眉不展。

阿里云原生多模数据库负责人天梧

 

不仅天梧，业界所有尝试多模技术的老哥们，都累得够呛。大佬的提法虽然不错，逻辑上也过得去，但实操起来，一堆Bug。

琢磨来琢磨去，大家默认，得，那就整个组合包吧。参考业界组合式数据库方案，多模数据库孵化版初现雏形。

孵化版最早是在阿里云HBase上做，天梧团队把基于HBase搭建的四个数据库组合了起来，统一的产品界面，看上去，似乎有了一个多模数据库的概念。

但其实就像一套家庭智能影音系统，电视机是电视机、音响是音响，不过都基于阿里云平台，有一个统一的购买渠道、产品界面和售后而已。

“实际上，本质还是多套系统”。天梧心里比谁都清楚，“用户需要一个智能电视机，却发现卖给他的是一个全家桶”。

而且这套“全家桶”还有个最大的BUG。

在最核心的数据处理存储这一层，这四套数据库是独立的。这点在物联网的场景里，尤为致命。

过去，Lindorm的客户阿里云IoT平台在公共云的架构方案是基于多套数据库实现的，虽然复杂一点，但毕竟每套系统背后都有体系化的支撑，资源上也能够弹性，业务还是能work的，但是当用这个方案去做混合云输出的时候，就特别痛苦，因为每一套数据库的背后都是一个庞大的系统及其资源开销。

为解决这个不同，客户公共云用阿里云HBase等多套数据库，到了线下混合云不得不换一套小一点的、轻量灵活些的架构，且完全得自己维护。每个应用最起码要腾出两个人来专门做数据的处理、衔接，成本极大还没法做到可靠性和一致性。

“如果能提供一个公共云混合云线上线下的统一架构，将会是一个巨大的提升。”做一个真正的多模数据库的想法，在天梧心里生根发芽。

三 “我们背后，是整个阿里云分布式系统”

事实证明，“缝缝补补带不来真正的技术革新”。

想要做到线上线下统一架构，构建真正的多模，需要投入大量人力资源，从顶层设计到落地推进，大刀阔斧进行革新。

“让我们下定决心要去做真正的多模数据库的原始动力，正是我们接触到了更多的人，他的确有这种需求。”这些迫切的渴求，给了天梧极大的鼓舞。

2019年，近百人的队伍被拉起来，浩浩荡荡投入Lindorm研发。

Lindorm项目团队成员

 

和阿里很多被业务倒逼催生的庞然大物不同，在天梧看来，Lindorm的诞生，源于技术人对更先进技术的探索和对革新的使命感。

当然，力求创新的阿里云，给了它生长勃发的土壤。

“iPhone不产生，我们世界也活好好的。但它的到来，可以让世界更美好。”天梧说这话的时候，眼里有微光在闪动。然而，现实是残酷的。

造“iPhone”的过程，比想象中难得多。

首先是顶层设计。到底要造一个什么样的多模数据库，对数据的需求要抽象在哪一层。只往上走一点，不能解决业务的问题，往下沉太多，复杂性会很大。

以在多模开发的过程中，最核心要去解决的几个问题为例。

垂类数据库按种类来分多达十几种，选哪几个模型进行融合？用笛卡尔积原理，每多一种模型就会多出海量的处理。第二是选择模型数据后怎么融合？

对于这些问题的解法，团队经历过不下数十次的争辩。

“这是我们最大的痛点，我们不知道是走对了还是走错了。”天梧说，如果前面有一个领路的权威者，至少我们做得会比较坚定。

纷纷扰扰，求而无门，几度挫败。

那个如空中楼阁一样飘在天上的多模数据库，真的存在吗？

天梧不是没有怀疑，但他更相信自己作为老技术人的嗅觉，以及真切感受到的客户需求。“今天我们做多模，革新技术，但并不是完全从零开始的。”一次例行周会上，天梧环顾团队年轻的同事们，说。

在阿里云漫长的12年里，今天在做的这件事，有宽表HBase上的积累、时序上的积累、云原生存储上的积累。“我们背后，是整个阿里云分布式系统。”

无人引路又有何惧？这种敢为人先的斗志，本来就镌刻在阿里云的基因里。

“没有一个总的设计架构，我们就围绕着客户的需求去对。”最终，团队选择了业务场景里高频使用的3种模型，宽表、时序和文件引擎进行融合。同时，将场景聚焦在IOT和APM两类方向。

“我们就追着垂直做这两个大的方向。把这两个方向打通后，其实建立的能力是相对也是通用的。”天梧坚信。

四 真正的多模数据库，成了！

Lindorm团队核心做了两件事情，第一，统一数据管理。第二，研发多模引擎。

首先把整个产品变成统一的，数据入口统一，数据存储统一，交互管理统一，但底下数据的组织和流转是多样的。利用多模引擎，数据可以从A流到B，从B流到C，自由畅行。

举个例子，Lindorm就像是一个巨大的仓库，多模引擎则是多种类型的仓格，客人入店，想要拿什么东西。只需告诉伙计，伙计依据仓格，取出所需。

在复杂的IOT场景下，伙计勤勤恳恳分毫不差。真正的多模数据库，成了！

2020年9月，Lindorm在万人集聚的云栖大会上被重磅推出。

很快，东软睿驰、江铃汽车、长城汽车等多家车企采用了Lindorm产品。

东软云科技云解决方案和服务事业部副总经理傅春江表示：“数据是车联网赋能车厂和车联网服务提供商提升客户体验，构建技术竞争力的关键，阿里云原生多模数据库Lindorm具备极具竞争力的数据存储性价比和技术优势，做到了让车联网数据存得起、看得见。”

不久前，上海市新能源汽车数据平台引入Lindorm，其是全国首个、上海市唯一的新能源汽车市级监管平台，已经接入新能源汽车41.8万辆，涉及车企95家，品牌107个，车型777款。由于车辆接入信息种类和结构呈现多样化，给平台的运营和维护提出了技术挑战，并且推高了成本。为此，平台运营方在关键数据库上选用了Lindorm，Lindorm的高并发写入、弹性扩展、实时检索分析等能力，使得数据的写入查询性能提升3倍以上、成本降低20%以上，对于流量突增等情况也可以从容应对，很好地支撑了业务快速发展。

如今，Lindorm被全面应用于阿里各大业务板块，服务的客户多达两千家。

一位原先用BigTable的国际客户称：使用Lindorm后的性能效率提高3倍。

这让天梧受宠若惊：“在数据库领域，BigTable是鼻祖一样的存在。”

不过，对于团队而言，最高兴的莫过于，随着客户体量的增多，他们再也不是摸着石头过河了，源源不断的用户需求和反馈，是最好的指引。

一个做监控SaaS的客户主动找到团队，滔滔不绝提了好多需求。

天梧回忆，当时的场景就像有人拿了一床大棉被，里面裹了各种文件啪丢给你，让你去分门别类规划。

“我觉得这个需求也很合理。实际上数据产生的时候，它就是这样糅合在一起的。客户希望交给你去处理，这样它可以减少很多一致性的工作。”

虽然这些需求，今天团队的设计理念和能力还不一定能达到。在天梧看来，正是Lindorm的理念激发了用户客观真实的需求。而需求又会推进Lindorm更加的完善和强大。

这本身就是一个相互迭代和认证的过程。

五 Lindorm，给开发者带来更多可能

Lindorm的强大能力，给开发者带来了更多可能。

“我们把之前应用需要花大力气去做的事情，都做掉了。”天梧说“用一句俗话，就是把复杂留给自己，把简单留给别人。”

对用户而言，他不需要再自己处理海量数据，而是可以直接利用数据带来的价值，提升效率，促进生产。

这种简单而朴素的愿景，伴随着技术的迭代发展。

从单机数据库到分布式数据库，再到如今分而合之的多模数据库Lindorm，一个收口可以表达对多类数据统一处理的需求。

同时，Lindorm不希望用户在多模数据库与多套数据库之间去做取舍，其每一个模型引擎，都是原生设计，可以当成一个专业的垂直类数据库。

“今天，我们定义了什么是多模数据库，从顶层设计架构，定义这种真正融合和统一。”在天梧看来，兼容并济，集各家之所长的Lindorm的诞生，正是技术进步的必然。

数据库技术发展几十年的每一次跃升，都向着越来越强和综合的能力进发。

对于天梧和所有Lindorm研发的技术人来说，能在进程中参与和促进这场变革，是一件有着莫大成就感的事情。

最后，说回Lindorm，名字取自西方神话，是一条迅猛的飞龙。

“因为我们要处理的都是海量的数据，我们不希望处理数据的时候很笨重，我们希望是很敏捷的，灵动的。”天梧释义，这是属于程序员的浪漫。

如今，这条飞龙正辗转腾挪，风驰电掣，直上云霄九万里。

原文链接
本文为阿里云原创内容，未经允许不得转载。