Twitter 如何将 Kafka 当做一个存储系统.docxVIP

Twitter 如何将 Kafka 当做一个存储系统 原创过往记忆大数据 过往记忆大数据 2021-12-31 收录于话题 #Kafka 4 个内容 #分布式技术 52 个内容 #过往记忆 59 个内容 #大数据 51 个内容 前言 当开发人员通过我们供应的 API 使用公开的 Twitter 数据时，他们需要牢靠性、高效的功能以及稳定性。因而，在前一段时间，我们为 Account Activity API 启动了 Account Activity Replay API ，让开发人员将稳定性融入到他们的系统中。Account Activity Replay API 是一个数据恢复工具，它允许开发人员检索5天前的大事。并且供应了恢复由于各种缘由而没有交付的大事，包括在实时交付期间服务器的宕机。 除了构建 API 来供应良好的开发者体验，我们还做了以下的优化： ?提高我们工程师的生产力。 ?使系统易于维护。具体地说，我们尽量削减开发者、站点牢靠性工程师和任何与系统交互的人的交互。 由于这些缘由，在构建此 API 所依靠的回放（replay）系统时，我们利用了 Account Activity API 的实时系统的现有设计。这挂念我们重用已经存在的工作，并且最小化上下文切换和培训。 实时系统是利用了发布-订阅架构（publish-subscribe architecture）。因而，为了保持这一架构，在构建存储层的时候，我们需要重新思考传统的流技术——Apache Kafka。 背景 实时大事在两个数据中心 （DCs）中产生，产生这些大事后，它们被写入 pub-sub 主题中，为了实现冗余目的，大事会写到两个数据中心。 并非全部大事都应当交付，因而内部应用程序将对这些主题中的大事进行筛选，依据键值存储中的一组规章检查每个大事，并打算能否应当通过我们的公共 API 将大事交付给给定的开发人员。大事是通过 webhook 方式交付，开发人员拥有的每个 webhook URL 都由一个独一的 ID 标识。 存储和分区 当构建一个需要存储功能的重放系统时，通常我们会使用基于 Hadoop 和 HDFS 的架构。而我们这里选择了 Apache Kafka，次要基于以下两个缘由： ?我们现有的实时系统接受的是发布-订阅架构； ?重放系统存储的大事量不是 PB 级的，我们存储的数据不超过几天。此外，MapReduce 任务读取数据的效率也没有 Kafka 高，也更慢，这不能满足开发人员的期望。 我们利用实时管道（real-time pipeline）来构建回放管道（replay pipeline），首先要确保应当交付给每个开发者的大事都存储在 Kafka 上。我们把对应的 Kafka 主题称为 delivery_log，每个数据中心都有一个。然后，这些主题在两个数据中心交叉复制，以确保冗余，从而使得任一个数据中心都可以处理重放恳求。 在这个 Kafka 主题中，我们使用默认的分区策略（也就是哈希分区）创建了多个分区。开发人员的 webhookId 哈希值对应分区 ID，它是每个记录的键。我们考虑过使用静态分区，但最终打算不使用它，由于假如一个开发人员生成的大事多于其他开发人员，那么一个分区的数据多于其他分区的风险就会添加。相反，我们选择固定数量的分区，使用默认分区策略来分散数据。有了这个，我们减轻了分区不平衡的风险，并且不需要读取 Kafka 主题上全部分区。相反，依据恳求进入的 webhookId，重放服务确定要读取的特定分区，并为该分区启动一个新的 Kafka 消费者。主题上的分区数量不会转变，由于这会影响键的散列以及大事的分布方式。 依据每个时间段读取的大事数量，我们选择使用固态磁盘（SSD）。我们选择它而不是传统的机械硬盘（HDD），以获得更快的处理速度，并削减寻道和访问时间带来的开销。最好使用 ssd 以获得更快的读取速度，由于我们访问的数据很少反复使用，因而无法从页面缓存优化中获得好处。 为了削减存储空间，我们使用 snappy 作为压缩算法对这些数据进行压缩。由于我们晓得大部分的事情都是在消费端进行的。我们选择 snappy 是由于它的解压速度比其他 kafka 支持的压缩算法 gzip 和 lz4 快。 恳求与处理 在我们设计的系统中，一个 API 调用发送重放恳求。通过恳求的参数里面，我们可以获得 webhookId 和应当重放大事的日期范围。这些恳求被长久化到 MySQL 中并进入队列，直到重放服务处理它们为止。恳求上的日期范围用于确定要开头读取的分区上的偏移量，消费者上的 offsetForTimes 函数用于猎取偏移量。 重放服务实例处理每个重放恳求，重放服务实例使用 MySQL 相互协调，以处理数据库中