LogDevice：Facebook开源的分布式日志数据存储系统

日志是记录有序可变记录序列并且把他们可靠存储下来的最简单方法。日志可以被视为面向记录的数据库，且仅支持附加和修剪的文件。

面向记录意味着数据以不可分割的记录写入日志，而不是单个字节。更重要的是，记录是最小的寻址单位：读取时总是从特定记录（或从附加到日志的下一条记录）开始读取，并一次接收一个或多个记录的数据。更重要的是，记录编号不能保证是连续的。编号序列中可能存在间隙，并且日志写入时事先不知道在成功写入时其记录的日志序号。

日志天然是附加的。不支持或提供修改现有记录的支持。

在删除日志之前，日志应该存在相对较长的时间。7天，几周，几个月甚至几年。日志的主要空间回收机制是根据基于时间或空间的保留策略进行修剪或删除最老的记录。

日志在现代以数据为导向的企业中至关重要，企业BI、大数据系统其最原始数据来源都是其业务日志。甚至很多在线决策服务也都依赖于企业日志数据。处理日志数据的管理和处理一般都面临着同样的窘迫需求：

怎么保证从日志从收集（INPUT）到消费（OUTPUT）全数据栈流程不会因为流量超控而被限制，保证不会数据丢失。

让一个阶段写入日志，另一个阶段从中读取。

如何维护日志数据的索引？如何让索引服务按正确的顺序读取更新日志并在所有应用中更改，并且能满足其后有一系列需要按特定顺序执行的工作项？先将它们写入日志，并会在后面一定时间内才会消费。

具有足够容量来订购所有写入的日志使它们成为可能。

数据耐用性问题？

怎么使用预写日志。

和大多数企业一样，社交巨头Facebook公司也遭遇着同样的问题，在脸书超大规模的日志数据面前，所有这些说起来容易做起来难。而其中需要满足的两个难以大规模实现的重要保证：高可用性和持久性记录存储，以及这些记录的可重复总顺序。 为了满足这两个个保证和上面提到的种种难题，脸书开发了分布式日志系统LogDevice。目前该系统已经在github开源(github: /facebookincubator/LogDevice)，本文虫虫就给大家介绍脸书的分布式日志存储系统LogDevice，一个专为日志设计的分布式数据存储。

LogDevice是一个可扩展且容错的分布式日志系统。 当文件系统存储和提供组织为文件的数据时，日志系统存储和传输组织为日志的数据。

LogDevice从头开始设计，可以提供大规模的高可靠性和高效率的多种日志。还支持高度可调性，允许对每个用例进行优化，以便在耐久性效率和一致性可用性空间中进行正确的权衡取舍。

工作量和性能要求

脸书拥有各种日志记录工作负载，其性能，可用性和延迟要求各不相同。LogDevice设计为可动态调整所有这些冲突参数的目标，而不是一个通用的解决方案。

大多数日志记录应用程序的共同点是要求高写入可用性。即使是几分钟，记录器也没有任何地方可以存放数据。 LogDevice必须提供高可用写入。

耐久性要求也是普遍的。与任何文件系统一样，没有人希望听到他们的数据在收到成功追加日志的确认后便丢失。LogDevice的客户端每个日志启动至少一个读取器，用于记录几小时甚至几天的记录。那些读者随后从那一点开始阅读每个日志中的所有内容。

能够应对单个日志的写入负载中的峰值也很重要。LogDevice将记录顺序与记录存储分开，并使用记录的非确定性放置来提高写入可用性，并更好地容忍由此类峰值引起的临时负载不平衡。

一致性保证

LogDevice日志提供的一致性保证是人们对文件的期望，尽管是一个面向记录的文件。多个写入器可以同时将记录追加到同一个日志中。所有这些记录将以相同的顺序传递给日志的所有读取者，即其LSN的顺序，具有可重复的读取一致性。如果将记录传送给一个读取者，它也将被传送给遇到该LSN的所有读者，除非导致丢失所有记录副本的灾难性故障。LogDevice提供内置的数据丢失检测和报告功能。如果发生数据丢失，所有丢失记录的LSN将报告给尝试读取受影响的日志和LSN范围的每个读取者。没有为不同日志的记录提供订购保证。来自不同日志的记录的LSN不具有可比性。

设计和实施

不确定的记录放置

为记录副本提供大量放置选项可提高分布式存储群集中的写入可用性。与许多其他分布式存储系统类似，LogDevice通过在不同的机器上存储每个记录（通常为两个或三个）的几个相同副本来实现持久性。对于这些副本有许多放置选项，即使群集中的许多存储节点停机或运行缓慢，也可以完成写入，只要启动的群集部分仍可以处理负载。

许多成功的分布式文件系统都采用了最大化传入数据的放置选项的原则。例如，在Apache HDFS中，数据块可以放置在集群中的任何存储节点上，受限于称为名称节点的集中式元数据存储库强制执行的跨机架和空间约束。在Red Hat Ceph中，数据放置由多值散列函数控制。散列函数生成的值为传入数据项提供多个放置选项。这消除了对名称节点的需要，但无法达到相同级别的放置灵活性。

LogDevice专注于日志存储，采用了不同的方法来记录位置。它提供了与名称节点相同的放置灵活性级别，而实际上并不需要名称节点。

LogDevice日志记录的顺序与记录副本的实际存储分开。对于LogDevice集群中的每个日志，LogDevice运行一个sequencer对象，其唯一的工作是在记录附加到该日志时发出单调递增的序列号。定序器可以在任何方便的地方运行：在存储节点上，或在为排序保留的节点上，以及追加不存储的执行。

节点集允许LogDevice集群独立于读取器数量进行扩展。客户端联系的节点通过尽可能快地将它们推送到TCP连接来向其传送记录副本。当然，每个记录的标题包括其序列号。

LogDevice客户端库执行必要的记录的重新排序和偶尔重复数据删除，以确保记录按其LSN的顺序传送到读取器应用程序。

序号

如上图所示，LogDevice中记录的序列号不是整数，而是整数对。该对的第一个组件称为epoch数，第二个组件在epoch内偏移。通常的元组比较规则适用。在LSN中使用时期是另一种可用性优化。当sequencer节点崩溃或以其他方式变为不可用时，LogDevice必须为所有受影响的日志调出替换sequencer对象。每个新的序列发生器开始发出的LSN必须严格大于已为该日志写入的所有记录的LSN。

epoch存储充当持久计数器的存储库，每个日志一个，很少增加并且保证永不退化。目前是使用Apache Zookeeper作为LogDevice的epoch存储。

多对多的重建

驱动器失败。电源故障。机架开关失灵。当这些故障发生时，某些或所有记录的可用副本数量会减少。在数次连续失败后，该数字降至零，就会丢失数据或至少丢失一些记录的读取可用性。这是LogDevice设计尽可能避免的情形。在一次或多次失败后，重建会为已复制不足（具有少于目标份数R的记录）的记录创建更多副本。

为了有效，重建必须快速。它必须在下一次失败之前完成一些失败记录的最后一个副本。与HDFS类似，LogDevice实现的重建是多对多的。所有存储节点都充当记录副本的发送者和接收者。整个集群的资源都会用于重建，允许LogDevice以每秒5-10GB的速率完全恢复受故障影响的所有记录的复制因子。重建协调是完全分布式的，并通过事件日志的内部元数据执行。

本地日志存储LogsDB

排序和存储的分离有助于分配集群的聚合CPU和存储资源，以匹配不断变化的，有时尖锐的工作负载。但是，分布式数据存储的每节点效率很大程度上取决于其本地存储层。最后，必须将多个记录副本保存在非易失性设备上，例如硬盘驱动器或SSD。当以每个节点100MBps +存储数小时的记录时，仅RAM存储是不切实际的。当积压持续时间以天为单位（在Facebook上不是一个不常见的要求）时，硬盘驱动器比闪存更具成本效益。所以设计LogDevice的本地存储组件，不仅在具有巨大IOPS容量的闪存上，而且在硬盘上也能很好地运行。企业级硬盘驱动器可以推动相当数量的顺序写入和读取（100-200MBps），但最高可达100-140随机IOPS。

LogDevice LogsDB的本地日志存储，是一个写优化数据存储，旨在保持磁盘搜索的数量小和受控，并且存储设备上的写和读IO模式大多是顺序的。LogsDB是RocksDB之上的一个层，是一个基于LSM树的有序持久键值数据存储。 LogsDB是RocksDB列族的按时间排序的集合，是完全成熟的RocksDB实例，共享一个共同的预写日志。每个RocksDB实例称为LogsDB分区。所有日志的所有新写入，无论是一个日志还是一百万，都会进入最新的分区，按照（log id，LSN）对它们进行排序，并在一系列大型已排序的不可变文件（称为SST文件）中保存在磁盘上。

用例和展望

LogDevice目前是脸书各种日志记录工作负载的通用解决方案。比如Scribe用的就是LogDevice，总吞吐量超过每秒摄取数TB的峰值，可靠地传输并且可以重放；TAO数据的二级索引也用的LogDevice，其吞吐量虽没有Scribe大，但每个日志的严格记录排序很重要，预期的端到端延迟大约为10毫秒；还有机器学习管道，它使用LogDevice将相同的事件流提供给多个ML模型训练服务。

LogDevice更多功能正在积极开发中。它用C++编写的，几乎没有外部依赖。目前正在探索的新领域包括集群分解，其中存储和CPU密集型任务由具有不同硬件配置文件的服务器处理，支持非常高容量的日志，以及通过应用程序提供的密钥对记录进行高效的服务器端过滤。这些功能将共同提高LogDevice集群的硬件效率，并为高吞吐量数据流的用户提供可扩展的负载分配机制。

目前脸书已经将LogDevice基于BSD协议开源，你可以通过github cone这个项目，并获取其完整的文档，该项目还提供了Docker容器镜像，你可以使用Docker快速安装并试用。