Tablestore深度解析：面向AI场景的结构化数据存储最佳实践
内容介绍：
一、Tablestore：十年历练，成就大规模在线数据存储服务
二、AI时代行业变革，多模态数据查询与存储需求升级
三、VCU模式叠加Serverless弹性VCU，替换CU模式
四、Tablestore向量检索发布
五、客户最佳实践
六、结合AI独创获客大模型
七、Tablestore：简单且高效的结构化数据存储
八、多元化索引，提供灵活高效的数据检索
本次分享的主题是Tablestore深度解析：面向AI场景的结构化数据存储最佳实践，由阿里云智能集团高级技术专家周赵锋、阿里云智能集团产品专家周颖和平方根（北京）科技有限公司CEO钱根平分享。
一、Tablestore：十年历练，成就大规模在线数据存储服务
阿里云Tablestore产品是与阿里云一起发展的产品。2009年是阿里云成立的一年，而Tablestore是在2014年发布的，它经过10年的进化和历练承接了非常多的阿里云业务。基于这些业务的打磨，给外部客户也提供了商业化的支持。阿里云的订单场景业务承载着阿里云采样系统，包括蚂蚁财政系统，因此在历史订单和风控的业务场景中有海量的数据承载，并以此为基础向外部，例如为众安科技提供服务，或其他业务场景，包括钉钉、通义千问、淘宝、飞猪和阿里邮箱等。
阿里内部业务在元数据管理场景、AI多人绘画以及IM聊天消息记录都存在非常多的业务沉淀和经验，并且以此为基础为外部商业客户提供了元数据管理的服务，例如设备、物流、监控等业务。也为阿里内部的菜鸟、天猫精灵、故障管理、云监控产品等都提供底层服务。在外部的客户，如光伏、车、电瓶车业务等，在Tablestore上有很多应用再到AI场景上都有新的迭代和需求，比如AI智能检索、AI智能聊天对话、以前的业务迭代、大数据数据洞察和分析都对数据的检索和存储提出了新的需求。
二、AI时代行业变革，多模态数据查询与存储需求升级
多模态数据应用给存储体系提出了诉求，即需要在底层把结构化数据和非结构化数据统一存储和应用，并且上层元数据管理需要针对结构化和非结构化数据进行统一的存储和管理，还需承载更多，如KV、向量的数据类型，在面对各种各样的数据类型时，需要提供更多的查询能力，如分析能力、检索、模糊能力。
随着AI的进化，以及更多数据体量上云以后，需要为成本和无限的存储规模上限提供基础服务，其中在线基础服务更关注稳定性和运维成本，而在线的基础设施需要考虑各种各样的需求。
Tablestore面向的需求打磨产品在上层的接入层面使用的是Service服务模式，并且还提供多语言SDK和API，支持Circle类型接入方式，从而让用户用更轻便的接入方式进行使用。在下层还支持多模态数据结构和数据引擎，其中底层存储类型支持各种的存储类型分层，包括热的、温的和冷的。
Tablestore在低成本、高性能和存储数据类型上都进行了功能更新。主要分为四部分：高性价比、高性能、高可用和多模态向量检索引擎的发布。
三、VCU模式叠加Serverless弹性VCU，替换CU模式
高性能把计费模式从CU模式升级为VCU模式。其中CU模式是按量计费的模式，存在着不可控的问题，在VCU模式推出后，解决了几大问题。第一是VCU让计费变得让用户更可控；第二是提供更简单的计费模式，把6个计费项缩减到1个计费项，使用户可以通过类比evco=4和16GB大约的性能对比评估，在需要购买性能费用的基础上，利用预留VCU和弹性上限阈值控制让用户在费用支出上面得到更可控的管理。
最重要的是VCU模式所带来的实惠，根据VCU模式和CU模式在预留费用上面的对比，VCU的模式整体费用下降的幅度达80%，即按量对比的预留CU平等计算性能交付的规模对比。交付规模对比的费用下降的两个规格是容量型的规格和高性能型的规格。在面向容量型的规格，对于按量CU的费用，如果用VCU模式替换CU模式在面向容量型规格上成本大约下降30%，如果对比高性能型规格上，整体下降可达90%以上。
接下来是在教育软件客户上进行的最佳实践。客户的业务高速增长，所售卖的设备为学习机，因此在数据管理和成本上有很大要求。其要求是在业务增长的同时，尽力防止成本过多增长和支出。在CU模式升级成VCU模式后，不仅成本明显下降，计算费用整体也下降到了39.32%，共下降了40%，而存储加计算整体成本平均下降了32.91%，即33%。
除费用下降的优势外，用户原使用的量是按弹性Serverless模式，并且在VCU模式下进行了保留。用户如果开启弹性VCU，可以根据使用量的完全贴合性能使用路径去付费，其中离线的流量，如小时级或按天数级，一天大约是1~2个小时的离线任务计算，而这与它的突增流量都可以不需预留VCU，只需开启弹性VCU根据使用容量收费即可。
在高性能方面，一直提供自研高性能计算引擎，针对计算引擎和开源HBASE进行的对比，以及和HBASE自建的相同计算性能交付的规格上进行的对比测试数据。其中根据自建的HBASE在同样的两个ECS节点上面所做的评估，写入和查询行数吞吐比自研HBASE高3~9倍。同样在性能消耗情况下，以及在提供这么高的吞吐倍数下，查询时延比自建HBASE快3~10倍。
四、Tablestore向量检索发布
在稳定性方面，Tablestore去年逐步推出了同城冗余实力，去年10月份，用户发布的同城冗余实力，以及用户购买新实力，都默认开启了同城冗余功能。在8个国内、国际和1个地域中进行默认升级，并且用户可以在后台不断查看，即默认升级同城冗余，但这对用户费用并未增加的。在出行软件用户案例中，帮助用户默认升级实力后，运维成本和使用成本没有提升和增加。在稳定性上包括单可用区，当出现跨机房故障时，还可以感知停服时间，这比数据库储备容灾方案要低，并且在整体可用性的数量上还有明显的提升。
向量检索引擎不是新增加的计算引擎，是在多元索引引擎上增加的向量检索的功能，在现有的多元索引功能中，包括倒排索引、全文索引、多维空间索引等，联合并进行多路召回。使用户在使用向量检索功能时可以不用把两套计算逻辑和两套工程链路分开，不需要做End的过滤，只需用一个SQL直接在引擎上进行一键检索。并且高性能Tablestore底座给向量引擎带来了高性能无底线的存储上限，因此向量检索引擎的存储规模可达百亿向量级。
索引构建提供实时索引构建和毫秒级索引查询的高性能能力，同时提供安全保障。这样用户可以用自己账号Tablestore实例存储向量数据，从而把不同安全级别的数据分表存放，最后应用时使用多表Join功能，将不同安全权限的数据调研整合，Join在一起，并面向不同权限的用户做不同的查询。
根据向量检索引擎与开源向量引擎做的性能对比，其中写入时间和查询时间下降了65%，查询时延上是开源引擎的1/6，但在时延快很多的情况下，消耗的内存占比是全内存索引加载的1/10。而所用的技术是DiskANN的普算法，所用的是内存+硬盘联合构建的索引模式。
最先的功能用户是OSS，它与OSS一起联合发布关于在OSS上实现一键AIservice检索功能，使未来的用户除了在OSS上使用检索功能以外，也可以把对应的OSS的Meta数据，包括用户自定义Meta、多媒体转译功能和用户自定义embedding的功能结果同步到用户自己的Tablestore表上，这样用户就可以使用Tablestore自带Circle查询能力把应用拓展到线上业务了。
五、客户最佳实践
向量索引引擎已经发布很久了，与客户也有非常深度的合作和打磨，其中AI集象是北京科技有限公司的一款产品，AI集象是一款AI驱动的获客专家，旨在帮助企业提高获客增长，提升成交转换以及高效销售避寒管理能力。
全方位的销售助手，第一是AI获客，它采用自然语言方式进行数据深度挖掘，并进行获客。第二是智能外呼，采用机器人呼叫方式筛选精准客户。第三是AI客服，基于大模型加rag检索，来实现整个AI客服。第四是智能名片，它具有全方位营销以及动态雷达追踪。第五个是功能新媒体运营，它提供了公域私域一体化的解决方案。最后是智能的CRM管理。
市面上有很多企业研发关于获客的软件，传统获客通常依赖于付费推广等一系列方式进行获客。然而在获客过程中，只能获取到客户的联系方式，为此企业还需进行大量电话轰炸获取精准客户。相比之下，AI集象有几大优点，第一、从客户获取到成交的过程实现了一体智能化。第二、由传统搜索转变成AI技术，主动推送潜在客户，第三、通过大数据清洗和智能分析提供企业画像，包括具体匹配度、缺口、建议方案等，从而提高获客的精准度。
六、结合AI独创获客大模型
大象无形，对话式交互方式允许用户在输入框内输入整体需求，例如请求寻找北京市需要购买算力作用的公司。系统能够利用141个企业数据进行深度检索，并通过湖仓一体等一系列先进技术推荐方式，帮助客户精准定位意向客户。这一过程不仅能让客户获取到目标企业的基本信息，还能获得匹配结果、企业库匹配度以及详细的企业画像，全方位展现企业状况。
结合AI独创的获客大模型，我们的工作分为三个层面展开。数据源主要源自合作厂商提供的数据，同时我们也通过合法途径自行采集数据，并将自身未有的数据作为训练数据的语料。这些数据涵盖了工商信息、经营数据、司法风险、招聘及知识产权等多个方面。通过数据训练，我们实现了信息聚类分类、数据标注、大模型参数调整以及机器自动化标签等功能，旨在满足AI大模型的用户意图分析、用户画像总结以及潜在客户匹配等需求。
AI集象与阿里云Tablestore携手，共同实现了LED智能检索功能。相较于传统的非结构化数据库加ES集群服务，该方案在运维基础设施建设上的成本显著降低。企业无需投入过多研发和人力，即可快速上线使用。同时，它支持线上业务规模扩展，并大幅降低了自建ES的成本。目前，我们拥有140+的数据源和17T的数据规模，若采用自建机房和基础设施，成本每年高达约50万。而与Tablestore合作后，成本已压缩至每年五万元。该联合方案提供了一站式接入服务，接入成本低廉，并支持百亿级向量的处理以及线上业务的标准化。在过渡过程中，阿里云提供了DTS等工具，帮助我们快速迁移至ETS，实现了CU向VCU的成本转变。
我们积极推动与阿里云及千寻的合作进展。鉴于企业数据量庞大，目前拥有141家企业的10亿级标签数据，每天增量需求高达9000万左右，查询响应时间控制在1秒到5秒之间。在TP99和故障率等方面，我们也取得了显著提升。在与千寻团队的合作中，项目成功实现了65个字段的深度推理，并处理了剩余的1000多个推理请求，深入理解了客户需求，并进行了深层次的推理分析。这不仅实现了深层次的推理功能，还支持了多轮对话交互。
七、Tablestore：简单且高效的结构化数据存储
众多业务场景借助AI实现了显著的效率提升，而AI在处理底层基础设施时面临诸多挑战，同时也为这些设施带来了独特的优势。Tablestore作为一款简单高效的表格存储服务，能够承载万亿级别的庞大数据量。在表中，每一行都包含组件链、属性链等，这些元素均可定义行的唯一性属性，同时允许用户自定义任意属性字段及其类型。Tablestore通过将大表按照分区键切割成多个分区，在集群内部实现分布式加载，从而提供了分布式且可横向扩展的能力。
Tablestore不仅适用于基础查询，还能在全文检索、地理空间检索和向量检索等多种复杂检索场景中发挥重要作用。用户可以根据需求灵活地为表建立索引，包括不同类型的索引，并通过简易的API调用创建相应类型的索引，提供RESTful API接口。此外，用户还可以通过C语言接口轻松建立表查询索引，与不同的上游和下游系统对接，便于用户在不同业务场景中构建数据系统。
从产品形态上，Tablestore面向高效应用，形成了serverless模式，即用户无需关注底层资源管理，也无需进行任何运维投入。这种模式下，表格存储可以从小规模逐步扩展至大规模，整个过程无需用户进行任何干预操作，实现了自动扩展。此外，Tablestore还进行了高可用性和成本性能的内部优化，使得可用性、成本和性能都得到了显著提升。
Tablestore在应用场景上相对简单明了。在OTA（例如对象存储服务）上，存在大量的对象，Tablestore会同步这些对象的元数据到表存储中。这些元数据包括系统定义的属性、用户自定义的属性以及智能存储提取的数据内容。其中，知识库内容可以提取文档的embedding向量，作为向量的元数据存储。元数据可以建立对应的索引，并基于这些索引进行元数据的检索，如语音检索等，还能在不同场景下智能解锁特定功能。
对于表格存储而言，它需要满足更高的要求。具体来说，它需要支撑海量的数据，并支持不同类型属性数据的索引，从而支持多种类型的检索，包括混合检索。在面对AI场景时，Tablestore还进行了特殊优化处理。在AI场景下，Tablestore提供的关键功能包括支撑大规模的结构化数据存储、支持多元化数据检索以及面向AI的场景解锁优化技术工作。
其中，支撑大规模数据存储的架构图分为两层：第一层是阿里云的存储基础设施，作为分布式的文件系统和分布式的表引擎；第二层是基于这两层架构定义的重算分离、独立扩展存储和计算的能力，它具备更灵活的横向扩展能力。此架构使存储和计算分别池化，并提供了更灵活的资源调度能力。
分布式表架构则是基于动态分区的分布式表架构。大表可以被划分成多个分区，并进行分布式调度，为节点提供分布式服务能力。当分区的负载变高或数据规模变大时，系统会自动进行分裂，而这个过程对服务没有任何影响。集群分区实现了动态负载均衡，从而保证了性能的稳定性。
基于存算分离架构和分布式表架构，Tablestore构建了serverless模型，实现了存储和计算的快速弹性扩展。Tablestore没有绑定固定的比例关系，可以灵活配置计算和存储的使用量，从而达到最高的资源使用效率。集群整体采用三A类部署，并默认具备A类级的熔断能力。
Tablestore支持灵活的数据检索和吻合检索能力，包含多种元数据，如作者的创建时间、描述内容、地理位置以及embedding等。不同的属性需要支持不同的检索方式，如组合检索、全文检索、空间检索和向量检索等。因此，设计时需要对应不同的索引结构。例如，B树索引库常用的索引支持多列固定组合条件的检索；BKDT存储结构支持空间检索或数据范围检索；倒排索引支持全文检索；向量索引支持向量检索。因此，对应不同的检索模式需要支持不同的索引，并且要能够灵活组合。索引架构在特定场景下需要提供多类型的索引框架。由于数据是源源不断写入的，索引也需要实时更新，因此需要支持实时索引构建，以保证数据更新后可以迅速进行检索。同时，索引之间是相互独立的，但由于数据往往是多个不同条件的组合，因此需要进行混合检索。为了实现这一点，Tablestore内部对混合检索进行了优化。
八、多元化索引，提供灵活高效的数据检索
向量解锁优化对存储能力提出了多数据类型支持的要求，针对不同数据类型需要相应的解锁能力。Tablestore在支撑向量检索场景时，必须满足大规模、高性能和低成本的需求。向量索引算法不仅要能处理大规模数据，还要兼顾高效率、高召回率和低成本。传统的向量算法包括土树算法、聚类算法和图算法。
二叉树算法通过随机选取超平面并对向量空间进行不断切割，形成多棵二叉树，以提升召回率。然而，这需要用户在性能和召回率之间做出权衡，因为更高的召回率通常需要构建更多的二叉树，从而增加开销和成本。
图算法则是将向量与最近的几个点连接起来，构建成更大的图，并通过分层图索引来提升检索性能。但这种方法存在内存占用成本过高的问题。因此，这三种主流的索引算法都无法完全满足用户的要求。
A算法则能提供很高的性能，同时也能提供较高的召回率，并且在成本上有很大优势。以HNSW为例，其内存开销在未经量化时可能较大，但经过PQ量化后会显著下降，尽管召回率会有所降低。而DiskANN等算法则能在保持高召回率和高性能的前提下，将内存开销降低到与某些算法相当的水平，甚至更低，从而在成本上有所优化。
在混合检索场景中，针对一定规模的向量进行暴力搜索可以得出以下结论：对于小数据规模，使用暴力搜索可能无需下拉索引就能获得较好的查询性能和召回率。因此，在实际应用场景中，对于小规模数据使用下拉索引反而可能性价比不高。这需要进行查询策略的优化，具体策略包括：
自适应地构建图索引。当索引规模不大时，不建立索引以节省开销；当索引规模很大时，则选择建立下拉索引。
优化混合结果场景下的标量加向量的联合检索。通过标量过滤将结果集缩小，从而避免在大量向量中重新进行检索，而是直接对缩小后的结果集进行线性搜索，以提高性能。这需要根据标量过滤后的结果集规模自动判断是否使用向量索引。
在许多场景中，需要保证向量解锁的准确度。在混合检索场景中，联合标量过滤可能会被过滤掉一些满足top-k条件的向量，因此需要使用向量解锁后的后期过滤来确保结果的准确性。
目前，AI应用已经从早期的简单聊天（主要依赖LM单元模型存储绘画和消息）演进到RAG+知识库的模式，具有更多类型的存储，如文档分段embedding和知识图谱。智能体对框架进行了更高层的抽象，包括大语言模型和记忆。其中，智能体具备规划和工具使用的能力。某篇研究论文中提出的智能体认知框架与现在的RAG或聊天模型有所不同。记忆被区分为三类：流程记忆、情景记忆和语义记忆。流程记忆处理问题和流程，可以被编码进入大语言模型或智能体代码中；而情景记忆处理事件的序列，智能体能够主动规划、评估并迭代规划的过程，不断优化。
在Tablestore智能情景下，情景记忆和语义记忆下的存储在记忆存储场景中发挥着重要作用。首先，记忆会输入动作并对应到数据的存储和更新。记忆进行了两种类型的提取：回忆提取（定位到某个空间或时间发生的事件序列）和检索提取（根据某个片段、关键词、语义提取的内容）。然后，基于这些事实进行输出、总结输出或提取知识框架形成输出。
大规模数据存储需要支持提取与解锁操作。那么，在情景记忆和语义记忆下的具体要求是什么呢？这通常涉及到如何高效地存储、检索和更新这些记忆内容，以及如何确保在复杂场景下能够准确、快速地提取所需信息。
随着开源AI应用框架的逐步落地，AI为人类生活带来了许多变化。这些变化不仅体现在应用场景上，也对基础设施提出了更多的需求。随着数据规模的增长，如何高效地存储和管理这些数据成为了一个重要的问题。越来越多的客户也开始关注如何更好地使用这些数据来推动业务的发展。对于多媒体数据处理场景而言，AI正助力其朝着智能化、内容化和结构化方向演进。
