发布于: Mar 22, 2022
在 Verizon Media Group（VMG），我们面临的一大主要问题，就是无法在理想的时间之内完成计算容量扩展——硬件采购通常需要几个月才能落实到位。这就意味着，我们无法让硬件的扩展与升级与工作负载变化匹配起来，这不仅造成了巨大的资金浪费，同时也给冗余管理软件的升级流程带来大量停机时间，进而极大提升运营风险。
在 VMG，我们使用 Apache Hadoop 以及 Apache Spark 等技术方案运行我们自己的数据处理管道。我们之前曾经使用过 Cloudera Manager 进行集群管理，但其发布周期过慢，跟不上技术发展与业务需求的变化。结果就是，我们只能使用较为陈旧的开源版本，导致无法充分使用 Apache 项目上的最新 bug 修复与性能改进成果。出于以上原因，再加上我们对 Amazon Web Services 的现有投资，最终促使 VMG 决定尝试将分布式计算管道迁移至 Amazon EMR 当中。
Amazon EMR 是一套托管集群平台，能够简化各类大数据框架（例如 Apache Hadoop 与 Apache Spark）的运行流程。
本文主要讨论我们在构建数据处理管道时，经常遇到的问题以及相关解决办法。
Verizon Media 在本质上属于一家在线广告企业。目前，大多数在线广告主要通过展示广告（亦称「横幅广告」或「视频广告」）形式实现。无论具体采取哪种方式，所有互联网广告都需要发送各种信标以实现服务器跟踪。这些服务器主要为具备高度可扩展性的 Web 服务器部署，负责将接收到的信标记录至一个或者多个事件接收器当中。
在我们负责处理视频广告的专项小组中，我们主要使用部署在多个地理位置的 NGINX Web 服务器将由视频播放器触发的事件直接记录至 Apache Kafka 以供实时处理，而后将结果记录至 Amazon S3 接受后续批处理。我们使用的典型数据管道一般需要完成输入内容摘要、应用验证以及充实例程、结果数据汇总，并将其复制至其他目的地以供报表等具体操作任务。下图所示，为我们典型管道的基本架构。
我们首先在 NGINX 信标服务器上获取数据。数据以 1 分钟的间隔以 gzip 文件格式被存储在本地磁盘之上。每分钟，我们都会将数据从 NGINX 服务器进一步转移至 S3 中的原始数据位置。在登录 S3 时，文件将消息发送至Amazon SQS。Apache NiFi 开始监听 SQS 消息并启动文件处理。在这段时间内，NiFi 将把较小的文件组织成数个较大文件，并将结果存储在 S3 某特殊路径的临时位置当中。路径名称使用反向时间戳进行组合，以确保我们的数据始终使用随机存储位置，避免引发读取操作瓶颈。
每小时，我们都会在 Amazon EMR 上对一套 Spark 集群进行向外扩展，借此处理原始数据。整个处理过程包括数据的验证与充实。这些数据以 Apache ORC 列格式存储在 S3 上的永久位置文件夹当中。我们还更新了 Amazon Glue 数据目录，用于在 Amazon Athena 中公开此数据，以供出现问题时进行调查取证。原始数据处理完成后，我们将削减 Spark EMR 集群的规模，并使用 Amazon EMR 上基于预定义的 Presto 聚合模板对数据进行聚合。聚合数据以 ORC 格式存储在 S3 之上用于保存聚合数据的特定位置。
我们还使用数据位置更新数据目录，以保证可以通过 Athena 随时执行查询。此外，我们将数据从 S3 处复制至 Vertica 中以进行报表生成，进而将数据公开给各内部与外部客户。在这种情况下，Athena 将作为 Vertica 的灾难恢复（DR）解决方案。每当报表平台发现 Vertica 运行状态不佳时，我们都会将负载自动故障转移至 Amazon Athena。事实证明，这套解决方案为我们带来了出色的成本效益。在实时分析当中，我们还拥有另一个 Athena 用例，但与本文主题无关，因此不具体讨论。