重塑 Sprout Social 的大数据方法

Sprout Social 的核心是一家数据驱动型公司。 Sprout 每天处理来自多个社交网络的数十亿条消息。 正因为如此，Sprout 工程师面临着一个独特的挑战——如何存储和更新大量进入我们平台的同一消息的多个版本（即转发、评论等）。

由于我们存储了消息的多个版本，因此 Sprout 工程师每天要多次“重建世界”——这是一个必不可少的过程，需要遍历整个数据集，将社交消息的每个部分整合为一个“真实来源”。

例如，跟踪单个 Twitter 帖子的点赞、评论和转推。 过去，我们依靠自我管理的 Hadoop 集群来维护和处理如此大量的数据。 每个 Hadoop 集群将负责 Sprout 平台的不同部分——Sprout 工程团队依赖这种做法来大规模管理大数据项目。

Sprout 大数据方法的关键

我们的 Hadoop 生态系统依赖于 Apache Hbase，这是一个可扩展的分布式 NoSQL 数据库。 让 Hbase 对我们处理大数据的方法至关重要的是它不仅能够对整个数据集进行快速范围扫描，而且还能够进行快速、随机、单条记录查找。

Hbase 还允许我们批量加载数据和更新随机数据，这样我们就可以更轻松地处理乱序到达或部分更新的消息，以及社交媒体数据带来的其他挑战。 然而，自我管理的 Hadoop 集群给我们的基础设施工程师带来了高昂的运营成本，包括手动管理灾难恢复、集群扩展和节点管理。

为了帮助减少管理这些具有数百 TB 数据的系统所花费的时间，Sprout 的基础设施和开发团队齐心协力寻找比运行自我管理的 Hadoop 集群更好的解决方案。 我们的目标是：

• 让 Sprout 工程师更好地构建、管理和运营大型数据集
• 最大限度地减少工程师手动拥有和维护系统的时间投入
• 减少由于集群扩展而导致的过度配置的不必要成本
• 提供更好的容灾方式和可靠性

当我们评估当前大数据系统的替代方案时，我们努力寻找一种可以轻松与我们当前的处理和模式集成的解决方案，并且可以减轻手动管理集群带来的操作麻烦。

评估新的数据模式备选方案

我们的团队考虑的解决方案之一是数据仓库。 数据仓库充当数据分析和聚合的集中存储，但与 Hbase 相比，它更类似于传统的关系数据库。 他们的数据是结构化的、经过过滤的并且具有严格的数据模型（即单个对象的单个行）。

对于我们存储和处理具有多个并排存在的消息版本的社交消息的用例，数据仓库有一个低效的模型来满足我们的需求。 我们无法将现有模型有效地适应数据仓库，而且性能比我们预期的要慢得多。 重新格式化我们的数据以适应数据仓库模型将需要大量开销来按照我们的时间表进行返工。

我们研究的另一个解决方案是数据湖屋。 数据湖屋扩展了数据仓库的概念，以允许结构化程度较低的数据、更便宜的存储和围绕敏感数据的额外安全层。 虽然数据湖屋提供的功能比数据仓库多，但它们的效率不如我们当前的 Hbase 解决方案。 通过测试我们的合并记录和我们的插入和删除处理模式，我们无法为我们的批处理作业生成可接受的写入延迟。

使用 AWS EMR 减少开销和维护

鉴于我们对数据仓库和 lakehouse 解决方案的了解，我们开始研究运行托管 Hbase 的替代工具。 虽然我们认为目前对 Hbase 的使用对我们在 Sprout 所做的工作有效，但我们问自己：“我们如何才能更好地运行 Hbase 以降低我们的运营负担，同时仍然保持我们的主要使用模式？”

这是我们开始评估 Amazon 的 Hbase Elastic Map Reduce (EMR) 托管服务的时候。 评估 EMR 需要以与我们测试数据仓库和湖屋相同的方式评估其性能，例如测试数据摄取以查看它是否能够满足我们的性能要求。 我们还必须测试数据存储、高可用性和灾难恢复，以确保 EMR 从基础设施/管理的角度满足我们的需求。

EMR 的功能改进了我们当前的自我管理解决方案，使我们能够像使用 Hbase 一样重用当前模式来读取、写入和运行作业。 EMR 的最大优势之一是使用 EMR 文件系统 (EMRFS)，它将数据存储在 S3 中而不是节点本身。

我们发现的一个挑战是 EMR 的高可用性选项有限，这限制了我们只能在单个可用区中运行多个主节点，或者在多个可用区中运行一个主节点。 这种风险通过利用 EMRFS 得到缓解，因为它为灾难恢复提供了额外的容错能力，并将数据存储与计算功能分离。 通过使用 EMR 作为我们的 Hbase 解决方案，我们能够提高我们的可扩展性和故障恢复能力，并最大限度地减少维护集群所需的手动干预。 最终，我们认为 EMR 最适合我们的需求。

迁移过程很容易预先测试并执行，以将数十亿条记录迁移到新的 EMR 集群，而无需任何客户停机。 新集群的性能得到提升，成本降低了近 40%。 要详细了解迁移到 EMR 如何帮助降低基础设施成本并提高我们的性能，请查看 Sprout Social 使用 AWS 的案例研究。

我们学到了什么

该项目的规模和范围为我们基础设施数据库可靠性工程团队提供了与多个工程团队跨职能合作的机会。 虽然它具有挑战性，但它被证明是我们作为协作工程组织在 Sprout 可以处理的大型项目的一个令人难以置信的例子。 通过这个项目，我们的基础设施团队对 Sprout 数据的使用、存储和处理方式有了更深入的了解，我们也更有能力帮助解决未来的问题。 我们已经创建了一个跨多个团队的公共知识库，可以帮助我们构建下一代客户功能。

如果您对我们正在构建的产品感兴趣，请立即加入我们的团队并申请我们的一个开放式工程职位。