可观察性平台的发展已从孤立的数据仓库和昂贵的专有索引转变为统一的湖屋架构，这些架构结合了数据湖的灵活性和仓库的性能。早期的 SaaS 可观察性提供商依靠 Elasticsearch 或 Splunk 集群，这些集群在 PB 规模上面临着指数成本曲线，并在真正的多租户隔离方面面临挑战。像 Apache Iceberg 和 Delta Lake 这样的开放表格式的出现使得在对象存储上实现原子事务和时间旅行成为可能，而 Trino 等查询引擎逐渐成熟，以提供对云存储的交互式 SQL。这种融合创造了从单一共享基础设施服务数千个租户的可能性，但在维护低于一秒的延迟、执行严格的安全边界以及通过智能分层优化存储成本方面引入了新挑战。
核心挑战在于协调相互冲突的需求：每秒摄取数百万个来自不同代理的事件（Fluentd、Prometheus、OpenTelemetry），同时对数十亿的历史数据提供交互式查询性能。传统的无共享数据库在跨租户的查询噪声中崩溃，而每个租户的孤立则造成了巨大的操作开销。严格的隔离要求租户 A 的查询不能实际扫描租户 B 的数据，但行级安全过滤器往往会引入性能悬崖。此外，将所有数据存储在热 SSD 上在经济上是不可能的，但将冷数据移动到 Amazon S3 Glacier 却有可能在归档数据突然被查询时违反低于一秒的 SLA。目录服务——跟踪分区和模式演变——必须保持去中心化，以避免在高速摄取时成为故障单点或吞吐量瓶颈。
构建一个分层湖屋，使用 Apache Iceberg 作为表格式，位于 Amazon S3、Azure Data Lake Storage 或 Google Cloud Storage 之上。通过 Apache Kafka 或 Amazon Kinesis 摄取数据流，使用 Apache Flink 或 Spark Streaming 处理，并将数据存储到适当的层：热层（查询节点上的本地 NVMe SSD）、温层（S3 标准），或者冷层（S3 Glacier 实时检索）。部署 Trino 或 Presto 作为分布式查询引擎，配置 Apache Ranger 或 AWS Lake Formation 以实现行级和列级的安全策略，在扫描级别强制执行租户边界。使用 Hive Metastore 联合或 AWS Glue 的区域副本实现去中心化的目录，以避免集中瓶颈。自动分层由基于机器学习的热图分析器驱动，该分析器监控查询日志，将经常访问的冷数据提升回温存储，并将过时的热数据降级，同时维护 Iceberg 中的元数据指针，以确保跨层查询的透明性。
详细示例：
NebulaObservability，一家为 12,000 家企业客户提供服务的 SaaS 提供商，需要更换其老化的 Elasticsearch 集群，该集群在 8PB 存储时每月成本为 200 万美元。每个客户每天生成 2-10TB 的日志和指标，需要进行低于一秒的仪表板加载时间的临时 SQL 分析。监管要求严格隔离，客户 A 不能通过时间攻击或查询错误推断客户 B 的数据存在。数据保留期要求为 13 个月，但 95% 的查询仅命中过去 72 小时的数据。先前的架构遭遇了“嘈杂邻居”问题，其中一个客户的大型聚合查询会降低其他客户的性能。
解决方案 1：分片 ClickHouse 集群
考虑部署大量以租户为基础分片的 ClickHouse 集群。优点包括卓越的单查询性能和成熟的 SQL 支持，具有向量化执行。然而，缺点相当严重：管理 PB 级集群的操作复杂性、在不降低性能的情况下执行行级安全的难度，以及存储与计算无法独立扩展。此外，在租户入驻期间重新分片 ClickHouse 集群需要数小时的停机和手动干预。
解决方案 2：每租户的 PostgreSQL 和 TimescaleDB
为每个租户提供孤立的 PostgreSQL 实例及 TimescaleDB 扩展提供了完美的安全隔离和简单的备份策略。优点很简单：原生行级安全、GDPR 的简单租户删除、没有跨租户干扰。然而，缺点使该方法变得不可能：管理 12,000 个数据库实例、修补周期和连接池耗尽的操作噩梦。与列式格式相比，存储成本因缺乏压缩而飙升，而跨租户分析对提供商的自身使用洞察变得不可能。
解决方案 3：分层存储的联邦湖屋
实施基于 Apache Iceberg 的湖屋以及 Trino 和自动分层提供了最佳平衡。优点包括共享基础设施的规模经济，Iceberg 的隐式分区防止用户错误，以及 S3 的无限可扩展性。通过 Apache Ranger 的行级安全性允许在不修改查询的情况下实施细粒度策略。自动分层通过将冷数据移动到 S3 Glacier 来降低存储成本 70%，同时保持元数据的热状态。缺点涉及显著的调优复杂性：查询规划需要仔细的分区修剪，而分层算法需要训练数据以避免抖动。
选择的解决方案及原因：
选择了解决方案 3，因为它独特地满足行星规模的要求，同时保持严格的隔离。Iceberg 格式对表元数据的原子更新能力允许在零停机部署中进行模式演变。Trino 的连接器架构使得将谓词下推到 S3 成为可能，减少扫描的数据。使用 AWS Lambda 函数触发的自动化分层，基于 Athena 查询日志确保在没有人工干预的情况下实现成本优化。这种方法将存储与计算解耦，允许在流量高峰期间独立扩展。
结果：
系统在 12PB 活动数据上实现了 650ms 的 p99 查询延迟，在高峰时段支持 50,000 个并发查询。与之前的 Elasticsearch 架构相比，存储成本下降了 68%，每月节省 136 万美元。自动分层正确预测了 94% 的数据访问模式，冷存储的“缓存失误”发生率仅为 0.3%。在前 18 个月的运营中记录到零个与跨租户数据泄漏相关的安全事件，经过季度渗透测试验证。新租户的入驻成为一个纯元数据操作，耗时不超过 30 秒。
如果自动化分层算法错误地降级了“温”数据，而该数据突然被计划的批处理报告访问，怎样防止查询延迟爆炸？
候选人常常建议被动缓存，而没有考虑预测机制。详细的答案需要实施一个预测性分层系统，使用查询访问日志的指数平滑，在降级到 Glacier 之前，在 S3 标准-IA 保持一个“温热”的中间层，具有毫秒级的首字节延迟。此外，在 Trino 和 S3 之间部署 Alluxio 作为分布式缓存层，以吸收意外的访问高峰。关键细节是实现“读取时提升”：当冷数据被访问时，系统异步将其复制回温层，同时从 S3 Glacier 实时检索 处提供当前请求，确保后续查询命中更快的存储。
如何在没有全局事务协调器成为瓶颈的情况下，跨数千个租户表维护模式演变（添加列）的 ACID 一致性？
大多数候选人提出分布式锁，这违反了“无集中瓶颈”的要求。正确的方法利用了 Apache Iceberg 的乐观并发控制和元数据分层。每个租户表都有一个独立的 metadata.json 文件传承。模式更改附加一个新的元数据文件，并递增序列号；目录（例如 AWS Glue）仅存储指向当前元数据文件的指针。在提交期间，写入者检查指针是否已更改（冲突），如有必要重试。这消除了全局锁的需要，因为租户表是独立命名空间。对于罕见的跨租户模式更新（例如，添加通用列），使用一个拥有幂等 DDL 操作的提议模式，而不是原子事务。
如何设计行级安全层，以防止“超级租户”执行全面表扫描，从而消耗其他租户的 CPU 资源，违反低于一秒的 SLA？
候选人经常遗漏资源治理机制。解决方案涉及使用 Trino 的资源组进行层次化资源隔离，为租户类别（高级 vs 标准）设置硬 CPU 限制和内存配额。实施接入控制，使用 Trino 的基于成本的优化器估算查询成本；超出特定租户阈值的查询被排队或拒绝，而不是执行。使用 Kubernetes 资源配额将查询引擎 pod 隔离到租户特定的节点池中，以防止 CPU 消耗殆尽。最后，实施查询终止策略，对于超出预测成本的长期扫描，结合常见昂贵聚合的物化视图，确保即使恶意或意外的全面扫描也不会影响其他租户的延迟。