日志是什么？如何在数据集成、实时处理和系统构建中使用日志？

 JayKreps是Linkedin的首席工程师。他说，日志几乎存在于计算机生成时，除了分布式计算或抽象分布式计算模型外，还有广泛的用途。他讲述了日志的原理，以及数据集成、实时数据处理和分布式系统设计，通过使用日志作为单独的服务。文章内容很干，值得学习。以下是原文：我在六年前的一个激动人心的时刻加入了Linkedin公司。从那时起，我们就解决了单一集中数据库的限制，并开始了特殊分布式系统套件的转换。这是一件令人兴奋的事情：我们构建和部署分布式图形数据库、分布式搜索后端、Hadoop安装、第一代和第二代键值数据存储，直到今天仍在运行。我们从这一切中意识到的最有益的事情是，我们构建的许多东西的核心都包含了一个简单的概念：日志。有时也被称为提前写入日志或提交日志或事务日志，它几乎存在于计算机生成时，也是许多分布式数据系统和实时应用结构的核心。不懂日志，就不能完全懂数据库，NoSQL存储，键存储，复制，paxos,Hadoop,版本控制和几乎所有的软件系统；然而，大多数软件工程师对它们并不熟悉。我愿意改变这种情况。在这篇博客文章中，我将带你浏览你必须知道的所有日志，包括什么是日志，如何在数据集成、实时处理和系统构建中使用日志。第一部分:什么是日志？日志是一种简单的抽象存储，不能再简单了。它是一系列只能添加的记录，完全按时间排序。日志看起来如下：我们可以在日志的末尾添加记录，并从左到右阅读日志记录。每个记录都指定了具有一定顺序的唯一日志记录编号。日志记录的排名是由“时间”决定的，因为左边的日志记录比右边的日志记录早。日志记录编号可以看作是这个日志记录的“时间戳”。一开始，按时间排序有点多余。然而，与任何特定的物理时钟相比，时间属性是一个非常容易使用的属性。当我们运行多个分布式系统时，这个属性非常重要。日志记录的内容和格式对本次讨论的目标并不重要。另外，在存储空间完全耗尽的情况下，我们不能再给日志添加记录了。我们稍后会提到这个问题。日志与文件或数据表并不完全不同。文件由一系列字节组成，表由一系列记录组成，而日志实际上只是按时间顺序存储记录的数据表或文件。在这个时候，你可能会想，为什么要讨论这么简单的事情？一个只能在不同环境中添加一定顺序的日志记录是如何与数据系统相关联的？答案是日志有其特定的应用目标：它记录了什么时候发生了什么。在分布式数据系统的许多方面，这才是问题的真正核心。然而，在我们进行更深入的讨论之前，让我澄清一些令人困惑的概念。每个编程人员都熟悉另一个日志记录——使用syslog或log4j可能写入本地文件的非结构错误信息或跟踪信息。为了区分，我们称这种情况的日志记录为“应用日志记录”。应用日志记录是我在这里所说的日志的低级变种。最大的区别是，文本日志主要是为了方便人们阅读，而我所说的“日志”或“数据日志”的建立是为了方便程序访问。(事实上，如果你深入思考，人们在机器上阅读日志的想法有些不符合时代潮流。当涉及到许多服务和服务器时，这种方法很快就成为一种难以管理的方式，为了了解多台机器的行为，日志的目标很快就成为查询和图形这些行为的输入——对于多台机器的某些行为，文件中的英文文本几乎不适合这里描述的结构化日志。）我不知道日志的概念起源于哪里——也许它就像一个二进制搜索：发明者认为它太简单了，不能作为一项发明。它早在IBM系统R出现时就出现了。数据库中的用法是在崩溃时同步各种数据结构和索引。为了保证操作的原子性和持久性，数据库在更改数据库维护的所有数据结构之前，将即将修改的信息转录到日志中。日志记录了发生了什么，每个表或索引都是一些数据结构或索引的历史映射。由于日志是即时永久性的，它可以被用作可靠的数据源，以恢复所有其他永久性结构。随着时间的推移，日志的使用从ACID细节发展到数据库之间复制数据的一种方法。使用日志的结果是，发生在数据库上的变更顺序需要与远端复制数据库上的变更顺序完全同步。Oracle,MySQL和PostgreSQL都包括日志传输协议，用于复制备用数据库传输日志。Oracle还将日志产品转化为一种通用的数据订阅机制，使非Oracle数据订阅用户可以使用XStreams和GoldenGate订阅数据，MySQL和PostgreSQL上的类似实现成为许多数据结构的关键组成部分。正是因为这个起源，机器识别日志的概念大多局限于数据库。日志作为数据订阅的机制似乎是偶然的，但将这种抽象用于支持所有类型的信息传输、数据流和实时数据处理是不现实的。分布式系统日志解决了两个问题：改变动作排名和数据分发，这在分布式数据系统中尤为重要。分布式系统设计的核心问题之一是协商一致的改变动作顺序(或保持每个子系统本身的做法，但可以复制副作用的数据)。以日志为中心的分布式系统受到简单经验知识的启发。我称这种经验知识为状态机复制原理：如果两个相同的、确定性的过程从相同的状态开始，并以相同的顺序获得相同的输入，那么这两个过程将产生相同的输出，并在相同的状态下结束。这可能有点难以理解，让我们更深入地讨论和理解它的真正含义。确定性意味着处理过程与时间无关，任何其他“外部”输入都不会影响处理结果。例如，如果一个程序的输出受到线程执行的具体顺序、获取等非重复性事件的调用或其他非重复性事件的影响，那么这些程序通常最有可能被视为不确定性。过程状态是过程中保存在机器上的任何数据。在过程处理结束时，这些数据要么保存在内存中，要么保存在磁盘上。以相同的顺序获得相同输入的地方应引起注意——这是引入日志的地方。这里有一个重要的常识:如果输入两个具有相同确定性代码的日志，它们将产生相同的输出。分布式计算的应用尤为明显。您可以将使用多台机器一起执行同一事项的问题减少为为这些过程输入实现分布式一致性日志的问题。这里日志的目的是将所有不确定的东西排除在输入流之外，以确保每个复制过程都能同步处理输入。当你理解这一点时，状态机的复制原理就不再复杂或深奥：这或多或少意味着“确定性处理过程是确定性”。无论如何，我认为它是分布式系统设计中常用的工具之一。这种方法的一个美妙之处在于，索引日志的时间戳就像时钟状态的副本——你可以用一个单独的数字来描述每个副本，这是处理日志的时间戳。时间戳与日志对应整个副本的状态。由于写入日志的内容不同，在系统中应用这一原则的方法也有很多。例如，我们记录一个服务请求，或者服务从请求到响应状态的变化，或者它执行命令的变化。理论上，我们甚至可以为每个副本记录一系列要执行的机器指令或调用的方法名和参数。只要两个过程以相同的方式处理这些输入，副本就会保持一致。一千个人眼中有一千种日志用法。数据库工作者通常区分物理日志和逻辑日志。物理日志是记录每行变化的内容。逻辑日志记录的不是改变行，而是导致行内容改变的SQL句子（insert，update和delete语句)。分布式系统通常可以分为两种方法来处理数据和完成响应。“状态机器模型”通常引用一个主动-主动模型，即我们记录请求和响应的对象。对此进行细微的更改，称为“预备份模型”，即选择副本作为领导，并允许其按要求到达的时间进行处理，并输出记录处理过程中状态变化的日志。其他副本按照leader状态变化的顺序应用这些变化，以便在leader失败时实现同步并取代leader的工作。为了理解这两种方法的区别，我们来看一个不太严格的例子。假设有一个算法服务副本，保持一个独立的数字作为其状态(初始值为0)，并对该值进行加法和乘法。主动-主动方式应输出所进行的变换，如“ “*2”等。这些变换将应用于每个副本，以获得相同的解集。主动-被动模式将有一个独立的主体来执行这些变化并输出结果日志，如“1”、“3”、“6”等。这个例子也清楚地显示了为什么顺序是确保副本之间一致性的关键：加法和乘法顺序的变化会导致不同的结果。分布式日志可理解为一致性问题模型的数据结构。因为日志代表了一系列后续追加值的决定。尽管日志模块是他们最常见的应用程序，但您需要重新审视Paxos算法簇。在Paxos算法中，它通常使用称为多paxos的协议，将日志建模成一系列问题，每个问题都有相应的部分。日志在ZAB、RAFT等其他协议中的作用尤为突出，它直接建模了维护分布式和一致性日志的问题。我怀疑的是，我们对历史发展的看法存在偏差，可能是因为分布式计算的理论在过去几十年中远远超过了它的实际应用。现实中，共识问题有点太简单了。计算机系统很少需要决定单个值，它们几乎总是按顺序处理请求。这种记录自然更抽象，而不是简单的单值寄存器。此外，专注于算法掩盖了抽象系统所需的底层日志。我怀疑我们最终会更加*日志作为商业基石，无论它是否以同样的方式实施，我们经常谈论一个哈希表，而不是纠结于我们是否得到一个特定的细节，如线性或其他变体哈希表。日志将成为一个流行的界面，为大多数算法和实现提升提供最好的保证和性能。变更日志101：表与事件的二相性。让我们继续谈论数据库。日志和表之间的二相性在数据库中有很多变化。这类日志与贷款清单和银行流程有些相似，数据库表是当前的盈余表。如果您有大量的变更日志，您可以使用这些变更来创建一个捕获当前状态的表。本表将记录每个关键点(日志中的特殊时间点)的状态信息。这就是为什么日志是一个非常基本的数据结构：日志可以用来创建基本表或各种衍生表。与此同时，它意味着可以存储非关系对象。这个过程也是可逆的：如果您正在更新一个表，您可以记录这些变化，并将所有更新的日志发布到表的状态信息中。这些变更日志是您需要的准实时克隆支持。基于此，您可以清楚地理解表与事件的二相性：表支持静态数据和日志捕获变化。日志的魅力在于它是变化的完整记录，它不仅捕捉到了表的最终版本，还记录了其他版本的信息。本质上，日志是表历史状态的一系列备份。这可能会导致你管理源代码的版本。源代码管理与数据库密切相关。版本管理解决了一个非常熟悉的问题，即什么是分布式数据系统需要解决的分布式管理。补丁的发布通常是基于版本管理系统，这实际上可能是一个日志。您可以直接与当前类似于表中的代码进行“快照”交互。你会注意到，与其他分布式状态系统类似，版本控制系统会在您更新时复制日志，您只想更新补丁并将其应用到您当前的快照中。最近，一些人从Datomic开始–一家销售日志数据库的公司得到了一些想法。这些想法使他们对如何在他们的系统中应用这些想法有了广泛的理解。当然，这些想法不仅仅是针对这个系统，它们将成为十多年来分布式系统和数据库文献的一部分。这似乎有点太理想化了。但不要悲观！我们很快就会实现它。请先解释一下“数据集成”是什么意思，为什么我觉得很重要，然后再来看看和日志有什么关系。数据集成是组织数据，以便在相关服务和系统中访问数据。“数据集成”（dataintegration）这个短语应该不仅仅是那么简单，但我找不到更好的解释。更常见的术语ETL通常只覆盖数据集成的有限子集(译注:ETL，Extraction-Transformation-与关于Loading的缩写相比，即数据提取、转换和加载)-