欧洲数字化养殖平台 Herdwatch 借力 Iceberg + StarRocks 提升分析能力

作者：Alfred Johnson，Herdwatch 数据负责人

随着业务从爱尔兰和英国逐步拓展至更多国家，Herdwatch 需要一套能够统一管理、灵活扩展的数据平台，既能为客户提供实时洞察，又能支撑日益增长的分析需求。

在早期阶段，我们的分析工作负载依赖于分区域部署的 MySQL RDS 数据库，最初能够满足需求，但很快就暴露出明显问题：

• 数据割裂：各区域数据库相互独立，用户必须切换多个仪表盘才能获取信息，难以实现统一报表分析。

• 性能瓶颈：仪表盘在查询 RDS 只读副本时响应迟缓，常常超时，且缺乏扩展能力，无法满足客户对实时仪表盘的需求。

这些问题让我们意识到，是时候对现有架构进行一次彻底升级了。

为了解决数据割裂与性能瓶颈，我们决定以 Apache Iceberg 为核心，重构数据基础架构。借助 Iceberg，可以将分散在各区域的数据统一整合，构建一个可扩展、高效的数据分析体系。

在引入 Iceberg 后，我们逐步搭建起湖仓一体架构，其中包括：

• 集中式数据湖：所有区域的数据管道统一写入 AWS S3 上的 Iceberg 表，形成唯一可信的数据源。

• 分层 ETL 管道：借助 AWS Glue 与 DBT，将原始数据加工为铜、银、金三层结构，确保数据在转换与聚合过程中得到充分优化。

在引入 Iceberg 之后，我们首先尝试使用 AWS Athena 作为查询引擎。其无服务器模式让我们能够快速上手，但很快暴露出如下问题：

• 高延迟：仪表盘加载通常需要 2–5 分钟，无法满足面向客户的交互式分析需求。

• 可控性不足：无服务器架构几乎没有可调优空间，限制了查询优化。

• 成本高：在高频、复杂查询场景下，按扫描量计费的模式使成本越来越高。

很显然，我们需要找到一个更高效的方案，来兼顾性能与成本。

于是，我们引入了 StarRocks —— 一款专为面向客户的分析场景打造的湖仓查询引擎，兼容 Apache Iceberg 与 Delta Lake 等开放表格式。经过充分验证，我们最终确定采用 Iceberg + StarRocks 的现代化架构，全面应对分析挑战：

• 集中式数据湖：各区域数据管道统一汇入 AWS S3 上的 Iceberg 数据湖。

• ETL 数据管道：借助 AWS Glue 与 DBT，将数据加工为铜、银、金三层，便于数据聚合与优化。

• StarRocks 作为查询层：在金层数据之上，StarRocks 显著提升查询性能，同时支持内部 BI 工具和面向客户的应用。

• 物化视图：对复杂查询进行预聚合，确保最佳性能。

• 面向客户的仪表盘：通过 MySQL 兼容 API 直连 StarRocks，实现亚秒级响应。

凭借 StarRocks 多仓支持和高级安全控制等功能，新架构带来了显著提升：

统一分析

• 将各区域的数据集整合为单一可信源，实现统一报表与简化治理。

• 消除了区域化仪表盘的复杂性。

• 同时流畅支持面向客户的仪表盘和内部 BI 场景。

性能提升

• 查询延迟从 Athena 的 2–5 分钟降低至 StarRocks 的 700 毫秒–1.5 秒。

• 多查询页面的仪表盘实现亚秒级加载。

成本节约

• 从 Athena 的“按扫描计费模式”转向 StarRocks 的缓存能力，大幅减少 S3 扫描成本。

• 借助物化视图优化计算资源，降低临时 Join 的需求。

可扩展性

• 支持数百万条畜牧业记录、覆盖数千个农场的分析，并具备进一步扩展空间。

运维效率

• 通过 Iceberg 与 StarRocks 的 MySQL 兼容性，实现架构统一，降低维护成本

• 借助集中化的数据治理与血缘关系管理，简化开发者上手过程。

展望未来，我们将继续拓展分析能力，重点方向包括：

• IoT 集成：引入可穿戴畜牧设备的实时遥测数据，实时洞察牲畜健康、位置和生产力。

• 直接查询 Iceberg：探索 StarRocks 直接查询 Iceberg 表的能力，进一步简化架构并降低延迟。

• 高级应用场景：扩展支持更复杂的分析需求，以满足企业级客户。