Twitter 运行着世界上最大的 Hadoop 集群之一。最初，Hadoop 被用于 Twitter 上的 MySQL 备份，随着时间的推移，其使用案例大大增加。

如今，它不但用于MySQL 备份，还用于对用户在平台上执行的操作进行分析，包括社交图谱分析、推荐、趋势、API 分析、用户参与度预测、广告定位、广告分析、推文印象处理等。

Hadoop 文件系统存储了超过 500 PB 的数据，运行在数万个实例上。整个集群使用Hadoop Federation 功能进行管理，每天运行数十万个 Hadoop 作业和数千万个 Hadoop 任务。

Twitter每天有超过 15 万个服务和 1.3 亿个容器在运行。

为了扩展服务，Hadoop 使用不同的Namenode独立运行，且彼此之间没有依赖关系。

有一些节点称为数据节点Datanode，用于数据存储。这些数据节点在集群中向 Namenode 注册。

为了管理命名空间，使用了View 文件系统，这对于管理具有多个 Namenode 的集群很有用。

每个集群都有超过3500个Namenode。

Twitter 最初以 MySQL 作为主要数据存储，然后逐渐从单一实例发展到大规模集群。

Twitter 自成立之初就拥有了世界上最大的 MySQL 集群之一。它包含数千个节点的 MySQL 实例，每秒可处理数百万次查询。

MySQL 主要有两种用例：

Twitter 的工程团队还基于 Apache Mesos 构建了一个可扩展的 MySQL 数据库集群管理框架，称为 Mysos。它的主要目的是简化和自动化 MySQL 数据库实例的管理和调度，使得数据库在大规模环境中更加稳定和可靠。

除了 MySQL，其他基于 SQL 的数据存储（如 PostgreSQL 和 Vertica）也用于存储广告活动、销售和内部工具数据。

Blobstore 是 Twitter 的可扩展存储系统，用于存储用户图片、视频和其他大型二进制对象。它使 Twitter 能够降低存储用户上传的推文图片的成本。

它是一个高性能系统，能够每秒处理数十万的请求的同时在几十毫秒内提供图片。

当图片上传到 Blobstore 时，它会通过异步队列服务器将图片同步到 Twitter 的所有数据中心。

通过缓存，Twitter 向客户端每秒传递约 120GB 的数据。

Twitter 的缓存有两个主要用途：

Twitter 内部运行着许多缓存服务，其中之一是Redis。Redis 集群缓存用户消息、广告支出、展示次数和参与度等等。

此外，Twitter 还自研了Twemcache，这是 Memcache 的定制版本，适合大规模生产部署。该平台拥有数百个缓存实例，内存中存储着来自 30 多个服务的超过 20TB 的数据。总体而言，缓存层每天可处理超过 2 万亿次查询。

为了方便缓存的管理，Twitter又自研了一款轻量级缓存代理服务器--Twemproxy，它支持 Memcached 和 Redis 协议。它的主要作用是将客户端的请求分发到多个缓存服务器，从而实现缓存系统的横向扩展。Twemproxy 提供了一个单一的入口，使得客户端无需知道后端有多少缓存服务器，也无需处理服务器之间的数据分布和负载均衡问题。

最初，Manhattan 用作指标存储数据库，但 Twitter 面临可扩展性问题以及不支持附加的分钟指标标签。

这导致了内部开发 Metrics DB，使用了 Facebook 内存时间序列数据库 Gorilla 的压缩算法。

Metrics DB 提供多区域支持、指标分区，压缩效率高于 Twitter 使用的其他数据存储。使用 Gorilla 的压缩算法，Twitter 减少了 95% 的空间使用量。

MetricsDB 有 3 个主要组件：

FlockDB 是一个分布式图形数据存储，专为快速图形遍历、存储邻接表、支持高频添加、删除和更新操作、分页处理数百万条目、横向扩展和运行图形遍历查询而设计。

Twitter 使用它来存储社交图，包含谁关注谁等信息。