分享概要

一、背景介绍

二、大数据在线存储

三、大数据离线存储

四、AI向量存储

 

一、背景介绍

 

1、货拉拉介绍

 

 

货拉拉成立于2013年，是一家互联网物流商城，提供同城与跨城的货运服务。货拉拉目前拥有八条以上业务线（企业服务、零担物流、长途运输、汽车租赁等），覆盖14个全球市场及400多个城市；年订单量超7.79亿，月活跃商户1400万+，月活跃司机120万+；并在全球运营6个以上数据中心。

 

2、货拉拉大数据

 

 

在大数据层面，货拉拉目前拥有4个DC，采用跨云混合云架构，涵盖阿里云、腾讯云以及部分自建机房。部署机器数量超过3000台，数据存储量40PB+，日均处理任务数20k+。当前，货拉拉的机器规模、数据存储量及日均任务数均处于业界中等水平，且在快速发展中。

 

 

大数据的使命是驱动业务数智化，助力公司业务持续增长。以上是货拉拉的大数据架构体系，该体系自下而上相互支撑，以满足公司离线场景的需求。主要分为：

 

• 基础层和接入层：提供基础计算、资源、存储及接入能力；
• 平台层和数据层：含数据研发平台、数据治理平台、数据资产等；
• 服务层：含数据应用工具、数据服务工具、数据智能工具等面向服务的大数据应用；
• 应用层：辅助决策类应用和赋能业务型应用。

 

3、自建+云服务混合

 

 

大数据存储架构采用自建+云服务混合部署的方式，根据数据流向分布，展现出典型的Lambda架构特征。源头数据在经过底层的采集、处理和加工后，会分成实时和离线两条路线。离线数据会落入离线存储中，而部分AI数据则会流入向量存储。实时数据与处理后的离线数据汇合后，会流入在线存储，共同为上层应用层提供服务。

 

从数据使用角度考虑，可将大数据存储划分为在线、离线和向量三大类别。

 

二、在线存储

 

1、在线存储发展历程

 

 

货拉拉的在线存储发展历程可以分为四个阶段。

 

1）萌芽期：各团队自建并维护自己的系统；

 

2）成长期：稳定性保障专项，建设生产级别存储能力；

 

3）成熟期：稳定性能力对齐业务，达到99.99%；

 

4）完善期：调研新组件以丰富应用场景。

 

2、在线存储使用现状

 

 

货拉拉的在线集群采用HBase 2.0.2版本数据库，是一个多云部署的架构。整体的集群规模有20套，运维节点数超200台，单纯的业务表700余张，其中最大一张表的数据集接近1PB，目前服务超100个场景。在此体量下，为保障多业务场景的稳定，最终参考业界实践来构筑完整的稳定性体系。

 

3、稳定性概览

 

 

如图，根据事前、事中和事后的顺序建立一个完整的稳定性体系。

 

1）事前

 

• 故障预防：技术架构盘、业务负责人盘点、研发变更梳理、容量评估、日常演练、业务隔离

 

2）事中

 

• 故障发现：故障告警、日常巡检、业务感知、链路监控
• 故障响应：应急响应小组、应急响应规范、应急演练
• 故障定位：定位大盘、trace能力、团队人员培养、定位工具箱
• 故障恢复：降级、RsGroup隔离、限流熔断、HA、恢复预案

 

3）事后

 

• 整改验收：故障复盘、改进迭代、专项治理、云运维

 

通过这样的建设，货拉拉在线SLA从原来的99.9%提升到了99.99%，满足线上业务的需求。

 

4、稳定性——业务隔离

 

 

目前，货拉拉采取业务隔离策略，采用多种集群部署模式，同时兼顾不同业务对稳定性和成本的需求。

 

1）独立部署

 

将在线业务与离线业务拆分，离线业务独立部署。由于离线业务可能存在大规模或不定期读写操作，对底层磁盘压力比较大，同时数据量也庞大，因此无法与在线业务进行共同部署。该策略的优点是不影响在线业务的稳定性与性能。

 

2）混合部署

 

即使把在线业务进行混合部署，因业务特性和读写方式的不同，也无法共用。例如，实时维表业务基于Flink进行读写，但在某些情况下会出现任务重启，这会导致流量激增，抢占CPU与磁盘IO性能；而风控业务则具有稳定流量特征，对性能要求较为敏感。如果将两类业务部署在同一资源池中，极易因资源竞争导致关键业务性能劣化，影响系统稳定性。

 

为解决该问题，货拉拉采用HBase的Rs Group能力在集群内实现分组隔离。该方案既避免了独立集群的建设成本，实现存储资源共享，又借助HDFS本地读取特性保障读写性能，最大限度降低成本。通过这种措施，实现了离线部署下P0/P1/P2级别的业务隔离，同时兼顾性能保障与成本控制。

 

5、稳定性——HA能力

 

 

HA能力的2.0.2版本在复制功能上存在较多问题。通过研究后续版本的实现，合并约40个issue以完善复制功能。如图所示，通过搭建两套集群实现双向复制，达到互为主备的容灾效果。同时备集群与主集群位于不同可用区，实现region级容灾。

 

由于社区未提供客户端切换能力，货拉拉基于公司内部的配置中心，自主研发了一个支持HA能力的HBase SDK。一旦集群发生故障，可通过配置中心修改主备参数配置，实现主备链路的读写平滑切换。该HA方案已支持表级别的主备切换。

 

目前，货拉拉正在规划实现自动切换机制以缩短故障恢复时间，同时希望通过HA架构拓展多路读能力，缓解HBase的长尾延迟问题。

 

6、性能与效率——挑战

 

 

稳定性体系搭建完成后，HBase在线业务进入稳定状态。业务规模根据需求特性划分为两部分：

 

1）性能型集群

 

风控、数据API等业务对性能要求高并且敏感，适合部署在性能型集群。

 

2）容量型集群

 

地图轨迹等实时业务作为内部服务，对时延不敏感且体量较大，因此更适合部署在容量型集群以节省成本。

 

随着业务的发展，这套架构逐渐暴露出3个痛点：

 

1）容量型性能差

 

容量型集群的性能已难以满足业务需求，HDD盘的读写性能不足和不稳定性制约了业务发展。例如，轨迹数据现逐步被风控人员使用，一旦出现超时，将影响风控策略的执行。

 

2）性能型资源使用率低

 

性能型集群在扩展过程中成本不断攀升。尽管采用三副本存储于NVMe盘以保障性能，但由于NVMe盘容量较小，磁盘容量常常成为瓶颈，CPU使用率处于较低水平。

 

3）长尾问题严重

 

这是HBase组件的典型问题，其存算分离架构设计及JVM GC的不确定性导致毛刺频发。

 

7、异构存储

 

 

针对容量型性能差和性能型资源使用率低的问题，经实践调研后，货拉拉使用异构存储的解决方案。

 

具体而言，利用HDFS的磁盘异构能力，在每台机器上引入NVMe盘并搭配大容量HDD硬盘。数据写入时，确保WAL的三个副本都写入NVMe盘以保障写入性能。

 

此外，通过HDFS的特性，数据在写入时会优先存储在本地的NVME盘上，其余两个副本存储于其他节点的HDD盘。由于写入的是NVMe盘，因此写入性能提升。

 

在查询阶段，借助HBase的数据本地性以保障数据本地率，结合Compaction进行优化，优先从高性能的NVMe盘读取数据。通过这种方式，该异构集群架构相较于HDD集群性能提升近十倍。同时，将三副本NVMe模式调整为单副本NVMe模式，使集群成本较原先OSSD方案降低近一半。业务上线后，成功满足性能与成本的双重需求。

 

8、长尾：高性能KV选型

 

 

针对长尾问题，货拉拉实施了多项优化措施，包括对Compaction的优化、GC调优、内存优化及不同业务场景的专项治理。然而，由于HBase的架构特性，其无法彻底解决该问题。因此，引入了高性能KV选型方案以应对该挑战。

 

通过调研业界实践，参考字节跳动表格存储、滴滴Fusion及小红书Red KV等案例，发现两条主流路径：基于自研或开源组件的二次开发。具体而言，此类方案普遍采用非Java语言开发，在架构设计上基于单机RocksDB做一层封装，通过Raft或Gossip等同步协议保障数据一致性。

 

经内部讨论，最终决定优先选用业界已有的成熟产品，并结合自身业务的具体问题与痛点进行筛选。筛选过程采用漏斗模型，经初步筛选与二轮评估，从十四款产品中最终选定OceanBase与Lindorm。筛选标准包括：

 

1）业务诉求

 

• 稳定性与性能：要求SLA达到99.99%以上；
• 风控场景：使用图引擎存在多跳查询场景，确保查询P99延迟足够低以避免超时；
• 离线交互：部分业务需大批量数据从离线旁路导入，且导入过程不得影响业务正常读写；
• 接口兼容性：业务可能需对新组件进行接口协议更改，但受限于人力投入，要求新组件兼容HBase协议。

 

2）运维诉求

 

• 成熟性：开源（拥有成熟社区环境和活跃度）或具备商业服务（有大厂背书并具备丰富的实践经验）；
• 稳定性：支持高可用架构，具备完善的监控和trace能力；
• 拓展性：支持动态扩缩容、多云部署；
• 可维护性：具备机房级别的容灾能力、组件依赖少、备份恢复。

 

9、测试与上线

 

 

经筛选，OceanBase和Lindorm两款产品均能满足需求，接下来设计了四种方案进行测试。

 

1）性能测试

 

重点关注Get、Scan和GetList这三类查询场景。测试结果表明，Lindorm与OceanBase表现相当，在部分场景中，Lindorm查询性能略胜一筹。

 

2）功能测试

 

这部分重点关注离线导入和机房容灾能力。

 

• 离线导入：HBase存在大规模数据导入导出需求，Lindorm与OB均能满足；
• 机房容灾：OceanBase以低成本实现该能力，仅需三个副本即可实现跨region容灾，甚至其云产品可支持通过两副本加一个仲裁节点去实现，而Lindorm需六个副本才能达到同等效果。另外，在多云部署方面，目前Lindorm仅能在阿里云使用，而OceanBase支持多云部署架构，更符合货拉拉的业务形态。

 

3）兼容性测试

 

货拉拉日常使用HBase，所以期望只需替换一个版本即可实现升级，Lindorm能完全兼容HBase，因此是最佳选择。

 

4）POC测试

 

目前整体处于POC阶段，两款组件各有优劣，均未完全契合理想选择。待POC完成后，将推进上线并开展数据迁移验证，并期望利用HA能力实现业务的无感切换。

 

10、多级存储架构

 

 

按当前规划及建设，在线存储架构可按成本和性能划分为性能型、异构型、容量型三层，从上到下成本递减，从下到上性能递增。

 

• 性能型：性能＞成本，适配风控策略、实时消息等在线业务；
• 异构型：性能&成本平衡，适配IOT业务、计价等场景；
• 容量型：性能＜成本，适配热力图、洞察日志等业务。

 

不同业务可根据自身应用特点选择适配存储类型，满足业务多元化需求。

 

三、离线存储

 

1、离线发展历程

 

 

1）萌芽期

 

起初，货拉拉采用自建HDFS进行离线存储，随着业务发展逐步转向云存储，通过存算分离，利用价格更低廉的对象存储从而降低成本。

 

2）成长期

 

随着数仓业务逐步扩张，离线存储成本日益高昂，因此建立成本治理体系以降低单均成本。

 

3）成熟期

 

在AI时代下，离线存储正协同支撑公司AI应用的落地。通过分桶而治、专项优化及缓存加速，助力模型训练。

 

2、冷热分层，成本治理

 

 

货拉拉构建了云数据管理平台作为成本治理体系，通过整体成本治理与存储优化，存储成本累计节省54%。其架构划分为三层：

 

1）存储层

 

利用对象存储的冷热分层能力实现存储分层。

 

2）采集层

 

主要构建归档和数据分析能力。通过查询SQL及DMS SQL语句进行数据采集，主要通过在hook中埋点，将这些数据发送至Kafka进行分析，按分区粒度统计热度。同时利用存储层的审计日志功能，补充并校正文件级热度信息，共同构筑完整的分区热度数据，最终存入ES，供上层应用查询使用。

 

3）管理层

 

负责治理推广，包括冷数据归档、温数据展示、数据生命周期治理及数据精细度深度优化。

 

目前，元数据管理平台团队正推进健康分治理与红黑榜功能建设，以形成良性治理循环。

 

3、当前AI时代的背景与挑战

 

 

近年来，大模型的兴起对货拉拉的存储系统带来了挑战。目前，离线存储的下行带宽越来越慢。尽管货拉拉已向云服务商申请较高带宽配额，但仍频繁出现带宽耗尽的情况。

 

在排除业务发展的因素后，发现问题主要源于AI训练任务对带宽的大量占用。由于AI训练数据与离线数仓数据的混用，以及AI训练任务具有访问数据量大、重复拉取等特性，下行带宽长期处于高位，影响离线链路业务的稳定性。

 

4、分桶而治，助力AI

 

 

为解决该问题，货拉拉采用分桶隔离与增加缓存层的方案，具体如下：

 

将AI训练数据与离线数仓数据进行分离处理，并为AI任务增加缓存层以减少重复拉取，降低相互干扰，从而保证大数据的稳定性。初步验证表明，迁移单个模型的数据后，整体下行带宽消耗降低10%。

 

AI模型训练过程对数据拉取和带宽占用较大，同时对存储的性能和吞吐量有较高要求。目前，货拉拉正与腾讯云合作，通过缓存加速层以应对这一挑战。该缓存加速层位于计算层，可及时将底层数据缓存起来，从而减轻对云存储带宽的压力，以较少资源满足AI模型的需求。

 

四、AI向量存储

 

1、发展历程

 

 

1）萌芽期

 

初期为了加速应用落地，团队采取多组件并行搭建的策略。

 

2）成长期

 

随着公司技术实力的增强与应用的稳定，开始进行统一的选型以保障支撑应用落地。

 

3）成熟期

 

随着多模态智能化概念落地，货拉拉在向量存储领域的技术方案逐步演进。

 

2、大模型在货拉拉的应用

 

 

大模型已经在货拉拉的14个业务部门及50多个真实业务场景中投入使用，向量存储在其中发挥着重要的存储作用，包括文生图、文生视频等应用场景，以及利用Rag落地企业知识库的查询助手等。

 

1）智能客服助手

 

 

在企业微信的场景中，客服业务主要面临两个挑战：

 

①体量大：客户数量庞大，客服人员人均对接1000+用户；

 

②效率低：因对接和学习成本导致效率低下。

 

为解决上述痛点，货拉拉借鉴行业经验，开发了一款基于RAG+知识库+LLM搭建的智能客服助手。这款助手将聊天记录中的SOP文档进行分词打标处理，通过Embedding技术存入向量数据库。当用户提问时，系统仅需通过ES进行关键字搜索，接着利用向量数据库进行向量检索。通过Score Fusion做综合排分，重新排序后将问题输入到大模型进行总结并生成标准回答，客服人员只需要进行简单审核即可。

 

2）IT运维助手

 

 

场景痛点：

 

①IT问题解决难度大

 

IT服务涉及的软硬件知识种类繁多，通常具有一定的技术门槛。

 

②问题重复

 

此类问题具有高频重复特性，人工回复耗时且效率较低。

 

为解决这两个痛点，货拉拉开发了内部的IT运维助手。

 

 

用户在前端界面输入问题后，后端会结合用户的基础信息（如姓名、电脑通讯账号等）对其问题进行改写。改写完成问题后，通过大模型进行意图识别，判断当前用户的问题属于哪一个Agent，之后调用对应的Agent执行。

 

系统核心功能为IT问答模块：接收用户问题后，先检索知识库中的相似QA知识，之后拼接到Prompt中，再结合用户的问题提交至大模型进行总结与答案生成。此外，问题改写阶段还会经过“猜你想问”的模块。该模块通过检索IT问题知识库，识别与用户问题最相似的问题，将其提供给业务进行推荐，辅助用户进一步明确需求。

 

具体案例：

 

若用户询问“怎么连接 wifi”，问题会先进入改写模块——系统自动识别用户设备为Mac电脑，将原始问题改写为“Mac 电脑如何连接 wifi”；经意图识别后，判定需接入IT问答模块，随即从知识库中检索与用户最相似的IT问题。

 

为避免召回问题冗长，系统会对召回的问题再次优化改写，使其更简洁且贴合用户核心诉求；最终将“用户原始问题 + 改写后问题 + 优化后召回问题”一同输入大模型，由大模型总结生成针对性回复并反馈给用户。

 

当前，应用系统已集成至飞书工作台，面向全员进行使用，货拉拉的大部分业务问题已实现自主问答，提升问题解决效率。

 

Q&A

 

Q1：如何优化跨云的数据访问效率？

 

A1：货拉拉通常将相同业务形态的数据部署在同一云上，以减少跨云调用。实际上跨云部署会涉及到带宽的流入和流出，这是不稳定的。因此在架构部署上并不建议采用此类设计。而为增强跨云数据传输效率，货拉拉一般采用数据压缩传输、使用专线、增加缓存层等方案。

 

Q2：货拉拉在存储层面如何规划以支持下一代更大规模、更复杂的AI应用？

 

A2：存储架构需从传统模式升级为分层融合、向量原生、智能自治的新体系：通过高性能缓存（如Alluxio, JuiceFS）与对象存储协同，实现训练高吞吐与推理低延迟；多模态存储选型，内嵌向量索引支持语义查询；基于湖（Iceberg）实现就地计算；并利用AI驱动自动分层、预取与成本优化，最终构建安全、弹性、低成本的“AI记忆体”基础设施。

 

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn