本次分享的主题是Lindorm：AI和具身智能时代的海量多模数据服务，由阿里云智能集团数据库产品事业部资深技术专家沈春辉分享。本次将分享关于新的AI和聚身智能时代的新的时代下面临的数据挑战，以及阿里云lindorm数据库最近一年的方向的思考和能力建设。
一、AI和具身智能时代的数据挑战
1.信息时代变革
在过去的40年，在座的各位都经历了信息时代变革，每一次大的技术变革，都会催生各种丰富多样的业务形态，新的业务形态的需求和数据的变化都是在一次次的驱动数据库的进化。
2.PC时代
在PC时代时，数据主要以结构化为主，再加上一定的查询和分析。
3.互联网时代
到互联网时代，随着半结构化数据和更复杂的分析文本检索的需求的加入，从2000年开始，以hadoop mongo DB数据库为代表的新型的数据库产品得到了快速的发展，分别解决了很多数据的在线和离线的需求。
4.AI时代
在新的AI时代，数据层面开始对非结构化的数据，以及基于非结构化数据的多模态的搜索或数据的理解推理有了进一步的需求，可以相信这一次的技术变革也会大幅的去推动和促进数据库层面的变革。
以具身智能的场景为例，目前智能化的汽车或各种形态的机器人，以及APP上网上的各种AI助理，都可以把它视为是一种具身智能，具身智能本身在产生类似于像设备的信号的数据，位置的数据，以及很多标签，日志，以及基于这些数据特征向量产生了丰富的称之为是多模态的多形态的数据。在传统的基于互联网的架构下构建的解决方案中，采用的是一种针对不同的数据，使用不同的数据库来解决不同场景的问题。
一般把它分为两大类，在线服务和分析计算。这两大类的数据库分别针对不同形态的数据，最终形成业务为解决自己场景的需求，需要叠加不同于HBase PostGIS MongoDB等非常多样的数据库，这对快速迭代的AI业务有非常大的阻力，如今每一个人都在期待AI业务给生活和工作带来新的变化或新的价值，这需要高速的去迭代效率，但是底下的数据的设施的多样化会严重的阻碍的开发效率。这些多样化的系统本身也引入了很复杂的架构，以及随之而来的各种运维复杂度，和相关的资源成本开销。所以阿里云lindorm多模数据库面向新型的AI场景下，应思考在AI场景下数据库应该长什么样。
二、多模数据库Lindorm定位与设计
1.Lindorm定位
经过过去两年的探索和结合，最新的前线的AI的场景lindorm。阿里云的云原生多模数据库lindorm定位于打造一个面向AI时代的海量多模数据服务，把过去传统的需要多个数据库组合解决的方案式的解决方案，通过提供多样化的产品能力把它融合在一个产品里，而能力主要也是面对在具身智能的场景。常见的数据，比如半结构化、结构化的时序数据、地理位置、数据标签、二值数据、文本数据、向量特征数据，都是新型的新时代的主要的数据，针对这些数据，lindorm能够进行统一的多模化的数据存储管理，以及能够提供检索复杂，分析AI推理等多样化的查询能力。
2.lindorm发展历史
lindorm是从2011年开始诞生于互联网时代。为阿里淘宝电商提供大宽表服务，服务在阿里包括支付宝，蚂蚁，菜鸟等各个电商的场景里面提供做出了非常多的优化和感性，在2019年，随着阿里云的整体的业务节奏，lindorm产品在阿里云官网上进行上线，提供企业级的Hbase服务。满足互联网很多头部，像小米，携程。在互联网公司场景中的HBase和相关的需求，为满足互联网和AI新兴未来行业发展的需求，lindorm的整体定位进行升级，从原来的大宽表的数据库，升级成多模态的数据库。该升级能够提供宽表之外的时序，时空等多种类型，同时支持基础的点查搜索分析。在2023年lindorm面向AI浪潮，在lindorm内部提供向量搜索的能力和IN-DB AI推力的能力来满足AI的业务应用的相关需求。
三、Lindorm的核心能力特点
1.多模一体化，极速提升研发效率
了解lindorm数据库核心能力特点和技术实践。作为数据库，拥有统一的典型的SQL的接口。在接口下，用户可以去定义丰富的数据类型，如基础的数值类型，复合类型以及类似于LB或向量以及其他能够支持复杂需求的数据类型。数据类型在一张大表格中可以支持达到腕列级，如超过上万的列的大宽表，列可以动态的增加或删除，并返回整个数据处理。对于业务，针对超宽的大宽表，能够通过SQL去做基础的，如点查或范围的查询、组件的查询。
同时可开展各种非组件的多位、多条件的查询。或根据关键词做检索，以及根据向量做向量搜索。在大宽表和业务层面，了解主流的大部分的数据查询需求，以及如何支持查询和过去不能支持查询的原因。lindorm通过多样化的引擎技术，如针对不同的数据处理需求，既有基于满足高效检查的宽表索引的技术引擎，也有基于倒排或向量索引的相关的技术支持搜索类相关需求，并通过索引的形式去无感知的访问数据，而不需要像传统多个产品方案用多套API，或需要有一个数据的通道去打通两者之间的数据，在lindorm数据的感知数据中，不同数据的列入的传输，不同的API统一被分装和收敛，用户使用的是一个超级能力的大型大宽表的数据库。
2.云原生和分布式，从0到PB级的弹性伸缩
数据库设计技术架构遵循两个理念分别是云原生和分布式。用户层面，它能够支持从0~pB级数据的资源的弹性伸缩。所有的数据都是在下层的分布式文件系统，它随着数据的增长而自动弹性。对于不同的查询需求，如简单查询或全文搜索，都能够独立的进行资源伸缩。在lindorm中，每一个组件都能做到存储和计算的分离，计算负载的分离以及不同计算的独立的伸缩。
3.异步攒批，最大化写入吞吐
对于海量的数据，传统的数据库的写入即事物的写入，从rpc到SQL的解析再到事物的处理，到各种内存的排序（flash），要经过比较长的阶段。对于传统数据库没有做批量化、异步化的逻辑处理，整体写入链路长，适合吞吐量较低的写入。在lindorm中，针对海量的数据，在写入的链路层面进行大幅的架构简化以及异步展批，把多行的数据合成一个主包，高吞吐的写入到lindorm系统中。例如以车为代表的车机数据，如果有100~ 1000个列，当使用开源HBcase结构方案，每个扩展能支持的写入是10.5万每秒。当使用lindorm的方案，写入能力能够上升到72.6万，整体会有7倍的提升。
4.多级介质和冷热分离，最小化存储成本
Lindorm面对海量数据进行多级介质的分离，分离可使用户选择不同时间跨度的数据，如M天以前可以选择冷数据，n天以内近期的数据可以使用热数据。lindorm本身支持4级存储介质，4级存储介质的性能和成本有很好阶梯性的差别。不同的用户可以按需去选择不同的存储介质来大幅的提升整体海量数据的存储的性价比。
5.深度压缩优化，降低一半存储空间
在存储层面，lindorm做了关于压缩的优化，传统的压缩手段无法应对海量的AI时代和车联网时代数据的特征，lindorm重点研发了面向以持续数据为代表的持续专用的压缩算法，压缩算法再结合通用的压缩手段，相比于目前开源市面，有一半的存储空间的优化。观察右边表格，在完全真实的数据下，车企中通过lindorm的持续的压缩技术，相比于业界已经非常领先的格式会有进一步的40%的优化，在左边，针对在线的行存的数据库以及MySQL开源数据下也会有一半的压缩优化。
6.丰富索引，加速任意灵活查询检索
了解lindorm在数据查询能力的特点，lindorm能支持丰富的搜索能力，既包括全文的检索，多维的检索，也包括AI应用中强依赖的向量搜索，lindorm能够在SQL的界面去混合执行查询检索，并提供数据的查询能力。针对不同的场景，使用了不同的索引技术，如常见主键的查询，主要去使用类似lsm的基于行存的PK的检索技术。针对全文的检索以及多条件的随机组合的检索，主要使用像lucene倒排的技术，以及做关键词的匹配，在向量检索方面lindorm重点除了传统的基于内存的索引技术之外，重点去攻坚和落地类似于ifp为核心的磁盘缩影技术。相比基于内存的技术，它可以把整体对内存的使用大幅下降一个数量级。最低可以做到只消耗16分之一的内存可获得对应的向量检索的能力。在SQL界面下索引技术，给用户提供一个丰富的、灵活的混合查询和检索能力，可以大幅提升用户开发业务的效率，以及查询检索的性能。
7.Serverless 计算，能离线ETL，也能交互分析
了解lindorm在计算层面的能力。lindorm的计算基于云原生的架构理念，使用阿里云的容器服务，结合开源的SPARK引擎来提供收费式的按需使用的效果。对业务需要去搭建一个是100台的集群来提供一个固定式spark服务，不同任务之间需要一定的资源增强，或突发临时紧急任务，需要去不同的腾挪资源，无法快速的响应业务的需求。对业务而言能使用lindorm的设备的技术Serverless的技术，可以解决业务需求和资源成本控制的矛盾性问题。在过去，存在矛盾冲突问题，想要业务支撑好，需要很多资源和成本。相反为了节省成本，牺牲质量。使用了lindorm的serveless计算的技术，可以使业务在有需求的时候，才会消耗资源，同时资源越多，业务完成的越快，且总成本保持不变。通过serveless计算技术可以大幅的提升借带应用对于数据的按需分析和弹性分析的需求。
四、Lindorm一站式车联网多模数据平台
了解基于lindorm的多模的数据能力搭接的一站式的多模数据平台的解决方案。在过去，lindorm围绕车联网，围绕汽车的数据的特点和需求，构建了以lindorm为中心的一站式的多模数据平台，并且被广泛应用，目前熟知的各种汽车品牌都在使用，已经覆盖了60%国内的头部车企，支撑近百PB的数据的规模，带来90%业务成本的下降，相比于传统基于开源的大数据和在线多模数据库的组合解决方案，整体一体化的平台帮助业务大幅的消化在数据方面企业的负担，包括资源成本、运维以及业务效益。
