我加入LinkedIn大约六年前在一个特别有趣的时间。我们刚开始对我们整体式，集中式数据库的极限跑起来，并开始过渡到专门的分布式系统的组合需要。这是一个有趣的实验：我们构建，部署和运行这一天的分布式图形数据库，分布式搜索的后端，Hadoop的安装，以及第一代和第二代key-value存储。
其中最有用的东西，我在这一切的教训是很多的，我们正在构建的事情曾在他们的心脏一个非常简单的概念：日志。几乎只要有时被称为预写日志或提交日志或事务日志，日志已经出现如计算机，并在许多分布式数据系统和实时应用程序体系结构的心脏。
你不能完全理解的数据库，NoSQL的专卖店，键值存储，复制的Paxos，Hadoop的，版本控制，或者几乎任何软件系统不理解日志; 然而，大多数的软件工程师不熟悉他们。我想改变这种状况。在这篇文章中，我将带您看您需要了解日志，包括什么日志以及如何使用日志数据集成，实时处理和系统建设的一切。
第一部分：什么是日志？
日志也许是最简单可行的存储抽象。它是按时间排序的记录追加只，完全排序顺序。它看起来像这样：
记录被追加到日志的末端，和读出进行左到右。每个条目被分配一个唯一的顺序日志条目号。
的记录的顺序定义，因为条目的左侧被定义为较旧然后条目右侧的“时间”的概念。该日志条目数可以被认为是作为条目的“时间戳”。描述这个顺序与时间的概念似乎起初有点古怪，但它有它从任何特定的物理时钟脱钩的方便特性。这个属性会变成是至关重要的，因为我们得到的分布式系统。
的记录的内容和格式是不是本讨论的目的很重要的。此外，我们不能只是一味添加记录到日志中，我们最终将空间用完。我会回来到这一点。
因此，日志是不是所有的从一个文件或表不同。文件是字节数组，表是一组记录和日志其实只是一种表或文件，其中记录按时间排序。
在这一点上，你可能想知道为什么这是值得谈论的东西这么简单吗？如何记录相关数据系统的任何方式只追加序列？答案就是日志有特定的用途：它们记录所发生的事情和时间。对于分布式数据系统，这是在许多方面，问题的心脏。
但在此之前，我们太远让我澄清的东西是有点混乱。每一个程序员熟悉测井非结构化的错误消息的另一个定义或跟踪信息的应用程序可能会写出使用日志或log4j的本地文件。为了清楚起见，我会称之为“应用程序日志”。应用程序日志中我描述了日志概念的退行性形式。最大的区别是，文本日志，目的是要主要用于人们阅读和“日记”或“数据日志”我所描述的是专为编程访问。
（其实，如果你仔细想想，人类通过个别机器的日志阅读的理念是不合时宜的东西，这种方法很快就当许多服务和服务器所涉及无法管理策略和日志的目的很快就为输入端查询和图表来了解多台机器，东西这在文件中英文文本是几乎没有适合作为这里所描述的那种结构日志的行为。）
在数据库中记录
我不知道在哪里日志概念起源，可能是像二进制搜索是过于简单的发明人意识到这是一项发明的事情之一。它是本早IBM的R系统中的数据库的使用具有同步的各种数据结构和索引的保持在撞车的情况下做的。为了使这个原子耐用，数据库使用日志写了关于他们将修改记录的信息，应用更改它维护的所有各种数据结构前。该日志是发生了什么事的记录，每个表或索引是这段历史的投影到一些有用的数据结构或索引。由于日志被立即坚持它用作恢复所有其他永久结构在发生碰撞时的权威来源。
过时间日志的使用从ACID的实现细节长大一种方法，用于在数据库之间复制数据。事实证明，变更所发生的数据库上的顺序是需要什么，以保持一个远程副本数据库同步。Oracle，MySQL等，和PostgreSQL包括日志传送协议，以日志的部分传送到副本数据库充当奴隶。甲骨文已经产品化的日志作为一般数据订阅机制与非Oracle数据用户XStreams和金门在MySQL和PostgreSQL和类似设施是许多数据架构的关键组成部分。
正因为如此起源，机器可读日志的概念已经在很大程度上被局限在数据库内部。作为数据订阅机制使用日志似乎几乎是偶然丛生。但是这很抽象是理想用于支撑各种消息，数据流，和实时数据的处理。
在分布式系统日志
这两个问题日志解决-订货变化和分发数据是即使在分布式数据系统中更为重要。在排序同意更新（或同意不同意，并与副作用应对）是这些系统的核心设计问题之一。
日志为中心的分布式系统源自一个简单的观察，我会打电话给国机复制原理：
这似乎有点钝，所以让我们深入并明白它的意思。
确定性意味着处理未时序依赖性和不允许任何其他“带外”输入影响其效果。例如一个程序的输出是由线程的执行的特定顺序或由一个呼叫的影响gettimeofday或其它一些非可重复的是一般最好看作非确定性。
的状态的过程是任何数据保持在机器上，或者在存储器中或磁盘上，在该处理的结束。
关于得到相同的输入以相同的顺序应响位钟这正是在日志进来这是一个非常直观的概念：如果你给两个代码确定性件相同的输入日志，它们将产生相同的输出。
分布式计算的应用是很明显的。您可以减少使多台机器都做同样的事情，以实施分布式一致日志来养活这些过程的输入问题的问题。这里日志的目的是要挤压的所有非决定出输入流，以确保每个副本处理此输入保持同步。
当你了解它，没有什么复杂的或深约这样的原则：它或多或少等于说“确定性处理是确定的。” 尽管如此，我认为这是对分布式系统设计的更普遍的工具之一。
一个对这种做法的美丽的东西是时间戳记该索引的日志现在充当时钟的状态副本，您可以通过一个单一的数字，时间戳因为它已经处理的最大日志条目描述每个副本。此时间戳的日志结合独特的捕获副本的整个状态。
有很多这取决于置于日志中的系统中应用这种原理的多种方式。例如，我们可以登录进入的请求到服务，或状态改变了服务响应经历要求，或改造它的命令执行。从理论上讲，我们甚至可以记录一系列的机器指令对每个副本执行或方法名称和参数来调用每个副本。只要两个过程处理以相同的方式，这些输入，进程将剩余横跨副本一致。
不同的人群似乎会以不同描述日志的用途。数据库一般人区分物理和逻辑日志记录。物理记录装置记录该被改变的每一行的内容。逻辑日志记录是指不改变行，但导致该行更改（插入，更新和删除语句）的SQL命令。
分布式系统文献常用区分两大类方法来处理和复制。该“状态机模型”通常指的地方，我们保持一个日志中的传入请求主动 - 主动模式，每个副本处理每个请求。这方面的一个轻微的修改，被称为“初级备份模式”，就是要选出一个副本为龙头，让这位领导者来处理他们到达的顺序请求和处理请求注销改变其状态。在其他副本适用于为了国家改变领导者，使使他们保持同步，并准备接任领导人应该领导失败。
要理解这两种方法之间的区别，让我们来看看玩具的问题。考虑复制“算术服务”，它保持一个单一的数作为其状态（初始化为零），并适用于加法和乘法这个值。主动积极的方法可能会注销转换申请，说“+1”，“* 2”，等等。每个副本将适用这些转换，从而通过相同的价值观。“主动-被动”的方式将有一个单一的主执行变换和注销的结果，说“1”，“3”，“6”，等等。这个例子也明确为什么排序是确保一致性的关键复制品：重新排序加法和乘法将产生不同的结果。
分布式日志可以被看作是在数据结构模型的共识的问题。日志，毕竟代表了“下一个”值追加一系列决定。你得稍微斜视一下，看看日志中的Paxos算法家族，虽然日志建设是他们最常见的实际应用。有了Paxos的，这是使用协议的扩展名为“多的Paxos”，通常做哪些车型日志作为一系列共识的问题，一个是在日志中的每个插槽。日志是在其他的协议，如更为突出ZAB ，RAFT，和Viewstamped复制，这直接建模维持分布式的，一致的日志的问题。
我怀疑，我们的这一观点是历史的路径偏差，可能是由于在分布式计算的理论超过了其实际应用的几十年一点点。在现实中，共识的问题是有点太简单了。计算机系统很少需要确定一个值，他们几乎总是处理请求的序列。这样一个日志，而不是一个简单的单值寄存器，是更加自然的抽象。
此外，专注于算法，掩盖了潜在的日志抽象系统需要。我怀疑我们最终会更多地关注日志作为一个商品化的积木，不论它在我们常说的一个哈希表以同样的方式执行，而不会打扰在我们是否意味着杂音哈希值与线性探测或一些细节来获得其它变体。该日志将成为商品化接口的东西，有许多算法和实现竞争提供最好的保障和最佳的性能。
更新日志101：表和事件是双
让我们回过头来对位数据库。有一个日志的变化和桌子之间的facinating两重性。日志类似于所有贷方和借方和银行的进程列表; 一个表是所有当前账户余额。如果你有一个日志的变化，可以以创建表捕获当前状态应用这些更改。该表将记录每个按键的最新状态（作为一个特定的日志时间）。有一种感觉，即日志是更基本的数据结构：除了创建原始表，你也可以将它制作成各种派生表。（是的，表可以意味着对非关系人键控数据存储。）
这个过程反向工程太：如果你有一个表以更新，您可以记录这些变化和发布的所有更新表中的状态“更新日志”。此更新日志正是你需要支持近实时副本什么。因此，在这个意义上，你可以看到表和事件双：表在休息和日志捕获变化支持数据。日志的神奇之处在于，如果它是一个完整的修改日志，它拥有不仅表的最终版本的内容，也可以让重建，可能已存在的所有其他版本。它是，有效地，一种备份的每个表中的前一状态。
这可能提醒你的源代码版本控制。有源控制和数据库之间的密切关系。版本控制解决了一个非常类似的问题是什么分布式数据系统都需要解决，管理分散，状态并发的变化。版本控制系统通常模型补丁的顺序，这实际上是一个日志。您可以直接在当前代码的签出的“快照”，这是类似于表进行交互。你会注意到，在版本控制系统，与其他分布式状态系统，通过复制日志发生了：当你更新你拉下只是补丁，并将其应用到当前快照。
有些人从看到一些这些想法最近Datomic，一个公司销售日志为中心的数据库中。这表现给出了他们是如何应用在他们的系统的想法很好的概述。这些想法不是唯一的这个系统，当然，因为他们已经在分布式系统和数据库文献远远超过十年的一部分。
这一切似乎有点理论。不要绝望！我们会得到实际的东西很快。
下一步是什么
在本文的其余部分我会尽量给一个什么样的记录是良好的超越分布式计算或抽象的分布式计算模型的内部一番风味。这包括：
- 数据集成 -Making所有在其所有的存储和处理系统容易获得企业的数据。
- 实时数据处理 -Computing派生数据流。
- 分布式系统设计 -如何实际系统可以通过用日志为中心的设计简化。
这些用途都解决围绕一个日志作为一个独立的服务理念。
在每一种情况下，该日志的效用来自简单的函数，所述日志提供：生产历史的一个持久的，重新可玩记录。出人意料的是，在这些问题的核心是具有多台机器播放历史在一个确定的方式自己率的能力。
第二部分：数据集成
让我先说一下我的“数据整合”为什么我认为这是重要的，然后我们会看到它如何与回日志的意思。
这句话“数据整合”是不是所有的常见的，但我不知道一个更好的。更易于辨识术语ETL通常只包括数据集成，填充关系型数据仓库有限的一部分。但大部分我所描述可以被看作是广义ETL覆盖实时系统和处理流程。
你没有听到太多关于中的所有利益气喘吁吁的数据集成和炒作周围人的想法大数据，但尽管如此，我相信“使数据可用”，是更宝贵的东西组织可以专注于一个平凡的这个问题， 。
有效利用数据如下一种需求层次理论。金字塔的基础包括捕捉所有的相关数据，能够把它一起在适用的处理环境（是一个奇特的实时查询系统，或只是文本文件和Python脚本）。这个数据需要以统一的方式，以方便阅读和过程进行建模。一旦以统一的方式捕获数据的这些基本需求都照顾它是合理的基础设施建设工作，处理各种方式-MapReduce的，实时查询系统等这个数据
值得注意的是显而易见的：没有可靠和完整的数据流，Hadoop集群比非常昂贵，难以装配空间加热器而已。一旦数据和处理都可以，一是可以继续关注的良好的数据模型和一致性很好理解语义，更精致的问题。最后，浓度可转移到更复杂的处理，更好的可视化，报告和处理的速度和预测。
根据我的经验，大多数组织都在这个的基础上巨大的坑洞金字塔他们缺乏可靠完整的内容流，但要直接跳转到先进的数据建模技术。这完全是倒退。
所以，问题是，我们如何能够建立在整个组织中的所有数据系统可靠的数据流？
数据集成：两个并发症
两个趋势使得数据整合更难。
事件数据流水
第一种趋势是事件数据的上升。事件数据记录发生的事情，而不是东西都是。在网络系统中，这意味着用户的活动记录，也能可靠地操作并监视机器的数据中心的价值所需的机器级事件和统计数据。人们往往称之为“记录数据”，因为它往往是写入应用程序日志，但混淆形式的功能。这个数据是在现代网络的心脏：谷歌的财富，毕竟是建立在点击和展示，也就是说，事件相关管道产生的。
这东西不仅限于网络公司，它只是网络公司已经完全数字化，因此他们更容易的仪器。财务数据早已以事件为中心，RFID增加了这种跟踪物理对象。我认为，这一趋势将继续与数字化传统业务和活动。
这种类型的事件数据记录的发生了什么，往往要比传统的数据库使用大几个数量级。这为处理显著挑战。
专业数据系统爆炸
第二个趋势来自于爆炸，在过去五年中已经成为流行，经常免费提供专门的数据系统。专业系统存在OLAP，搜索，简单的 在线 存储，批量处理，图形分析，并因此 上。
的多品种，并获得该数据转换成多个系统的愿望更多的数据的组合导致了巨大的数据整合问题。
日志结构的数据流
日志是用于处理系统之间的数据流的自然数据结构。配方很简单： 每个逻辑数据源可以被建模为它自己的日志。数据源可能是注销事件（比如点击或网页浏览），或接受修改数据库表的应用程序。每个订阅系统从该日志尽可能快，因为它可以读取，适用于每一个新的记录到它自己的商店，并提出在日志中的位置。订户可以是任何类型的数据系统的高速缓存，Hadoop的，在另一个站点的另一个数据库，搜索系统等。
例如，日志概念给出了针对其所有订户可以测量每个改变一个逻辑时钟。这使得对不同的用户的系统的相对于彼此简单得多的状态的推理，因为每个具有“时间点”，他们已读到。
为了使这个更具体，考虑一个简单的例子，其中有一个数据库和缓存服务器的集合。日志提供了一种同步的更新而所有这些系统和推理的这些系统中的时间点。比方说，我们用写日志条目X中的记录，然后需要从缓存中做一读。如果我们要保证我们没有看到陈旧的数据，我们只需要确保我们不从尚未复制到任何X.缓存读取
日志还用作缓冲器，使数据生成异步从数据消耗。这是一个很大的原因重要的，但特别是当有可能以不同的速率消耗多个用户。这意味着用户系统可能会崩溃或者去停机维护，并追上时，它回来：用户消耗在它控制的速度。批处理系统如Hadoop的或数据仓库可能消耗仅每小时或每天，而实时查询系统可能需要先进的所述秒。既不是原始数据源也不是日志具有各种数据目的地系统的知识，所以消费者系统可以并用在管道无变化除去。
特别重要的：目标系统只知道日志和起源的系统没有任何细节。消费者系统不需要与是否从一个RDBMS，一个新发明的key-value存储传来的数据，或者没有任何形式的实时查询系统生成关注自身。这似乎是一个小点，但实际上是至关重要的。
我使用“日志”在这里，而不是“消息系统”或“酒馆子”，因为它是很多更具体的关于语义，你需要在实际执行什么来支持数据复制更密切描述。我发现，“发布订阅”并不意味着比间接的消息，如果你处理比较任意两个消息系统有前途的发布-订阅，你会发现，他们保证完全不同的东西，大多数车型都没有在这个领域非常有用得多。你能想到的日志作为作为一种消息传送系统的耐用性与保障性强排序的语义。在分布式系统中，传播的这种模式有时的（有点可怕）名称变核广播。
值得强调的是，日志还只是基础设施。这不是掌握数据流的故事的结尾：故事的其余部分周围的元数据，模式，兼容性和处理数据的结构和演化的所有细节。但是，直到有处理数据流的机制一个可靠的，一般的方式，语义细节是次要的。
在LinkedIn
我看在快进这个数据集成问题，脱颖而出，成为LinkedIn从一个集中的关系型数据库迁移到分布式系统的集合。这些天，我们的主要数据系统包括：
每个这些是一个专门的分布式系统，在其专业领域提供先进的功能。
使用数据流日志的这种想法已经漂浮在LinkedIn，因为我之前也来到这里。最早的一个部分，我们开发的基础设施是一个服务，称为数据总线所提供的我们早期的Oracle表的顶部日志高速缓存抽象扩展订阅数据库的更改，所以我们可以养活我们的社交图和搜索索引。
我给历史一点点地提供上下文。我自己在这种参与启动2008年左右，我们已经交付了key-value存储之后。我的下一个项目是试图得到一个工作的Hadoop的设置去，将一些我们的建议的过程中出现。有了这方面的经验不多，我们自然预算数周进出获取数据，以及我们何时落实看中预测算法休息。于是开始了漫长的跋涉。
我们原计划勉强数据我们现有的Oracle数据仓库。第一个发现是，获取数据了甲骨文的快速是一个黑暗的艺术。更糟的是，数据仓库处理是不合适的，我们计划在Hadoop的大部分处理是不可逆和具体申报正在进行的生产批量处理。我们最终避免了数据仓库和直接进入到源数据库和日志文件。最后，我们实现了另一个管道将数据加载到我们的key-value存储为服务的结果。
这个平凡的数据拷贝结束了的主导项目的原始发展方向之一。更糟的是，有在任何管道的问题任何时候，Hadoop的系统主要是无用的运行上的坏数据花哨的算法，只是产生更多的坏数据。
虽然我们已经建立的东西在一个相当通用的方式，每一个新的数据源所需的自定义配置来设置。它也被证明是错误和故障的数量庞大的来源。我们已经在Hadoop上实现的网站功能走红，我们发现自己有兴趣的工程师组成的长长的名单。每个用户有系统的列表，他们希望集成和长新数据源列表他们想要的。
有几件事情慢慢地我就明白了。
首先，我们所建造的管道，虽然有点乱，实际上是非常有价值的。只是让数据提供了新的处理系统（Hadoop的）的过程中解锁很多的可能性。新的计算是可能的，将已经很难做之前的数据。许多新产品，分析刚刚从先前已在专门的系统锁定了多个数据放在一起来到。
其次，很显然，可靠的数据加载需要从数据管道的深度支持。如果我们捕获的所有我们需要的结构，我们可以让Hadoop的数据加载全自动的，所以没有手工工作量扩大增加新的数据源或处理架构更改数据会神奇地出现在HDFS和蜂巢表将自动为新生成数据源与相应的列。
第三，我们仍然有非常低的数据覆盖。也就是说，如果你看着数据LinkedIn已经在Hadoop中是可用的总百分比，它仍然是非常不完整的。并获得完成是不会给的努力，以实施每一个新的数据源所需的量很容易。
我们一直在前进的路上，扩建自定义数据负载，每个数据源和目标，显然是不可行的。我们有几十个数据系统和数据存储库。连接所有这些都将导致建筑每对系统像这样的定制管道：
注意，数据经常在两个方向流动，因为许多系统（数据库，Hadoop的）是用于数据传输的两个源和目的地。这意味着我们将最终建立每个系统两条管道：一个拿到数据，一个用于获取数据了。
这显然将采取人民建设军队，绝不会是可操作的。当我们走近完全连通性，我们最终会得到像O（N2）等的管道。
相反，我们需要这样的东西一般：
尽可能，我们需要为每个消费者从数据的源隔离开来。他们最好应该只是一个单一的数据存储库，这将让他们获得的一切整合。
这个想法是，增加一个新的数据的系统是它的数据源或数据目的地应该创建整合唯一的工作将其连接到一个单一的管道，而不是数据的每个消费者。
这种经历使我重点建设卡夫卡结合我们在与日志概念数据库和分布式系统内部流行的消息系统所看见的。我们想要的东西，首先作为一个中央管道的所有活动数据，并最终为许多其他用途，包括数据部署了Hadoop的，监测数据等。
很长一段时间，卡夫卡是一个小唯一的（有些人会说奇）为基础的产品，既不是数据库也不是日志文件收集系统，也不是一个传统的邮件系统。但最近亚马逊提供的服务，这是非常非常类似于卡夫卡称为室壁运动。相似的推移一直到分区的处理方式，数据将被保留，而高，低层次消费者之间的卡夫卡API中的相当奇怪的分裂。我很高兴这件事。你已经创建了一个良好的基础设施的抽象的标志是，AWS提供它作为一个服务！他们对这一设想似乎正好类似于我描述：它是连接他们所有的分布式系统，DynamoDB，红移，S3等，以及使用EC2分布式流处理的基础管道。
关系ETL和数据仓库
让我们来谈谈数据仓库一会儿。数据仓库，就是要构造成支持分析的清洁，集成的数据的储存库。这是一个伟大的想法。对于那些不在知道，数据仓库方法涉及周期性提取源数据库中的数据，它改写（munging）成某种可理解的形式下，它装载到中央数据仓库。有一个包含所有数据的全新副本这个中心位置，是数据密集型分析和处理的非常宝贵的财富。在高层次上，这种方法并没有改变太多，你是否使用像Oracle或Teradata数据或Hadoop的一个传统的数据仓库，虽然你可能会开关向上装载和需要改写的顺序。
含清洁，集成数据的数据仓库是一个惊人的资产，但得到这个的机制是一个有点过时了。
对于以数据为中心的组织，关键的问题是清洁集成数据耦合到数据仓库。数据仓库是一块批量查询基础设施，这是非常适合于多种报表和即席分析，特别是当涉及查询简单的计数，聚合和过滤。但具有间歇系统是清洁的完整数据的唯一信息库装置的数据是需要实时馈送实时处理系统中，搜索索引，监控系统等不能使用。
在我看来，ETL真的是两件事情。第一，它是一种提取和数据清除过程，基本上释放在各种组织中的系统锁定数据和去除系统特定的无感。其次，该数据被重构为数据仓库查询（即由以适应一个关系数据库的类型系统，压入星形或雪花模式，或许捣碎成高性能柱 格式等）。混为一谈这两件事情是一个问题。数据的清洁，集成储存库应在实时以及低延迟处理以及索引在其它实时存储系统上可用。
我觉得这使得数据仓库ETL的好处多组织上的扩展性。数据仓库团队的经典的问题是，它们负责收集和清洁由每一个其他团队在组织中产生的所有数据。激励不对齐：数据生产者往往不很清楚在数据仓库中的使用数据，并最终创造的数据是很难提取或需要大量的，难以扩展转型进入可用的形式。当然，中央队从未完全管理规模相匹配的组织其余的步伐，因此数据覆盖范围总是参差不齐，数据流是脆弱的，变化是缓慢的。
更好的办法是有一个中央管道，日志，与添加数据明确定义的API。与这条管道整合，并提供一个干净，结构良好的数据馈送的责任在于这些数据的饲料生产商。这意味着，作为他们的系统设计和实施的情况下，他们必须考虑获取数据出来并进入井结构形式用于递送至中央管道的问题。加入新的存储系统的任何后果到数据仓库的团队，因为它们具有集成的中心点。数据仓库团队只处理从中央日志数据加载结构饲料的简单的问题，并开展具体改造他们的系统。
当人们考虑采用超越传统的数据仓库的其他数据系统这对组织的可扩展性问题就显得尤为重要。说，例如，一个希望提供超过设定的组织完整的内容搜索功能。或者说，一个人想提供数据的亚秒级监测与实时趋势曲线流和报警。在这两种情况下，传统的数据仓库，甚至Hadoop集群的基础设施将是不适当的。更糟的是，专门用于支持数据库负载ETL处理管道可能是没有用的喂养这些其他系统，使得自举这些作品的基础设施大承诺作为采用数据仓库。这可能是不可行的，可能有助于解释为什么大多数企业没有容易获得他们所有的数据这些功能。相反，如果该组织已经建立了统一的饲料，以及结构化的数据，得到任何新的系统完全访问所有数据只需要集成管道的单个位附加到管道。
这个架构也提出了一组为其中特定的清除或转化可以驻留不同的选项：
- 它可以通过数据产生加该数据到企业宽日志之前完成。
- 这是可以做到的对日志实时转换（这又产生一个新的，转化的日志）
- 这是可以做到的加载过程的一部分到某个目的地数据系统
最好的方式是有清理之前由数据的发布者发布的数据到日志完成。这意味着确保数据处于规范形式，并不会保留产生它或它可能一直保持存储系统的特定代码的任何船舱接管。这些细节最好的，因为他们最了解自己的数据创建数据的团队来处理。在此阶段应用的任何逻辑应无损可逆的。
任何种类的转化增值，可以实时进行应上产生的原始日志饲料进行作为后处理。这将包括像事件数据sessionization，或添加其他衍生领域是普遍关心的。原来的日志仍然可用，但此实时处理产生含有扩充数据派生日志。
最后，只有特定于目标系统聚合应加载过程的一部分来执行。这可能包括将数据转变为特定的星型或雪花架构分析和数据仓库报告。因为这个阶段，其中大多数自然地映射到传统的ETL过程，现对一个远更清洁和更均匀的集流完成的，但应当大大简化。
日志文件和事件
让我们来谈谈这个架构的一个附带的好处是一点点：它使解耦，事件驱动的系统。
在网络业活动数据的典型方法是将其记录到了为文本文件，其中它可以被报废到数据仓库或进入的Hadoop的聚集和查询。这里的问题是一样的所有批次的ETL问题：它夫妻的数据流向数据仓库的能力和处理进度。
在LinkedIn，我们已经建立了我们的事件数据在日志为中心的方式处理。我们使用卡夫卡作为中心，多用户事件日志。我们定义了几百事件类型，捕捉每一个特定类型的动作的独特属性。这涵盖了从网页浏览，广告展示和搜索，服务调用和应用程序异常。
要理解这种方法的好处，想象一个简单的事件，显示了工作页面上的招聘启事。作业页面应该只包含显示作业所需的逻辑。然而，在一个相当动态站点，这很可能会成为与无关的表示作业附加逻辑夹杂起来。例如，让我们说，我们需要集成以下系统：
- 我们需要发送这个数据Hadoop和数据仓库进行离线处理的目的
- 我们需要计算的观点，以确保观察者不试图某种内容刮
- 我们需要聚合这一观点在招聘海报的分析显示页面
- 我们需要记录的观点，以确保我们正确地展示上限为该用户任何工作的建议（我们不想一遍又一遍表现出同样的事情）
- 我们的推荐系统可能需要记录的观点正确地跟踪作业的普及
- 等等
很快，显示作业的简单行为已经变得相当复杂。当我们添加了显示移动作业等场所的应用，等等 - 这种逻辑必须结转和复杂性的增加。更糟的是，我们需要现在有些接口系统交织在一起，在上显示就业工作的人需要了解许多其他系统和功能，并确保他们得到适当的整合。这只是问题的一个玩具版本，任何真正的应用程序会更多，而不是更少的，复杂的。
“事件驱动型”的风格提供了一种方法来简化这一点。这项工作显示页面现在只是显示一个作业，并记录该工作与工作的相关属性，观众和有关作业的显示任何其他有用的事实一起显示的事实。每一个其他有关系统，推荐系统，安全系统，作业海报分析系统，以及数据仓库都只是订阅的饲料，并做他们的处理。上述显示用代码无需知道这些其它系统，并且如果增加了一个新的数据消费者不必改变。
建立可扩展的日志
当然，从用户分离出版商是什么新鲜事。但是，如果你想保持一个提交日志，充当一切发生在一个消费规模网站的多用户实时日志，可扩展性将是一个主要挑战。使用日志作为通用集成机制是永远不会比一个优雅的幻想更多，如果我们不能建立一个日志速度快，价格便宜，以及足够的可扩展性，大规模地进行这一实际。
系统通常人们认为一个分布式日志作为一个缓慢的，重量级的抽象（通常只用一种“元数据”使用提供了动物园管理员可能是适当的关联）。但有一个体贴的实施重点日记大型数据流，这不必是真的。在LinkedIn我们目前正在运行的60十亿唯一的消息通过卡夫卡每天写（几百十亿如果从算上写数据中心之间镜像）。
我们使用卡夫卡一些技巧来支持这种规模的：
- 分区日志
- 由配料优化吞吐量读取和写入
- 避免不必要的数据拷贝
为了让横向扩展我们砍了我们的日志为分区：
每个分区是一个全序的日志，但分区之间没有全球性的排序（或许比一些挂钟时间可能包括在邮件等）。消息的一个特定的分区的分配是可控制的由作家，大多数用户通过某种关键的（例如，用户id）的选择，以分区。分区允许日志无附加碎片之间的协调出现并允许系统的吞吐量与卡夫卡簇大小线性扩展。
每个分区跨越可配置数量的副本，其中每个具有分区的日志的相同副本复制。在任何时候，他们中的一个人会充当领导者; 如果领导者失败，其中一个副本将接任的领导者。
缺乏跨分区的全球秩序是一个限制，但我们没有发现它是一个主要的。的确，与日志相互作用通常来自数百或数千个不同的过程，因此它是没有意义的谈论过他们的行为总次序。相反，我们所提供的保证是，每个分区被顺序保存，并且附加到从单个发送者的特定分区卡夫卡保证将在它们被发送的顺序来传送。
日志，就像一个文件系统，便于优化线性读写模式。日志可以一群小读取和写入在一起形成大，高通量操作。卡夫卡积极追求这种优化。配料给消费者服务器之间传送硬盘数据时，在写入，复制，数据传输，并在确认提交的数据时，从客户端到服务器。
最后，卡夫卡将使用保存在内存日志，磁盘上的日志之间的简单的二进制格式，并在网络数据传输。这使我们能够利用大量优化，包括零拷贝数据传输。
这些优化的累积效应是，你通常可以写，并在由磁盘或网络支持的速度读取数据，即使同时保持数据集，大大超出内存。
这写了是不是意味着是主要是关于卡夫卡，所以我不会进入进一步的细节。可以读取LinkedIn的方法的更详细的概述这里和卡夫卡的设计的全面概述此处。
第三部分：日志和实时流处理
到目前为止，我只描述了数额是多少，从一个地方到地方复制数据的方法看中。但是，在存储系统之间shlepping字节是不是故事的结束。事实证明，“日志”是另一个词为“流”的日志在的心脏流处理。
但是，等待，究竟什么是流处理？
如果你是90年代末和21世纪初的粉丝数据库 文献或半成功的数据 基础架构 的产品，你可能会联想流处理与努力构建SQL引擎或“方框和箭头”界面，事件驱动处理。
如果你遵循开源数据系统爆炸，你可能与一些在这个领域，例如，系统的副流处理风暴，阿卡，S4，和Samza。但大多数人看到这些作为一种异步消息处理系统从群集感知RPC层没有什么不同的（事实上在这个空间里有些东西是完全的）。
这两种观点都有点有限。流处理无关与SQL。也不是仅限于实时处理。还有就是你不能处理的数据从昨天流或在一个月前使用各种不同的语言来表达的计算没有内在的原因。
我看到流处理的东西更广泛：基础设施的连续数据处理。我觉得计算模型可以像一般的MapReduce的或其他分布式处理框架，但要产生低延迟结果的能力。
该处理模型的实际驱动是收集数据的方法。它被收集在批量数据以批处理自然处理。当数据被连续地收集，很自然连续处理。
美国人口普查提供批量数据采集的一个好例子。普查定期揭开序幕，并通过确实有周围的人送货上门走了蛮力发现和列举的美国公民。这在1790年取得了很大的感觉，当普查首次开始。在采集数据的时间是天生批次为导向，它涉及到周围骑在马背上，并在纸上写下的记录，那么这个运输一批记录到中央位置，人类加起来的种种罪状。这些天，当你描述的普查过程中的一个立刻想知道为什么我们不把生死日记且产生的人口计数连续或有需要的任何粒度。
这是一个极端的例子，但许多数据传输过程还取决于采取定期转储和批量传输和整合。处理一个批量转储的唯一自然的方式是使用批处理。但由于这些过程与连续饲料替代，一种天然开始趋向连续处理转移到理顺所需的处理资源，减少等待时间。
LinkedIn为例，几乎没有批量数据采集的。我们的大部分数据的或者是活动的数据或数据库的改变，这两者的连续发生。事实上，当你想到的任何业务，底层机制几乎都是一个持续的过程，事件发生的实时，因为杰克·鲍尔会告诉我们。当数据批量收集，它几乎总是由于数字化的一些手动步骤或缺乏，或从一些非数字化进程的自动化遗留下来的文物。发送和反应中使用是非常慢的数据时，力学是邮件和人类那样的处理。在自动化第一遍始终保留原工艺的形式，所以这往往徘徊了很久。
日常运行生产的“批量”处理作业常常模仿有效的一种连续计算用一天的窗口大小。基础数据，当然，总是在不断变化。这实际上是如此普遍在LinkedIn（并使其在Hadoop中如此棘手工作的机制），我们实施了整体框架，用于管理Hadoop的增量工作流程。
由此看来，就容易有流处理的不同视图：它只是处理，其中包括的时间的基础数据一个概念被处理，并且不需要的数据的静态快照，以便它可以在一个产生输出用户控制频率，而不是等待数据集的“结束”来达成。在这个意义上说，流处理是分批处理的概括，并且，给定实时数据，一个非常重要的一般化的患病率。
那么，为什么流处理的传统观点一直是作为一个小众的应用程序？我认为最大的原因是，缺乏实时采集数据作出的学术关注的连续处理的东西。
我认为，缺乏实时采集数据很可能什么注定了商业流处理系统。他们的客户仍然进行文件化，日常批量处理ETL和数据集成。公司建立专注于提供处理引擎附加到实时数据流，流处理系统，但事实证明，在当时很少有人竟然出现了实时数据流。其实，很早就在我的LinkedIn的职业生涯，一个公司试图向我们兜售一个非常酷的流处理系统，但由于我们所有的数据是在那个时候收集在每小时文件，我们可以拿出最好的应用是管道每小时文件到系统流在时间的尽头！他们指出，这是一个相当普遍的问题。例外实际上证明这里的规则：金融，哪里流处理已经取得了一些成功的一个领域，是什么地方的实时数据流已经常态和加工已经成为瓶颈的区域。
即使在一个健康的批处理的生态系统的存在下，我想流处理的作为一个基础设施风格的实际适用性是相当广阔的。我认为它涵盖了实时请求/响应服务和离线批量处理的基础设施之间的差距。对于现代的互联网公司，我认为他们的代码大约25％属于这一类。
事实证明，该日志解决一些在流处理中最关键的技术问题，我会形容，但它解决了只是做实时的多用户数据输入可用数据的最大问题。对于那些有兴趣在更多的细节，我们有开源Samza，流处理系统明确建立在很多的这些想法。我们在文档中详细描述了很多这些应用在这里。
数据流图
流处理的最有趣的方面无关与流处理系统的内部，而是与它是如何扩展了我们的数据Feed是从早期的数据集成讨论什么想法去做。我们主要讨论了饲料或主数据的事件，并在各种应用的执行产生的数据的行的日志。不过流处理也允许我们计算包括了其它饲料的饲料。这些衍生饲料看起来没有什么不同的消费者，然后从他们计算原始数据的饲料。这些衍生的饲料可以封装任意复杂。
让我们深入到这一点。甲流处理工作，对于我们来说，将是任何东西，从日志读取和写入输出日志或其他系统。他们使用的输入和输出的日志加入这些过程进入处理阶段的图。事实上，以这种方式使用集中式日志，您可以查看所有组织的数据采集，转换和流动只是一个一系列写信给他们的日志和过程。
甲流处理器不需要有一个奇特的框架在所有的：它可以是任何进程或一组读取和写入日志的过程，但可以帮助管理处理代码来提供额外的基础设施和支持。
日志中的集成的目的是双重的。
首先，它使每个数据集的多用户，并下令。回想一下我们的“状态复制”的原则要记住秩序的重要性。为了使这个更具体，从数据库，如果我们重新排列两个更新考虑更新流在我们处理，我们可能会产生错误的最终输出相同的记录。这个命令是比由类似的TCP提供作为它不限于单点对点链路和存活超出进程故障和重新连接更永久的。
第二，日志提供缓冲的过程。这是非常重要。如果在非同步的方式进行处理，很可能发生的生产作业的上行数据会更快地产生的数据比其他下游作业可以使用它。发生这种情况时的处理必须阻塞，缓冲或丢弃数据。删除数据很可能不是一种选择; 阻塞可能会造成整个处理图表停顿下来。日志作为一个非常，非常大的缓冲，使过程重新启动或不会拖慢处理图形的其他部分失败。延伸该数据流以一个更大的组织，其中的处理是由许多不同的小组所作的工作发生时，这种隔离是特别重要的。我们不能有一个错误的原因工作背压的停止整个处理流程。
这两个风暴和Samza都采用这种方式，并且可以使用卡夫卡或其他类似的系统，其日志。
状态实时处理
一些实时流处理仅仅是无状态记录在-A-时间变换，但许多用途是更复杂的计数，聚集，或者加入了流中的窗口。一种可能，例如，希望丰富与有关用户操作的点击后在作用在加入点击流给用户帐户数据库的信息的事件流（例如一个点击流）。无一例外，这种处理结束需要某种状态的由处理器维持：例如，计算的计数时，必须计迄今维护。这怎么样的状态正确维护，如果处理器本身可能会失败？
最简单的选择是保持状态在内存中。但是，如果进程崩溃，将失去它的中间状态。如果状态仅维持了一个窗口，这个过程可能只是回落的地步窗口开始在日志中。然而，如果一个是做了一个多小时的计数，这可能是不可行的。
另一种方法是简单地将所有状态存储在远程存储系统，并加入了该网络的那家店。这里的问题是，没有数据和大量的网络往返的地方。
我们怎样才能支持这样的事情被分割了我们处理的“表”？
清楚地记得表和日志的二元性的讨论。这为我们提供了完全相同的工具，以便能够流转换为表格共同位于与我们的处理，以及用于处理容错这些表的机制。
个流处理器可以保持它在当地的“表”态或“指数”-a BDB，性LevelDB，甚至一些更不寻常，如Lucene的或fastbit指数。这这家店的内容是从它的输入流美联储（后第一次也许将任意变换）。它可以刊物出它保持，使其能够恢复崩溃和重新启动的情况下，其状态这个本地索引更新日志。此机制允许用于保持共同分配状态中任意索引类型的本地与传入的流数据的通用机制。
当这个过程发生故障，恢复从更新日志它的索引。该日志本地状态转变成一次备份一种增量纪录。
这种方法状态管理有优雅的财产，该处理器的状态也保持为日志。我们可以将这个日志就像我们会在更改记录到数据库表中。事实上，这些处理器有一些非常喜欢与他们一起保持着共同的分区表。由于这种状态本身就是一个日志，其他处理器可以订阅它。这实际上是在例相当有用时的处理的目的是更新的最终状态，并且该状态是该处理的自然输出。
当与原木出来的数据集成的目的数据库相结合，日志/表二元性的力量变得清晰。改变日志可以从数据库中提取，并通过各种流处理器以不同的形式收录参与对事件流。
我们给这种风格在管理状态Samza处理和更大量的实际例子的更多细节在这里。
登录压实
当然，我们不能希望保持一个完整的日志为所有的时间都状态的变化。除非人愿意用无限的空间，不知何故日志必须清理。我就谈一下这卡夫卡的实施，使之更加具体化。在卡夫卡，清理具有根据数据是否包含键控更新或事件数据的两个选项。对于事件数据，卡夫卡支持只是保留数据的一个窗口。一般，这是构成为几天，但可以在时间或空间来定义的窗口。对于键入的数据，不过，完整的日志的一个很好的特性是可以重新播放重新创建源系统的状态（可能重现它在另一个系统）。
然而，随着时间的推移保留完整的日志将使用更多的空间，重播将需要更长的时间和更长的时间。因此，在卡夫卡，我们支持不同类型的保留。而不是简单地扔掉旧的日志，我们删除过时的记录，即记录其主键有一个较新的更新。通过这样做，我们仍然保证日志包含源系统的完整备份，但现在我们不能再重新所有源系统以前的状态，只有较新的。我们把这种功能日志压实。
第四部分：系统构建
最后一个主题我想讨论的是在日志中的数据系统设计在线数据系统的作用。
有一个日志服务于分布式数据库中的数据流，它服务于一个更大的组织数据整合的角色的角色之间这里的比喻。在这两种情况下，它是负责对数据流，一致性和恢复。什么，毕竟是一个组织，如果不是一个非常复杂的分布式数据系统？
分拆？
因此，也许如果你眯了一下，你可以看到整个您组织的系统和数据作为一个分布式数据库流动。您可以查看所有的面向个人查询系统（Redis的，SOLR，蜂巢表等）为您的数据只是特定的索引。您可以查看像风暴或Samza流处理系统，只是一个非常发达的触发器和视图物化机制。古典数据库的人，我已经注意到，像这样的观点非常，因为它终于说明了他们在地球上的人在做什么，所有这些不同的数据系统，它们只是不同的索引类型！
有无可否认，现在的数据类型系统的爆炸，但在现实中，这种复杂性一直存在。即使在关系数据库中的鼎盛时期，组织了很多很多的关系型数据库的！因此，也许真正的整合还没有，因为当所有的数据确实是在一个地方大型机存在。有对分离数据分成多个系统中的许多动机：规模，地理，安全性和性能的隔离是最常见的。但是，这些问题都可以通过一个好的制度来解决：它有可能为一个组织有一个单独的Hadoop集群，例如，包含所有数据，并提供大量不同的选区。
因此在数据的处理，在移动已经成为可能分布式系统已经一种可能的简化：聚结大量每个系统的小实例成几个大簇。许多系统都不够好，让这个尚未：他们没有保障，否则无法保证性能隔离，或只是不很好地扩展不够。但每个问题是可以解决的。
我的看法是，不同系统的爆炸是构建分布式数据系统的难度造成的。通过减少到一个查询类型或使用情况下，每个系统能够将其范围缩小到该组的东西都是建立可行的。但运行所有这些系统产生了太多的复杂性。
我看到三个可能的方向，这可能遵循的未来。
第一种可能性是现状的延续：系统分离仍或多或少，因为它是一个很好的协议更长。这可能发生是因为分配的难度实在很难克服，或者因为这种专业化允许便利和动力系统的每一个新的水平。只要这仍然是真实的，数据集成问题仍将为成功使用数据的最中心的重要的事情之一。在这种情况下，集成数据的外部记录将是非常重要的。
第二种可能性是，有可能是一个重新合并，其中具有足够的通用的单一系统启动重新合并在所有不同的功能集成在单一尤伯杯系统。这尤伯杯系统也能像关系数据库的表面，但它是在一个组织中使用的将是完全不同的，你会只需要一个大的，而不是许许多多的小家伙。在这个世界上，还有什么，除了这是系统内部解决没有真正的数据集成问题。我认为，建立这样一个系统的实际困难，使这个可能性不大。
还有另一种可能的结果，虽然，这其实我觉得吸引人的工程师。新一代数据系统的一个有趣的方面是，他们几乎所有的开源。开源允许另一种可能性：数据基础设施可以分拆成服务和面向应用程序的系统API的集合。你已经看到这种情况出现在Java堆栈在一定程度上：
- 动物园管理员处理多系统协调（也许有点更高级别的抽象，如帮助的螺旋或馆长）。
- Mesos和纱线做处理虚拟化和资源管理
- 像嵌入式图书馆的Lucene和性LevelDB做索引
- 网状，码头和更高级别的封装类，如欺骗和rest.li处理远程通信
- Avro的，协议缓冲区，节俭，以及许许多多数不胜数的其他库序列化处理
- 卡夫卡和Bookeeper提供了后盾日志。
如果你在一堆堆叠这些事情，眯了一下，它开始看起来有点像分布式数据系统工程的乐高版。你可以拼凑这些成分共同创造可能的系统繁多。这显然不是一个故事相关的最终用户谁想必关心主要是了解API那么它是如何实现的，但也可能是对获取单个系统的简单性在不断发展，更加多样化和模块化的世界的道路。如果实施时间为分布式系统从几年到周去，因为可靠的，灵活的积木出现，然后凝聚压成一个单一的整体系统中消失。
日志的系统架构的地方
假定外部日志存在的系统允许单个系统放弃了很多自己的复杂性，并依赖于共享日志。以下是我认为一个日志可以做的事情：
- 测序并发更新节点处理数据的一致性（无论最终的或立即）
- 提供节点间的数据复制
- 提供“提交”语义作家（即承认只有当你写保证不丢失）
- 提供从系统外部数据订阅资讯
- 提供能力恢复失败的副本失去他们的数据或引导新副本
- 处理节点之间的数据的重新平衡。
这实际上是一个什么样的分布式数据系统做了相当大的部分。事实上，大部分的东西剩下的是关系到最终面向客户的查询API和索引策略。这正是要改变从系统到系统的部件：例如，全文搜索查询可能需要查询所有分区而由主键的查询可能只需要查询负责该密钥的数据中的单个节点。
这里是如何工作的。将系统划分为两个逻辑部分：日志和所述服务层。该日志捕获顺序状态的变化。无论指数是需要提供查询服务节点存储（例如key-value存储可能有一些像B树或的SSTable，一个搜索系统将有一个倒排索引）。写既可以直接到日志中，尽管它们可以由服务层被代理。写日志产生一个逻辑时间戳（比如日志中的索引）。如果系统被分配，我假定它是，则在日志和服务节点将具有相同数目的分区，尽管它们可以具有机器非常不同的号码。
该服务节点订阅日志并尽快申请写入在日志中存储的顺序其本地索引。
客户可以得到读取你写通过提供一个写的时间戳作为其查询服务节点接收这样的查询将所需的时间戳比较自己的索引点的一部分，并在必要时延迟请求，直到从任何节点语义它收录到至少那个时候，以避免提供过时的数据。
服务节点可以或可以不需要有“主控权”或“领导人选举”的任何概念。对于许多简单的用例，服务节点可以是完全没有领导者，因为日志是真理的来源。
其中一个棘手的事情分布式系统必须做的是处理恢复故障节点或从节点移动分区节点。一个典型的方法将具有在日志仅保留数据的固定窗口，并与存储在分区中的数据的快照合并于此。这同样是可能的日志中保留数据的完整副本和垃圾收集日志本身。这个移动的复杂性显著量出所述服务层，这是系统特定的，并且进入记录，其可以是通用的。
有了这个日志系统中，你得到的数据存储哺养ETL到其他系统中的内容完全开发订阅API。实际上，许多系统可以共享相同的日志，同时提供不同的索引，例如：
注意这样的日志为中心的系统是如何本身立即在其他系统的处理和加载数据流的提供者。同样，流处理器可以消耗多个输入流，然后通过另一个系统的指标是输出为他们服务。
我觉得这种观点的系统，分解成一个记录和查询API非常发人深省，因为它可以让你从系统的可用性和一致性方面分开查询的特点。其实，我觉得这是连精神上的因素不建这种方式来更好地理解系统的有效方法。
值得注意的是，虽然卡夫卡和Bookeeper是一致的日志，这不是一个要求。你可以很容易的一个因素迪纳摩样数据库到最终一致性AP日志和一个键值服务层。这样的记录是有点棘手的工作，因为它会重新传递旧邮件，并且依赖于用户来处理这个（很像迪纳摩本身）。
日志（尤其是如果它是一个完整的复制）在具有数据的单独副本的想法撞击多的人浪费。在现实中，虽然也有，使这不再是一个问题的几个因素。首先，日志可以是特别有效的存储机制。我们在存储数据中心每75TB我们的生产卡夫卡的服务器上。同时，许多服务系统需要更多的内存，有效地服务数据（文本搜索方式，比如，往往是所有内存）。正在服务的系统还可以使用优化的硬件。例如，我们的大多数实时数据的系统无论是发球出的内存或者使用固态硬盘。相比之下，日志系统只进行线性读取和写入，所以它使用的大型多TB的硬盘是非常高兴。最后，如在上面的图象，在数据是由多个系统提供服务的情况下，该日志的成本分摊在多个索引。这种结合使得外部日志的费用非常少。
这正是LinkedIn已用于构建了许多自己的实时查询系统的格局。这些系统断料的数据库（使用数据总线作为日志抽象或关闭专用日志从卡夫卡），并提供一个特定的分区，索引和查询有关该数据流的顶端能力。这是我们实现我们的搜索，社交图和OLAP查询系统的方式。事实上，这是很常见的有一个单一的数据馈送（无论是活饲料，或从Hadoop的未来一个源性饲料）复制到现场服务于多个服务系统。这已被证明是一个巨大的简化的假设。这些系统中没有需要有一个可从外部访问的写api位于所有，卡夫卡和数据库被用作记录和变化的系统，通过该日志流至适当的查询系统。写入由主办特定分区节点本地处理。这些节点盲目地抄写在日志中提供自己的商店的饲料。失败的节点可以通过重放日志上游恢复。
到这些系统依赖于日志的程度而变化。一个完全依赖系统可以利用日志数据分区，节点还原，再平衡，和一致性和数据传播的各个方面。在此设置中，实际的服务层实际上无外乎就是一种“缓存”的结构，使特定类型的处理与写入直接到日志中。
结束
如果你做了这么远，你知道的大部分东西我知道日志。
在这里，你可能想看看一些有趣的引用。
每个人似乎都使用不同的术语为同样的事情，所以这是一个有点难题的文献数据库连接到分布式系统的东西的各种企业软件阵营开源世界。不过，这里有在大方向上几个指针。
学术论文，系统，讲座，和博客：
- 很好地概述状态机和主备份复制
- PacificA上是Microsoft的实现基于日志的分布式存储系统的通用框架。
- 扳手 -不是每个人都喜欢为自己的日志逻辑的时间。谷歌的新数据库尝试使用物理时间和模式时钟的不确定性直接处理时间戳为一个范围漂移。
- Datanomic：解构数据库是由Rich希基，Clojure的创造者一个伟大的演讲，在他启动的数据库产品。
- 回滚恢复协议的调查消息传递系统。我发现这是一个非常有用的介绍容错和日志恢复数据库以外的实际应用。
- 无宣言 -我其实不太清楚什么是反应式编程的意思，但我认为这意味着同样的事情为“事件驱动”。这个环节没有太多的信息，但是这个类由Martin Odersky的（斯卡拉的名望）看起来facinating。
- Paxos的！
- 原纸是在这里。莱斯利·兰波特有一个有趣的历史的算法是如何在20世纪80年代创建，但没有公布直到1998年，因为评审不喜欢在纸上希腊比喻，他不想去改变它。
- 即使一旦原始论文发表它不很好地理解。兰波特再次尝试，这一次甚至包括一些对如何把它利用这些新发明的自动计算机使用“无趣的详细信息”。它仍然没有得到广泛的理解。
- 弗雷德·施耐德和巴特勒·兰普森每人给实际系统中应用的Paxos的更详细的介绍。
- 一些谷歌工程师总结他们的经验在丘比实施的Paxos。
- 其实，我发现所有的Paxos论文相当痛苦理解，但忠实地挣扎过。但你并不需要，因为这部影片由约翰Ousterhout加入（日志结构文件系统的名声！）将使这一切非常简单。不知何故这些共识算法通过绘制它们作为通信轮展开，而不是在一个纸张的静态呈现好得多呈现。讽刺的是，这段视频在试图表明的Paxos是很难理解的创建。
- 使用的Paxos构建可伸缩一致的数据存储：这是使用日志来构建数据存储，由君，共同作者之一凉爽的纸张也卡夫卡最早的工程师之一。
- Paxos的有竞争对手！其实每一种更紧密地映射了很多日志的实施，可能更适合于实际执行：
- Viewstamped复制芭芭拉Liskov的是一个早期的算法模型直接登录复制。
- 朱是由动物园管理员使用的算法。
- RAFT是一个更容易理解的一致性算法的一种尝试。该视频演示，同时是John Ousterhout，是伟大的。
- 你可以看到日志的作用在不同的实际分布式数据库的作用。
- 如果你发现自己的复制算法比较购物，本文可以帮您解决。
- 复制：理论与实践是一个伟大的书，收集在分布式系统上的复制一堆总结论文。许多章节的在线（例如1，4，5，6，7，8）。
- 流处理。这是一个有点过于宽泛总结，但这里有我喜欢的几件事情。
- 模型和数据流系统的问题：可能在这方面的早期研究的最好的概述。
- 高可用性算法分布式流处理
- 一对夫妇的随机系统论文：
- TelegraphCQ
- 极光
- NiagaraCQ
- 离散流：本文讨论了星火的流媒体系统。
- MillWheel是谷歌的流处理系统之一。
- 耐德：适时数据流系统
- 事件采购 -As据我可以告诉这基本上是说：“国家机器复制”的企业软件工程师的方式。有趣的是，同样的想法会在这样一个不同的上下文中再创造。事件采购似乎集中在较小的内存使用情况。这种方法的应用开发似乎是在日志与应用程序事件的发生“流处理”相结合。由于在处理大到足以需要大规模我专注于流处理作为一个单独的基础设施基本数据分区这成为相当不平凡。
- 变更数据捕获 -there大约是获取数据从数据库的小行业，这是数据提取的最登录友好的风格。
- 企业应用集成似乎是，当你有什么是关闭的，现成的企业软件如客户关系管理和供应链管理软件的集合解决数据集成问题。
- 复杂事件处理（CEP） ：相当肯定没有人知道这意味着什么或如何真正从流处理不同。所不同的似乎是，重点是无序的溪流和事件过滤和检测，而不是聚集，但是这在我看来是没有差别的区别。我认为，任何制度，善于应该善于另一回事。
- 企业服务总线 -我想企业服务总线的概念是非常相似的一些我已经围绕数据集成所描述的想法。这种想法似乎一直在企业软件社区比较成功的是网络管理人员或分布式数据基础设施的人群中大多是未知的。
- 卡夫卡是“日志作为服务”项目，该项目是基础，很多这个职位。
- Bookeeper和海德薇包括另一个开源“日志作为服务”。他们似乎更针对数据系统的内部，然后在事件数据。
- 数据总线是提供一个日志状覆盖数据库表的系统。
- 阿卡是斯卡拉演员的框架。它有一个加上，eventsourced，提供了持久性和日志。
- Samza是一个流处理框架，我们在LinkedIn工作。它使用在这篇文章中有很多的想法以及与卡夫卡整合作为底层的日志。
- 风暴是流行的流处理架构，与卡夫卡很好地结合。
- 火花流是一个流处理框架，是一部分火花。
- Summingbird是在风暴或Hadoop之上的一层，提供了一个方便的计算抽象。
我尽量保持在这个区域，所以如果你知道一些事情我已经离开了，让我知道。
我离开你这个消息：
1884
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
