作者:来自 Elastic Ugo Sangiorgi, Matt Wehle
了解 Elastic 和 Splunk 数据管理方法之间的主要区别,以便做出明智的决策,实现高效的数据处理
在数据管理领域,在讨论如何根据不同的性能要求提供和/或保留数据时,经常会提到 “热 - hot”、“温 - warm” 和 “冷 - cold” 等术语。
Elastic® 和 Splunk 的产品都有独特的、有时甚至相互冲突的术语,我们的目标是解开这些差异,并呈现更清晰的图景,以便采用战略性、经济高效的方法满足你的数据管理需求。
什么是数据层?
从根本上讲,数据层是不同的存储级别,根据访问频率、成本效率和性能需求等标准对数据进行分类。它们允许优化数据组织,并可以通过将存储费用与信息的价值随着时间的推移保持一致来帮助降低成本。
数据层的概念存在于大多数数据平台中,尤其是那些处理可观察性和/或安全工具的数据平台。这些工具收集的数据量通常非常大,每秒处理数千甚至数百万个事件,并可用于搜索、仪表板和警报。可观察性和安全性也有一个共同的特点:最新的数据也是最有价值的,因为管理这些工具的团队依靠收集的信号在出现问题时立即采取行动。
因此,使用最快的硬件来提取和存储数据,并随着时间的推移将数据 “向下” 移动到更便宜、功能更弱的硬件上是有意义的。它也可以在需要时 “向上” 移动。
我们可以将 Elastic 和 Splunk 中的数据层分为 “数据蛋糕 - data cake” 中的三层:
- Layer A - A 层:数据通常首先写入此处,索引和搜索性能最佳。
- Layer B - B 层:数据从其他层移至此处,可搜索,但性能不如上层。数据备份到对象存储,归档或恢复无需用户操作 — 平台会自动完成。
- Layer C - C 层:移至此层的数据不会产生计算成本,因为不会主动索引。为了使用(搜索)数据,必须根据用户的明确操作将其恢复到更高层 — 在此之前,数据几乎是 “不可见的”。
由于 A 层是三者中最昂贵的,因此仅在需要时才将数据保留在其中是有意义的。例如,将数据在 A 层保留一周,然后将其移动到 B 层,在那里保留六个月,然后移动到 C 层,在那里存储三年,以达到合规性目的。
我们认为,可观察性和安全性解决方案必须让用户能够尽可能地选择如何在各层之间上下移动数据,因为在考虑预算和业务需求等多种因素时,如何平衡性能和成本最终取决于用户。
了解 Splunk 和 Elastic 中的数据层有助于制定适当的数据迁移策略。这包括确定应迁移哪些数据、应如何转换或重构数据以及如何确保迁移过程中的数据完整性和一致性。了解源数据层和目标数据层使你能够有效地将数据从一个系统映射到另一个系统。
Elastic 和 Splunk 中的数据层
现在我们有了一个用于比较数据层的单一框架,让我们比较一下 Elastic 和 Splunk 的本地解决方案 Elasticsearch® / Splunk Enterprise,以及它们的云解决方案 Elastic Cloud / Splunk Cloud。
但首先,先谈一下性能比较。 在这篇博客中,我们严格讨论数据管理,通过对比不同存储层,而不是从性能角度进行比较。 如果要推测性能差异,可以根据存储层级的高低来判断,但这仅适用于同一产品(例如,在 Elastic Cloud 中,Hot 层比 Cold 层更快,因为它使用了更强大的硬件,并且具有更好的可扩展性,可以将数据复制到多个节点上)。
比较:Elasticsearch 和 Splunk Enterprise
虽然 Elastic 和 Splunk 都有热、温、冷和冻结层,但它们在两种解决方案中的含义完全不同。让我们总结一下。
Elastic 有五层结构:
- 热(hot):这是新摄取数据的主要目的地,提供最佳性能和实时可用性。
- 温(warm):这里存放的是稍微不那么紧迫的数据,位于更经济实惠的硬件上,同时保持可扩展性和可用性。
- 冷(cold):这里,集群中只维护一个可搜索的数据副本,如果拓扑发生变化,可以自动从对象存储中恢复。
- 冻结(frozen):此层存放访问频率较低的数据,从而节省计算资源,并引入搜索的自动数据恢复。它提供了一种使用远程对象存储来存储数据的方法,例如 Amazon S3、Google GCS 或 Microsoft Azure Blob 存储。
- 快照(snapshot):作为数据备份,这些快照是可以手动恢复的副本,用于恢复或迁移目的。
Splunk Enterprise 具有四层结构:
- 热+温(hot + warm):这是新摄取数据的主要目的地,提供实时可用性和搜索性能。Splunk Enterprise 中的热和温之间的区别仅在于读写和只读 — 温数据仅可读(例如,用于搜索),因为索引器不会向其中写入新数据。
- 冷(cold):冷阶段允许管理员将不太可能被搜索的数据移动到更便宜(即更慢)的存储设备。
- SmartStore:此层存储访问频率较低的数据,从而节省计算资源,并引入搜索的自动数据恢复。它提供了一种使用远程对象存储来存储数据的方法,例如 Amazon S3、Google GCS 或 Microsoft Azure Blob 存储。这是在 Splunk 中构建数据层的一种完全不同的方式,因为大多数数据驻留在远程存储上,而索引器只维护本地缓存。
- 冻结(frozen):这些快照充当数据备份,是可手动恢复的副本,用于恢复或迁移目的。这里,Splunk 所称的冻结类似于 Elastic 的快照。
使用 Splunk Enterprise,热层和温层之间的区别不那么明显,其冷层在硬件利用率方面可与 Elastic 的温层相媲美。Elastic 仍然以可扩展的热层领先,促进了向温层的过渡,而不会放弃可用性。
Elastic 的冷存储和冻结存储策略确保数据可立即查询,这要归功于对象存储备份,这些备份可自动执行检索过程,类似于 Splunk 的 SmartStore。但是,Splunk 的冻结类别需要手动恢复,类似于 Elastic 的快照。
在 Elastic 中,冷存储和冻结存储都依赖于可搜索快照功能,该功能允许搜索早至 5.0(早在 2016 年就已发布!)的快照,而无需将其恢复到活动集群 — 这对于治理和合规性、安全调查和历史回顾非常有用,无论你使用的是哪个 Elasticsearch 版本。
Elastic Cloud 和 Splunk Cloud
在 Elastic Cloud 中,数据从热层开始其旅程,该层以其可扩展性、高可用性和复杂操作(如索引和搜索)的峰值性能而闻名。相比之下,Splunk Cloud 在热层和温层方面不提供与 Elastic Cloud 相对的分层选项;相反,它有 DDAS,这似乎优先考虑节省成本,可能会以牺牲速度为代价。
Elastic 在 Elasticsearch 和 Elastic Cloud 中具有相同的五个层,但 Splunk Cloud 具有三层结构:
- DDAS:此层优先考虑节省成本而不是性能,因为它利用了 SmartStore。Splunk 表示,“Splunk Cloud Platform 利用多层存储架构并管理数据移动以根据用户搜索模式优化性能。通常,最近处理的数据(最近提取、搜索、分析机器学习等)的性能将优于一段时间未处理的数据。”
- DDAA:数据可以配置为存档在 DDAA 中,Splunk 将管理存储,用户必须主动请求恢复。恢复的 DDAA 数据通常在恢复请求后 24 小时内即可搜索,并且最多可搜索 30 天。大量 DDAA 数据恢复可能需要超过 24 小时才能完成。
- DDSS:此层中的数据专门存储在对象存储中,需要手动恢复(或 “重新恢复数据”)才能搜索。用户将在与其 Splunk Cloud Platform 相同的区域中的 Amazon S3 或 Google Cloud Storage 中管理存储。
Elastic Cloud 的层级与 Splunk Cloud 有着根本的不同。主要区别在于两者在部署灵活性方面采取了截然不同的方法 —— Elastic 提供了 AWS、Google Cloud 和 Azure 的详细实例类型列表,你可以随时选择,甚至可以随时更改数据层的实例类型而无需停机。在 Splunk 中,你有两个选项:AWS 或 Google Cloud,每个选项都有不同的功能集,并且无法查看硬件。
此外,Elastic 本地可用的所有内容在 Elastic Cloud 上也可用,因为它们是完全相同的产品,而 Splunk 对你可能在 Cloud 上使用的功能施加了限制。根据你的订阅级别,实时搜索默认情况下也不会启用,可能需要支持票才能启用。
总结:Elastic 和 Splunk 数据层
命名惯例可能会产生误导,在尝试将业务需求与提供商之间的数据存储选项相匹配时,会造成可以理解的混乱。了解这些层的实际功能可以帮助你做出更明智、更具成本效益的数据管理决策。
此细分旨在消除 Elastic 和 Splunk 之间数据层命名重叠所带来的误解。通过此数据层描述,你将能够更好地战略性地组织数据,以获得性能和成本效益。超越名称并了解每个层的基本机制至关重要,以确保你的数据策略既强大又高效。
本文中描述的任何特性或功能的发布和时间均由 Elastic 自行决定。任何当前不可用的特性或功能可能无法按时交付或根本无法交付。
Splunk 和其他相关标志是 Splunk Inc. 在美国和其他国家/地区的商标或注册商标。所有其他品牌名称、产品名称或商标均属于其各自的所有者。
原文:What’s the difference? Elastic and Splunk data tiers | Elastic Blog