RTL Germany 如何借助 Elastic Observability 冻结层将数据保留期延长至三倍，并在切换过程中实现零中断

RTL Germany 重新构想了其集中式数据湖架构，将标准数据保留期限从 30 天延长至 90 天，将节点数量减少近一半，并在迁移过程中实现零数据丢失。

RTL Germany 运营着一个覆盖全公司的 Elastic 数据湖，该数据湖经过近十年的发展，已成为各部门用于日志记录、应用程序数据和商业智能分析的标准平台。由于本地存储容量上限为 100 TB，标准数据保留周期一直被限制在约 30 天，这不仅阻碍了团队分析数月内 KPI 的变化趋势，也迫使合规数据存储在可搜索式数据湖之外的独立 S3 存储桶中。从白金级升级到企业级后，RTL Germany 基于可搜索式快照和冻结层重新设计架构，使标准数据保留周期延长至 90 天（提升至原来的 3 倍），在相同许可规模下总容量增长至 235 TB，虚拟化基础设施节点数量从 18 个物理节点减少至 10 个，并且整个迁移过程实现零中断、零数据丢失。

RTL Germany 的 Elastic 数据湖覆盖了近十年来整个广播和媒体业务中的公司级日志记录、应用程序数据以及商业智能数据。到 2024 年，该数据湖的发展遇到了瓶颈。约 100 TB 的本地存储容量将标准数据保留周期限制在约 30 天，但多个部门需要保留数月的历史数据，以跟踪 KPI 随时间的变化趋势；同时，根据内部政策，合规数据需要满足 6 个月的保留要求，但这些数据被存储在可搜索式平台之外的独立 S3 存储桶中。从白金级升级到企业级后，RTL Germany 基于可搜索式快照和冻结层重新设计架构，使标准数据保留周期延长至 90 天（提升至原来的 3 倍），在相同许可规模下总容量增长至 235 TB，虚拟化基础设施节点数量从 18 个物理节点减少至 10 个，并且整个迁移过程实现零中断、零数据丢失。

30 天的数据保留周期所限制的不只是更长时间跨度的历史数据，更是一类关键问题的分析能力：季度环比比较、年度同比季节性变化分析，以及足够长的基准周期来支撑可信的趋势线。对于 RTL Germany 的 BI 用户而言，数据湖虽然包含运营数据，但其覆盖范围远未达到分析需求开始发挥作用的程度。如今，标准数据保留周期已延长至 90 天，部分索引的数据保留时间更可达 1 年，这类分析问题可以直接在同一个数据湖中完成 — 运营团队正在实时监控的同一数据湖、相同的数据源，而无需将数据导出到其他位置。

该结果建立在该平台生命周期内两次关键转型的基础之上：第一次是在 2023 年，由于企业合并引入了第二套日志平台，RTL Germany 将系统整合至 Elastic 平台；第二次则是后续的许可证升级，通过重新设计存储架构，使数据保留期限增加至原来的三倍，同时无需扩大许可证覆盖规模。

RTL Germany 的 Elastic 环境最初是在近十年前作为共享基础设施工具开始建设的，并逐步由各个团队扩展，最终发展成为覆盖全公司的数据湖。两个事件塑造了如今这一平台的形态。

第一件事是 2023 年的一次并购后整合。一家新加入的公司实体原本运行着不同的日志平台。RTL Germany 的 Elastic 环境已经部署在本地，并且仍有充足容量，因此同时维护两个平台在财务和运营层面都不具备合理性。此次从旧日志工具迁移的过程历时约 5 个月，其中最具挑战的部分是沟通协调、重建团队多年积累的仪表板和通知工作流，以及重新设计数据摄取管道。

第二件事是存储容量上限，以及突破这一限制的方法。在 Elastic{ON} 慕尼黑活动中了解可搜索式快照和冻结层后，团队发现了一种能够直接解决存储问题的架构方案：保持现有许可规模不变，将长尾数据迁移至由 S3 支持的冻结存储，并利用释放出的热层容量空间延长数据保留周期。在做出最终决策之前，团队进行概念验证，重点验证一个关键问题：在冻结层上查询较旧数据的速度如何？测试结果显示，查询性能足够理想，因此团队很快决定将整个集群架构从热层-冷层模式重新设计为热层-冻结层模式。

在重新设计之前，RTL Germany 的标准数据保留期限受限于 100 TB 的本地存储容量，最多约为 30 天。数据湖整体运行状况良好，但三项运营层面的现实因素同时加剧了存储容量压力。

商业智能需求超出了 30 天。一些部门希望追踪关键绩效指标 (KPI) 随时间的变化趋势，而数据湖中仅保留 30 天的历史数据，无法支持这类分析工作。各团队拥有满足日常运营所需的数据，但缺少开展深入分析所需的时间窗口。

合规数据位于数据湖之外。根据内部政策要求，需要保留 6 个月的防火墙数据存储在独立的 S3 存储桶中，而非可搜索的平台内。虽然这些数据得到了保留，但在实际调查过程中，团队需要先从对象存储中提取数据，再加载到可搜索式系统中，这真实场景下会带来相当大的操作负担。

硬件正在老化。该集群运行在大约五到六年前的服务器上，使用的是标准 SSD，而非 NVMe 固态硬盘。团队意识到，无论架构是否进行调整，硬件更新换代都已势在必行。

团队的时间都投入在维持现有平台在容量上限下的稳定运行状况，而不是用于扩展平台能力、为整个业务创造更多价值。

团队将许可证从白金级升级到企业级，以启用可搜索式快照和冻结层功能，随后重新设计存储布局，从原先的热数据和冷数据模式转变为热数据和冻结数据模式，并以 S3 作为底层存储支持。

端到端的数据流保持了原有模式。Logstash 节点从组织内各个数据源采集数据，并写入 Elastic。热索引存储在新集群本地 NVMe SSD 上。较旧的索引会迁移至冻结层，并存储在 S3 中；当用户发起查询时，相关数据会按需加载至本地缓存。迁移切换期间，跨集群搜索连接新旧集群，使用户无需切换环境即可访问历史数据。

性能方面的权衡被证明是可控的。首次查询冻结层中的索引时，由于相关数据需要加载到冻结节点的缓存中，通常需要约 30 秒。此后，对同一数据的查询即可达到热层的运行速度。

• 当前数据的热层查询速度：在运行于 KVM 上的新型服务器上，使用 35 TB NVMe SSD。
• 以低成本实现数月至数年的保留期：200 TB 由 S3 支持的冻结存储，通过可搜索式快照提供服务。
• 同一许可占用空间，容量提升至三倍：235 TB 综合容量（35 TB 热存储、200 TB 冷存储），许可资源单元未增加。
• 更小、更快速的集群：虚拟机管理程序占用空间从 18 个物理节点减少至 10 个物理节点，采用每个节点具有更多核心的新型硬件。
• 工作负载逐项切换，无需管道架构：Logstash 继续处理摄取；迁移过程中，目的地按数据源重定向。
• 迁移过程中不会丢失对历史数据的访问权限：跨集群搜索始终处于活动状态，因此用户继续读取旧集群上的旧索引，同时新数据流向新集群。
• 首次查询后即可达到热层速度访问旧数据：首次查询时，冻结层缓存加载相关数据大约需要 30 秒；之后对相同数据的查询即可达到热层的运行速度。

团队没有采用一次性大规模切换的方式，而是在旧集群旁搭建了新集群，并按工作负载逐一迁移，优先处理最大的数据源。由于数据摄取流程通过 Logstash 运行，迁移某个工作负载通常只需在 Logstash 节点上将目标地址从旧集群的主节点更改为新集群即可。跨集群搜索让用户能够继续在新环境中访问旧集群中的数据，因此历史数据在整个迁移过程中始终保持可访问状态。

团队还借机将自定义摄取管道尽可能迁移到 Elastic 维护的集成中，他们称这是未来更好的发展路径。

硬件交付出现延迟时，Elastic 支持团队延长了新旧环境的重叠周期，团队特别指出，这是确保整体时间线能够顺利推进的重要因素之一。

概念验证本身耗时约 2 周。在整个 6 到 8 周的 PoC 时间线中，大部分时间用于硬件采购和配置，而非测试工作。完整切换过程历时约 3 个月，最终在没有中断或数据丢失的情况下完成。

对于日常使用数据湖的各个部门而言，此次变更几乎是无感的。用户只需在临时重叠期间将书签指向新的 URL，并在切换完成后恢复使用标准域名即可。整个过程中，跨集群搜索功能确保了历史数据始终可从新集群访问，因此用户无需学习新的操作流程，也不必在两个系统之间切换来查找旧数据。

在合规方面，过去存储在独立 S3 存储桶中的数据如今已纳入可搜索式数据湖中。6 个月的防火墙数据保留要求不再带来流程上的障碍。如果某个部门需要回溯整个保留周期内的数据，只需采用与查询数据湖中其他数据相同的方式进行查询即可。

项目中有一些实用经验教训尤为突出。

尽可能使用托管集成。RTL Germany 过去多年积累了大量自定义数据采集管道，并在迁移过程中将其中许多管道迁移至 Elastic 维护的集成方案。团队认为，这不仅是本次项目的更优路径，也是面向未来长期发展的更佳选择。

将迁移视为一次整容手术。同时更换老旧硬件、现代化改造架构并重新审视集成方案，使该项目产生的价值远超单独完成其中任何一项工作所能带来的收益。

客观评估托管模式。考虑到 RTL Germany 现有资源和商业因素，采用本地部署模式是合理的选择。对于缺乏内部能力搭建和运维集群的小型组织，团队建议选择 Elastic 的 SaaS 方案，以避免承担额外的运营维护负担。

难点在于数据量，而非复杂性。将数据采集流从一个集群切换到另一个集群相对简单。真正耗费精力的是数量庞大的数据管道，以及需要通过这一简单变更处理的数据规模。

两个结果决定了接下来会发生什么。第一个结果是：将 Elastic AI Agent 连接至 RTL Germany 的内部大型语言模型 (LLM)，缩短新团队成员查找正确数据视图所需的时间。这将帮助新成员更快地熟悉平台并找到所需的数据视图，而这一直以来都是入职培训过程中较具挑战的一步。

第二个结果是：在不扩大许可规模的情况下，将更多应用程序日志纳入数据湖。该内部项目旨在将来自各个应用程序的更多日志接入数据湖。新的架构在设计之初就充分考虑了这一增长需求。借助 200 TB 由 S3 支持的存储容量以及可轻松扩展的存储能力，团队能够在无需重新调整许可规模的情况下承载不断增长的数据量。

您的组织如今可能并未运行一个覆盖整个广播和媒体业务、历经十年发展的数据湖，但无论您是从数个 TB 的日志数据起步，还是正在扩展至 235 TB 的热数据与冻结数据架构，同样的原则都适用：许可证覆盖规模无需随着数据保留周期的延长而同步增长。

RTL德国是RTL集团的一部分，RTL集团是德国最大的广播和媒体公司，业务涵盖电视、流媒体和内容制作。

了解 Elastic Observability 的冻结层如何在不增加成本的情况下延长数据保留期，或立即开始免费试用。

• Elastic Observability
• 日志监测
• Elasticsearch
• Logstash
• 数据集成
• 可观测性实验室
• Elastic 文档

主题：Elastic Observability、Elasticsearch、Logstash、冻结层、可搜索式快照、分层存储、跨集群搜索、日志分析、数据湖、合规数据保留、媒体与广播、媒体与娱乐行业