唯品会的StarRocks实践：从架构1.0到2.0的演进之路

运动健康美食

唯品会的 StarRocks 实践：从架构1.0到2.0的演进之路 数据平台团队 唯技术 唯技术 专注技术，一个专属于技术人的号 35篇内容 2024年09月26日 12:00 广东 本文作者：高景、范舟、徐其民、王新春01OLAP引擎在唯品会的迭代在大数据分析中，OLAP 引擎是非常重要的基础组件，负责提供灵活高效的查询服务。唯品会在不同阶段引入了不同的 OLAP 引擎以满足业务需求，从早期的 Presto，到后来的 ClickHouse，均在适合的场景中广泛应用，支撑了业务在线数据分析的需求。随着技术的不断发展，新的 OLAP 引擎如 StarRocks 和 Velox 也相继出现，团队通过调研和测试，从中找到适合业务场景的最佳搭配组合，适时地应用到生产，从而不断提升分析效率。1.1 Presto （2015年） Presto 作为比较老牌的 OLAP 引擎，在 2015 年被引入唯品会，替代了 Greenplum，主要支持数据产品的各类查询需求。目前，Presto 有9个集群，4万+ CPU 核。平均查询量 180万/天，平均扫描数据量 2.7 PB/天，SQL 平均执行时长 17.3秒。在Presto上面，唯品会主要做了如下改进：1、基于负载的集群调度：定制化 Presto 管理工具 Spider/Nebula（新版），支持多集群路由，集群HA，负载均衡，查询回溯，全链路监控等。2、Presto容器化：全部基于 K8S 调度，实现集群的智能扩缩容，优化资源调度和部署效率。3、潮汐互借：Presto 的查询高峰集中在白天工作时间，凌晨时除了 DQC 等任务外，查询量大幅减少。为此，夜间会对 Presto 集群进行缩容，将上万核资源调度给 Spark ETL 任务，以提升整体服务器的利用率。1.2 ClickHouse （2020年）自从2020年ClickHouse被引入唯品会大数据团队后，在OLAP场景下一直发挥着重要的作用，主要解决对响应时间要求比较严格的场景。具体参见：ClickHouse在唯品会的实践另外，ClickHouse 在日志场景也发挥了重要作用，在2022年替换了 Elasticsearch，成为日志系统 2.0 架构的核心组件。具体参见：基于ClickHouse的下一代日志系统技术揭秘BulkLoad离线导数虽然 ClickHouse 作为一款查询性能卓越的 OLAP 引擎，每天处理唯品会上百万次的查询请求，但在使用过程中，我们也遇到了一些问题。比如用户离线出仓数据到 ClickHouse 的场景，当大量写请求同时发生时，查询性能会明显下降。正常情况下，查询响应时间在几百毫秒内，但在写入高峰期可能延长至几十秒。为解决这一问题，我们通过调研发现 ClickHouse-local 是一个理想的选择。 ClickHouse-local 是 ClickHouse 内置的单机引擎，无需完整的 ClickHouse 服务器，使用简单的 SQL 命令即可使用 ClickHouse 的核心功能。原本我们通过 Apache Seatunnel 的 ClickHouse Sink 功能，利用 Spark 引擎读取 Hive 数据并通过 JDBC 写入 ClickHouse。采用 ClickHouse-local 改造后的流程主要包括：1、Spark 读取 Hive 数据后，先将数据以 binary格式存在 Spark Task 本地磁盘中；2、调用 ClickHouse-local，读本地 binary 格式数据，转换为 ClickHouse MergeTree 格式；3、最后，将 MergeTree 格式的数据通过 SSH 传输到 ClickHouse 集群，并使用 ClickHouse Attach Partition 命令加载对应的数据。 由于部分 ClickHouse 用户经常需要重刷过去30天的数据，导数过程中容易导致CPU飙升，查询响应变慢，而采用Bulkload版本出仓方式后，仅需在步骤三把数据传输到 ClickHouse 集群，调用 Attach Partition 过程中CPU 和内存消耗极少，对查询性能几乎没有影响。1.3 StarRocks （2022年） 随着业务需求的变化，ClickHouse 虽然在大宽表场景下具有明显优势，但在处理 JOIN 等复杂分析时暴露了短板。团队内部有一个重要的自助分析产品，通过指标建模，可以高效的支持内部运营和商务的取数、看数的需求。由于维度建模需要频繁的 JOIN 操作，继续在 Presto 上提升查询效率面临瓶颈，因此团队开始寻求新的查询引擎。最终，StarRocks 被选为首选试点。OLAP 引擎间横向对比除了性能、代码质量和生产环境的稳定性等因素外，我们还重点关注以下几个方面：1、支持国产优秀的开源 OLAP 引擎，因为团队需要大量定制化来适应业务，并将其无缝嵌入现有生态系统的需求。2、活跃的社区，能够及时响应问题和需求。3、背后的商业公司有推动 OLAP 生态发展的愿景，实现双赢合作。在 2022 年下半年，唯品会引入了 StarRocks，并于 2023 年 Q1 开始大规模使用基于 StarRocks 2.5 的“唯品会计算向量化 OLAP 架构 1.0”（下文简称“架构 1.0”），逐步替代自助分析业务中原有的 Presto。该架构带来了 5 到 10 倍的速度提升，P70 查询耗时显著缩短，极大改善了用户体验，获得广泛好评。为进一步解决大查询慢、存储成本高、集群弹性差等问题，架构不断演进。到 2024 年上半年，所有业务全面迁移到基于 StarRocks 3.1 存算分离的“唯品会计算向量化 OLAP 架构 2.0”（下文简称“架构 2.0”）。通过优化多种软硬件方案和参数，该架构不仅大幅提升了整体计算能力，还有效降低了成本。02StarRocks在唯品会的应用和落地2.1 计算向量化架构1.0-自助分析业务加速 (2023) 在 2023 年 Q1，唯品会自助分析业务率先采用基于 StarRocks 2.5 的存算一体 “架构 1.0”。一经推出，多个重要业务部门迅速给予好评，特别是其查询速度基本稳定在 5 秒以内，符合用户的预期响应时间。系统每天有上千人使用，2023 年共节省 822 人天，显著提升了整体工作效率。到2023年底，整个集群查询量较期初增长了4倍，资源利用率在双11、双12活动大促、运营推广、复盘、年末汇算期间长期保持在85%以上，月均查询量超过18万次。系统支持多个主题查询，数据可查询范围可追溯至2019年全年，查询 p70 低至8秒，p90 能始终保持在60秒内。在降本方面，最显著的效果就是直接从系统抽机器。集群大部分采用 E5 2683 v4 旧机器，仅保留少量 Intel 4314。通过对淘汰机器改造和使用 StarRocks 后，系统成功减少了 70% 的机器数量，查询速度依旧提升了5-10倍，极端情况 CPU core 数量可以达到1：5的交换比，充分展现了 StarRocks 强大的性能优势。2.1.1 数据导入服务团队开发了独立的数据导入服务，专门处理建表、数据导入及 DQC（Data Quality Check） 等任务。单个集群每天需完成约 500-1000 次全表或分区更新，若需刷历史数据，分区更新次数可达数千次。服务内置多个接口，支持单分区、多分区，以及批量、定时、延时等不同类型的数据更新需求。导入过程十分高效。100GB 级以内的分区更新通常在几秒到几分钟内完成。对于 TB 级数据，服务优先将数据写入 SSD，待完成 compaction 等高 I/O 操作后，空闲时间逐步降冷到HDD。在时效性要求较高的离线表场景中，服务可按照 Hive 表的更新级别实现同步更新，支持小时级甚至半小时级更新。StarRocks通过 Broker Load 的数据载入流程StarRocks 的数据载入过程主要分为 ETL -> Loading -> Commit 三个步骤。根据数据量和数据所在的 BE 节点当前负载情况，加载时间从几分钟到数小时不等。在此过程中，系统或数据问题可能导致加载失败。因此，我们需要一个数据载入状态与历史管理模块，实时监控数据载入状态，并在任务失败时自动触发后续处理。具体步骤如下：1、外部系统通过 HTTP 发送数据更新事件后，平台首先将事件记录至 MySQL 。然后生成对应的 Load 语句和事件ID，将其发送给指定的 StarRocks FE 开始加载数据。同时，平台通过轮询和 FE Callback 的机制获取当前任务状态，实时更新 MySQL 状态表中对应记录。2、如果任务失败，系统会自动重试，并更新到 MySQL状态表对应记录中。3、任务状态关联对应表或分区查询，获取最新的加载状态（成功/失败）及加载时间。随着 2024 年架构的升级，原先的“在 Spark commit 阶段发送更新信息”的方案被替换为使用“Flink 监听 Hive MetaStore MySQL 的 Binlog”触发自动数据导入的新方式。在此过程中，服务还增加了大量与元数据相关的接口。 Flink 任务定时通过调用元数据接口，获取需要监听的表和分区信息，并将相关更新事件返回给服务。服务也增加了多项控制功能，例如：导入数量限制、回刷历史数据时使用批量导入功能、以及是否将任务安排在周末或夜间空闲时段执行等。在出仓数据导入方面，StarRocks 具有显著的优势，它可以直接在 Hive 上进行分析，无需进行出仓操作。在需要构建内表的场景下，导入时间通常能在秒级完成，极大满足了对时效性要求高的业务场景。众所周知，大数据 4V 理论中，时效性（Velocity）对商业价值至关重要，延迟会导致非线性衰减。与 ClickHouse 相比，StarRocks 省去了 Hive 表打宽和出仓的 Spark 任务，统计显示，这部分时间节省了 1-3 小时，同时也减少了相应硬件资源的占用。此外，这种方式还降低了平台和业务团队在打宽和出仓任务上的维护成本。在性能无显著优势的情况下，ClickHouse 在其他功能方面已难以与 StarRocks 竞争。2.1.2 数据质量DQC目前，DQC 通过行数对比的方式进行数据校验。系统采用事件驱动和定时调度相结合的方式，对 StarRocks 内表进行部分或全量数据的一致性校验，确保数据的一致性。未来，除了极少数对性能和 SLA 要求极高的场景，内表架构将逐步被摒弃，转向大规模应用湖仓一体化方案。然而，类似内表这样的存算一体架构在大数据 OLAP 场景中的查询能力上限极高，仍是一个值得探索和学习的方向。2.1.3 查询加速1.0-冷热数据优化为降低成本，团队从各系统中回收淘汰的旧机器再利用。由于这些机器型号较老、故障率高且硬件配置不一致，查询时常出现木桶效应，导致团队在机器和存储空间均衡上花费了大量精力。在数据冷热优化方面，团队发现 StarRocks 自带的数据降冷方案无法满足需求，因此开发了一套基于查询情况自适应冷热数据自动上浮降冷的方案。通过改配和升级操作系统至华为欧拉 Linux 5.10内核，开启 bcache 模块，使用一张NVME 搭配多张 HDD 解决大规模冷热数据上浮下沉。根据业务查询特性，将部分数据始终保持在 SSD 上，同时结合LRU 算法，确保冷数据变热后自动上浮至 SSD。最终，数据在高速存储盘的缓存命中率最高达到80%，查询从 I/O-Bound 转换为 Computation-Bound。在开启 CPU 睿频和 SATA-SSD (RAID5) 的共同加持下，查询速度提升了 30-65%，大幅改善了 I/O 效率。通过一系列优化，整体性能已在公司内部和业内达到领先水平，而这也仅是优化工作的开始。2.1.4 StarRocks存算一体架构的优势 StarRocks 存算一体是一种比较稳定的一体化架构设计，几乎无外部依赖，能够避免外部组件故障带来的连锁反应，特别适合对稳定性要求极高的业务场景，这也是唯品会将其首先用于核心数据计算的主要原因。相比传统的 HDFS+Presto 存算分离架构，StarRocks 存算一体直接从本地读取数据，避免了因读取远程存储HDFS带来的网络和数据盘的双重开销和抖动。因为 HDFS 本身承载各种长短流，需要应对各种高并发、高吞吐等突发性高流量，参数调优上需要兼顾各种情况，导致其参数调优必须平衡多种需求，难以专门针对 OLAP 场景进行查询优化。这也是把数据保存在本地高速存储能对查询速度有极大提升的原因。此外，随着业务发展，跨机房访问的网络瓶颈（如跨机房带宽或交换机上联打爆）逐渐暴露，而 HDFS 的整体性能很难短时间内大幅提升到本地存储的水平。因此，本地化数据存储与计算成为提高查询速度、降低成本的关键因素。Presto集群与StarRocks集群的性能表现对比我们在测试中对比了Presto集群与StarRocks集群的性能表现。在一个有100+物理机的 Presto 集群中抽取耗时最长的 500个 query，其中约210个 query 耗时触及1800秒 timeout（如下图中蓝线所示）。对标的是StarRocks 19台 Xeon E5-2683V4 64C 的测试集群，开启 block cache 并设置 3600 秒 query timeout 后，逐条重新执行这些查询。尽管测试期间遇到了网络瓶颈（达到上联带宽极限），但 StarRocks 的性能仍显著优于 Presto，这进一步证明了数据本地化对查询速度的重要性。（参考StarRocks vs. Trino: 解密高性能背后的技术优势）随着当前EB 级HDFS 正逐渐趋于向冷存储和跨机房容灾发展，StarRocks 则通过尽量减少对慢速存储设备的访问、避免大数据量跨机房传输，进一步体现在数据查询效率上的优势。随着业务的不断推进，团队希望覆盖更多业务场景和更广泛的数据，由 ADS/DWS 往 DWD 迈进。这也带来了更多的挑战，例如如何在继续压榨机器资源、降低成本的同时提高查询速度，支持更多季度和年度数据的查询需求。此外，团队还面临着支持多集群路由、大查询的资源隔离、冷数据查询以及内外表联邦查询的需求。基于这些业务需求，团队在 2024 年 Q1 初适时地推动了业务架构向 “架构 2.0” 。2.2 计算向量化架构2.0-启用存算分离（2024）正如上节所述，"架构 1.0" 采用的 StarRocks 存算一体版虽在性能上具备优势，但也存在一些局限性，首先对机型存储容量的一致性要求较高。计算和存储资源的紧耦合，导致独立资源的弹性扩展能力不足。所以，团队从2024年Q1开始逐步推出 "架构 2.0" ，采用更加紧密的软硬件结合方案，并支持多数仓的架构设计（参考 《The Snowflake Elastic Data Warehouse 》SIGMOD 2016）。架构 2.0" 底层计算引擎基于使用 StarRocks 3.1 存算分离版，开启Data Cache功能 （参考 StarRocks 存算分离 Data Cache 二三事）。利用公司海量跨机房HDFS的数据存储和管理能力，做 StarRocks 内表和 Hive 表的 Data Storage。计算节点统一更换为能达到3.5GB/s的大普微，ScaleFlux，三星等多家厂商的NVME PCIE3.0盘作为本地缓存。因为缓存数据为1副本，空间成本较原先 "架构1.0" 的3副本的下降70%，热数据的吞吐单盘效率提升7-15倍，整机性能提升在3-5倍。截至2024年8月底，底层由 StarRocks 承接的 OLAP 分析业务月查询屡创新高，查询量突破35万大关。尽管月查询量增加2.33倍，查询性能丝毫没有受到影响，2024年 H2 相较于 H1 环比，p90 提升了 32%，p95 提升了 37%，p99提升了 50%。在 CPU 核心数和底层引擎不变的情况下，通过优化系统，自 2024 年初起，每季度以平均 20% 速度提升，且还有巨量的潜力可以挖掘。为了支撑激增查询业务，目前我们启用了3个集群，百余台物理机。然而，由于大多数机器较为老旧，需要经常维护，集群的常态妥善率维持在68%左右。集群按照一定的业务特点分配请求流量，除了由8台 AMD EPYC 9654 机器组成的存算一体集群外，剩下上百台物理机（约9000 core）均使用 StarRocks3.1 版本的存算分离架构，体量约为同类计算节点整体的3%左右。集群内部数据对等，部署在多个机房，保障了业务在机房或者网络出现故障时，核心查询请求不受到长时间的影响。随着 2024 年下半年来自人工智能服务和各业务线的电商大促请求量的增加，集群 CPU 核数需要进一步降低成本，预期集群还需支撑当前查询量 2-3 倍以上的请求，这无疑将带来巨大挑战。与此同时，架构正在逐步从 2.0 向 3.0 过渡，这意味着未来的优化工作量将更加庞大，团队也需要在这段过渡期内解决更多的问题。2.2.1 查询加速2.0 - 性能优化实践在性能优化的过程中，硬件往往决定了系统的能力上限，而软件的目标则是尽可能压榨硬件性能直至接近物理极限。在进行架构设计时，软硬件深度协同的方案尤为关键。通常在第一阶段，我们会根据具体业务需求，选用适当的软硬件组合。随后，通过一段时间的系统运行和量化分析，找出系统中比较明显的短板并补齐。在各种搭配组合达到均衡之后，若需针对业务做进一步定向优化，使得某些能力得到更加充分的发挥，这阶段就不可避免需要权衡利弊做些取舍。正如《Fundamentals of Software Architecture》所言 "Everything in software architecture is a trade-off."通过使用多种性能测试工具（如vtune、pvm、flame、perf等）评估后得知：在当前业务特点的作用影响下，现有系统的主要瓶颈点粗略估计排名：50% 的瓶颈在I/O（存储或网络）30% 在内存带宽和容量15%在各种锁和 SIMD 向量化指令集其中I/O的影响尤为突出，表面上看 CPU 利用率很高，很多计算资源实际被浪费等待数据环节 （引用 CPU Utilization is Wrong），这也是降本增效中误区之一，盲目追求提高 CPU 使用率，认为 CPU 使用高就是资源充分利用，而忽略了分析 CPU 真正用在了什么地方，或者解决哪些卡点。Brendan's Off-CPU Analysis在"架构2.0"中，我们在大幅降低成本前提下对机器进行了针对性的调整，几乎消灭在 I/O 上等待的时间。架构上线后，CPU 使用率下降了40-60%以上，程序90%的时间都在用户态运行，查询性能得到大幅提升，尤其是大查询耗时显著下降，真正将 CPU 资源用于业务处理，也只有这种情况下谈计算向量化才有意义。虽然向量化理论上能够带来8-10倍的性能提升，但由于其准入门槛非常高，在实际生产环境中往往达不到这种理想状态。因为首先需要有足够的 I/O 吞吐和内存带宽来确保数据能及时送达 CPU 的各级缓存和寄存器。通常，IPC（instruction per cycle）是衡量处理效率的重要指标。未经优化的应用往往无法达到 1，很多情况下甚至不到 0.8 或更低，甚至不到 0.4，但上限通常可以到4 （参考向量化编程的精髓）。其次，在当前的大数据生产环境中，组件之间的依赖性越来越强，优化难度也相应增加。此外，还有许多“tax”可以优化。例如memory相关、压缩格式（如 LZ4/ZSTD）以及 UDF等。公开的性能测试报告或线下环境测试数据都非常"漂亮"，因为这些测试大多在理想环境下进行。但生产环境复杂多变，结果往往未达预期，主要原因就在于对运行环境的理解不足，缺少有针对性的优化。ISCA '15Profiling a warehouse-scale computer在成效方面， "架构2.0"使查询速度相较于 "架构1.0" 提升了50%以上，尤其是p99 达到了接近5倍的提升。Case1：在2024年Q1末，StarRocks 使用30台利旧物理机支持了 Presto 的查询量的7倍，查询耗时降低一个量级水平，集群规模实现了1:5的交换比。Case2: 充分利用操作系统特性，集群cn节点的 query_scan_bytes 指标最高达到70GB+/s，核心业务查询所需的计算资源几乎不再浪费在I/O 等待上。Case3: 充分利用NVME的加速能力，部分类型大查询已经能同时达到多项硬件物理限制，说明短板已补齐，资源获得充分利用。在基建研发方面，“架构 2.0” 全面采用 Docker 容器封装，极大地降低了部署和运维的人力成本。此外，容器内部使用了较新的 Ubuntu 22.04，其 glibc 通过 indirect function 机制自动适配根据 CPU 架构优化的函数，尤其在大数据量的场景下，提升了内存操作性能。经过对 StarRocks 相关代码的修改和升级 glibc 版本后，memset 和 memcpy 操作在 Intel 6130 等多种机型上的耗时，在华为欧拉 Linux 5.10 内核下的 benchmark 测试中减少了约 40%。在引入 XSIMD 库和开启 AVX512 指令集后，各类机型性能提升了 5%-10% 不等，特别是在清理了一些 BE 内部的历史代码后，整体性能也得到了相应优化。2.2.2 优化HyperLogLog函数因为业务需要大量使用 HyperLogLog 函数计算UV/PV等数据，特别是流量曝光等场景中，处理的数据集规模巨大，单个分区的常见数据量在10-100亿级别。过往用户查 Presto 需要控制在30个分区内，一个大跨度查询必须拆成多个SQL逐一运行，非常不便。为此，团队在以下方面进行了优化：1、对表进行了列裁剪，配置合理的字段类型/分桶参数2、增加 XXHash 函数到 StarRocks，并提前把参与 HLL 计算的字段转为 BIGINT 的 hash 值等多方面优化，充分享受 SIMD指 令的位宽。通过这些优化，原本在离线 Spark 上需要耗时十几分钟的请求，现在在 StarRocks 上实现了 300 个分区的过滤与 UV 计算，并做到秒级出数。此外，还有在灰度测试中的新HLL模块，借鉴 Meta(Facebook)Velox 的 HyperLogLog 实现，替换 StarRocks 自带的相关函数，使得二进制兼容由Spark使用Java 版 HLL UDAF 写入Hive的预聚合结果。此改进进一步利用 了SIMD 指令和预聚合带来的加速作用，并且大量计算可以放到离线系统，进一步减少 StarRocks集群规模。通过这种方案，整个架构可以更好地与现有的大数据环境融合。如下图所示，C++ 的实现耗时基本上是传统Java的20%-25%。2.2.3 StarRocks视图实践自2023年Q1 StarRocks 开始投入业务以来，一直使用内表作为数据源，其优势是读取速度相较于读 HDFS 更加高效，然而，内表的使用也暴露出一些缺点：1、数据本地存储，有容量上限；2、数据需要及时导入，尤其是需要小时/半小时级更新的表；3、需要时刻保持与 Hive 原数据一致；4、在多集群多架构下，导入的时间差使得集群间的数据一致性难以维持；为了应对这些挑战，团队于2024年H1末开始研发视图（view），结合内部自研 SQL 路由的 SQL 改写 rewrite 功能。通过配置视图，可以灵活调配使用 StarRocks 内表和外表（直接访问 Hive+block cache 加速）的分区比例，弥补了之前仅使用纯内表模式的局限性。如图所示，整张表可查询范围从 20190101 到 T天（即整个视图可查询范围）。同时用户配置了一张对应的内表并嵌入到视图中。当查询在内表可视范围（从内表 TTL 到 T-30天）内的时，查询速度得到了显著提升，也兼顾到了大时间跨度查询的需求。StarRocks 视图优势1、时效性提升：当天数据直接来自Hive，没有 Load 过程耗时（尽管这部分已经能控制在10-20分钟，视数据量而定）2、降低集群压力：特别适用于每天都需要大范围（比如DT更新范围在30、60天）更新的表，或者高频次（主要是小时/半小时级）更新的表3、提高高速存储的利用率：根据查询冷热及存储空间限制调配内表范围。特别是一些访问较少的大表，存储空间可减少50%-90%4、灵活模式支持：视图支持多种模式，如固定窗口、滑动窗口，以及纯外表或内外表混合模式5、基于DQC校验配置更新视图，可以有效避免内表分区导入异常带来的查询失败6、扩大了整个数据可查询范围7、轻量化的数据转换2.3 小结大数据领域已经经历了数十年的发展，按照 Gartner Hype Cycle 技术成熟度曲线标准，领域早就进入了生产力成熟期，许多创新或者改进也乏善可陈。近些年，领域内的一部分先驱公司纷纷改用可以充分利用向量化技术的C++语言重写提升查询速度。StarRocks 作为一款市面上少有的优秀产品，如和煦春风一般吹进 OLAP 领域。不仅支持了大量加速特性，同时经过唯品会大数据团队的不懈努力优化，能够有机地嵌入到当前公司内部整个大数据生态里，把查询性能和投效比都提升到了一个新的高度，达到公司内部和业内领先水平。随着近两年的优化迭代，相关的配套和最佳实践已趋近成熟，Presto 和 ClickHouse 将会逐步收敛到基于 StarRocks 的新架构上，给公司商业数据分析和决策带来无法估量的价值。 此外，在实践中我们还积累了宝贵的经验：1、硬件性能极限的不断突破：通过验证不同的数据处理技术和各种组件搭配，持续挖掘硬件潜力，不断突破OLAP查询性能的上限。2、降低外部组件依赖的重要性：减少外部组件的依赖度，摒弃了层层堆栈带来的累积风险。3、破除降本提效中 CPU 占用率以高为优的迷思：通过辩证的视角审视各种优化观点，结合量化手段观察系统环境，精确定位主要瓶颈点，用有说服力的数据验证架构设计的优劣。032024年下一步迭代 随着越来越多的重要业务接入，查询请求不断上升，系统对并发吞吐、查询速度、集群稳定性、资源利用率等多方面都有了更高的要求。现有架构设计正逐步往跨机房多集群、多活容灾、资源切分隔离、计算弹性方向发展。其中重点的一些方向包括： 计算向量化架构3.0经过两代架构的演进，整个系统已经在OLAP领域无论是查询速度、功能特性还是投效比 ROI 都领先于其他同类系统，各项指标在相关领域处于领先水平。然而，仍有大量潜力尚待挖掘。目前系统正处于是向量化的初级阶段。代码中仍有很多可以优化的部分，以提高机器的 IPC。例如，全面启用 AVX512，加入更多支持向量化函数以及支持 GPU 的算子等。数据模型配合使用gluten，可以进一步加速模型迭代和优化，减少大字符串，改为合适大小的数字类型等。优化方面借鉴多个同类OLAP产品中优秀的部分继续兼收并蓄提高各方面性能，例如提高内存带宽利用率，优化内存用量，优化NUMA方案等方面。在系统优化方面，操作系统将升级至阿里巴巴的 Anolis 更高内核版本，以支持 IO_URING。在网络和存储带宽上，200G 以上的 RoCEv2 网络将帮助兼顾存算分离与就近计算，初步目标是远程数据访问速度超过 10-15GB/s，以充分挖掘机器计算潜力，预计效能提升可达 4-8 倍。跨机房多数仓架构方面，SQL查询支持在多个OLAP引擎间自动选择。这也加速了业务接入新引擎新架构。同时，元数据管理也积极接入 Gravitino 中。多机房容灾 在多机房容灾建设过程中，唯品会大数据存储 HDFS采用了多个机房均有副本的数据布局方式。唯品会团队替换 StarRocks 自带的 HDFS 客户端，改用支持 IDC-aware 的 自研HDFS 版本，做到集群的FE和BE同时在多个机房内部署，即使某个机房发生故障，OLAP 服务能够在短时冲击后快速恢复，保持稳定运行。 湖仓一体唯品会正在积极推进数据湖建设，特别是在电商场景中，数据的 upsert 能力是一项广泛的需求。通过结合 StarRocks 引擎的高效分析能力与 Paimon 的数据更新能力，提升数据迭代的时效性。 缓存加速 为了进一步优化数据缓存并提升分析性能，唯品会正在考虑重新启用 Alluxio，以便多个 OLAP 引擎能够共享加速访问跨机房 HDFS 上的数据。此外，我们也在调研 Ceph（Crimson） 或 Kubeblock 等支持云原生的存储方案，以便更好地支持类似 local cache 这类需要本地存储的组件。 智能BI分析加速 结合大模型进行指标分析的数据产品是当前落地的热点方向，唯品会也在积极推进这一领域，以提升数据产品的智能化和价值。通过大模型驱动，能够实现自动化分析与指标根因挖掘。智能分析场景通常需要执行大量Query，并且对响应时间有严格要求，以便及时返回查询结果供模型进行洞察。传统的数据产品查询往往是用户通过点击按钮来发起页面所需的数据请求，而结合AI后，可以通过指标维度的拆解，自动进行归因和下钻分析。这种方式可以一次生成多个相关性强的查询，查询请求量是过去的数倍。基于 StarRocks 良好的可扩展性和高性能，在智能 BI 场景中能够充分发挥出自身的价值特点。---------- END ----------致谢在此特别感谢北京镜舟科技有限公司所有的同学们给予的强力支持，特别鸣谢以下几位（按照姓氏拼音顺序）：蔡小华、崔静、丁凯、董念、董颖婷、冯浩桉、冯宇、耿军、姜扬军、景丹、康凯森、李书明、梁文磊、孟庆欢、冉攀峰、王欢明、王思墨、王衍波、夏德军、章炎、张友东、赵纯、赵恒。十分感谢唯品会大数据平台和DBA运维的各位伙伴们在项目中的大力支持，同时向唯品学堂在本篇文章审稿和排版工作的投入致以谢意。PS：本文所参考引用的文档链接，请关注唯技术公众号后台留言“StarRocks”即可获取跳转链接。扫码关注公众号唯技术