From 0ac0ad6449047906bd05d755d69182c7c62f2e24 Mon Sep 17 00:00:00 2001 From: Jerry Lee Date: Fri, 21 Aug 2015 18:51:26 +0800 Subject: [PATCH] =?UTF-8?q?=E5=AE=A1=E6=A0=A1?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../the-end.md | 60 +++++++++---------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/the-end.md b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/the-end.md index 2f9c51e..594b87d 100644 --- a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/the-end.md +++ b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/the-end.md @@ -12,59 +12,59 @@ - 关于[状态机](http://www.cs.cornell.edu/fbs/publications/smsurvey.pdf%E2%80%8E)和[主备份](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.20.5896)复制的概述。 - [`PacificA`](http://research.microsoft.com/apps/pubs/default.aspx?id=66814)是实施微软基于日志的分布式存储系统的通用架构。 -- [`Spanner`](http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/spanner-osdi2012.pdf)-并不是每个人都支持把逻辑时间用于他们的日志，Google最新的数据库就尝试使用物理时间，并通过把时间戳直接做为区间来直接建时钟迁移的不确定性。 +- [`Spanner`](http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/spanner-osdi2012.pdf) —— 并不是每个人都支持把逻辑时间用于他们的日志，`Google`最新的数据库就尝试使用物理时间，并通过把时间戳直接做为区间来直接建时钟迁移的不确定性。 - [`Datanomic`](http://www.datomic.com/)：[解构数据库](https://www.youtube.com/watch?v=Cym4TZwTCNU)是**_Rich Hickey_**（`Clojure`的创建者）在它的首个数据库产品中的的重要陈述之一。 - [在消息传递系统中回滚恢复协议的调查](http://www.cs.utexas.edu/~lorenzo/papers/SurveyFinal.pdf)。 我发现这是有关容错处理和通过日志在数据库之外完成恢复的实际应用的很不错的介绍。 - [Reactive Manifesto](http://www.reactivemanifesto.org/) —— - 我其实并不清楚反应编程（`reactive programming`）的确切涵义，但是我想它和『事件驱动』指的是同一件事。 + 我其实并不清楚反应式编程（`reactive programming`）的确切涵义，但是我想它和『事件驱动』指的是同一件事。 这个链接并没有太多的讯息，但**_Martin Odersky_**（`Scala`名家）讲授的[这个课程](https://www.coursera.org/course/reactive)是很有吸引力的。 - `Paxos`! 1. 原论文在[这里](http://research.microsoft.com/en-us/um/people/lamport/pubs/lamport-paxos.pdf)。 **_Leslie Lamport_** 有一个有趣的历史：在80年代算法是如何发现的，但是直到1998年才发表了，因为评审组不喜欢论文中的希腊寓言，而作者又不愿修改。 2. 甚至于论文发布以后，它还是不被人们理解。**_Lamport_** 再次尝试，这次它包含了一些并不有趣的小细节，这些细节是关于如何使用这些新式的自动化的计算机的。 它仍然没有得到广泛的认可。 - 3. [Fred Schneider](http://www.cs.cornell.edu/fbs/publications/SMSurvey.pdf)和[Butler Lampson](http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying)分别给出了更多细节关于在实时系统中如何应用Paxos. - 4. 一些Google的工程师总结了他们在Chubby中实施Paxos的[经验](http://www.cs.utexas.edu/users/lorenzo/corsi/cs380d/papers/paper2-1.pdf)。 - 5. 我发现所有关于Paxos的论文理解起来很痛苦，但是值得我们费大力气弄懂。你不必忍受这样的痛苦了，因为日志结构的文件系统的大师[John Ousterhout](http://www.stanford.edu/~ouster/cgi-bin/papers/lfs.pdf)的这个[视频](https://www.youtube.com/watch?v=JEpsBg0AO6o)让这一切变得相当的容易。这些一致性算法用展开的通信图表述的更好，而不是在论文中通过静态的描述来说明。颇为讽刺的是，这个视频录制的初衷是告诉人们Paxos很难理解。 - 6. [使用Paxos来构造规模一致的数据存储](http://arxiv.org/pdf/1103.2408.pdf)。这是一篇很棒的介绍使用日志来构造数据存储的文章，Jun是文章的共同作者之一，他也是Kafka最早期的工程师之一。 -- Paxos有很多的竞争者。如下诸项可以更进一步的映射到日志的实施，更适合于实用性的实施。 - 1. 由Barbara Liskov提出的[视图戳复现](http://pmg.csail.mit.edu/papers/vr-revisited.pdf)是直接进行日志复现建模的较早的算法。 - 2. [Zab](http://www.stanford.edu/class/cs347/reading/zab.pdf)是Zookeeper所使用的算法。 - 3. [RAFT](https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf)是易于理解的一致性算法之一。由John Ousterhout讲授的这个[视频](https://www.youtube.com/watch?v=YbZ3zDzDnrw)非常的棒。 + 3. [**_Fred Schneider_**](http://www.cs.cornell.edu/fbs/publications/SMSurvey.pdf)和[**_Butler Lampson_**](http://research.microsoft.com/en-us/um/people/blampson/58-consensus/Abstract.html)分别给出了更多细节关于在实时系统中如何应用`Paxos`。 + 4. 一些`Google`的工程师总结了他们在`Chubby`中实施`Paxos`的[经验](http://www.cs.utexas.edu/users/lorenzo/corsi/cs380d/papers/paper2-1.pdf)。 + 5. 我发现所有关于`Paxos`的论文理解起来很痛苦，但是值得我们费大力气弄懂。你不必忍受这样的痛苦了，因为日志结构的文件系统的大师[**_John Ousterhout_**](http://www.stanford.edu/~ouster/cgi-bin/papers/lfs.pdf)的[这个视频](https://www.youtube.com/watch?v=JEpsBg0AO6o) 让这一切变得相当的容易。这些一致性算法用展开的通信图表述的更好，而不是在论文中通过静态的描述来说明。颇为讽刺的是，这个视频录制的初衷是告诉人们`Paxos`很难理解。 + 6. [使用`Paxos`来构造规模一致的数据存储](http://arxiv.org/pdf/1103.2408.pdf)。这是一篇很棒的介绍使用日志来构造数据存储的文章，**_Jun_** 是文章的共同作者之一，他也是`Kafka`最早期的工程师之一。 +- `Paxos`有很多的竞争者。如下诸项可以更进一步的映射到日志的实施，更适合于实用性的实施。 + 1. 由**_Barbara Liskov_**提出的[视图戳复现](http://pmg.csail.mit.edu/papers/vr-revisited.pdf)是直接进行日志复现建模的较早的算法。 + 2. [`Zab`](http://www.stanford.edu/class/cs347/reading/zab.pdf)是`Zookeeper`所使用的算法。 + 3. [`RAFT`](https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf)是易于理解的一致性算法之一。由**_John Ousterhout_**讲授的这个[视频](https://www.youtube.com/watch?v=YbZ3zDzDnrw)非常的棒。 - 你可以的看到在不同的实时分布式数据库中动作日志角色： - 1. [PNUTS](https://www.youtube.com/watch?v=YbZ3zDzDnrw)是探索在大规模的传统的分布式数据库系统中实施以日志为中心设计理念的系统。 - 2. [Hbase](http://hbase.apache.org/)和Bigtable都是在目前的数据库系统中使用日志的样例。 - 3. LinkedIn自己的分布式数据库[Espresso](http://www.slideshare.net/amywtang/espresso-20952131)和PNUTs一样，使用日志来复现，但有一个小的差异是它使用自己底层的表做为日志的来源。 + 1. [`PNUTS`](https://www.youtube.com/watch?v=YbZ3zDzDnrw)是探索在大规模的传统的分布式数据库系统中实施以日志为中心设计理念的系统。 + 2. [`Hbase`](http://hbase.apache.org/)和`Bigtable`都是在目前的数据库系统中使用日志的样例。 + 3. `LinkedIn`自己的分布式数据库[`Espresso`](http://www.slideshare.net/amywtang/espresso-20952131)和`PNUTs`一样，使用日志来复现，但有一个小的差异是它使用自己底层的表做为日志的来源。 - 如果你正在做一致性算法选型，[这篇论文](http://arxiv.org/abs/1309.5671)会对你所有帮助。 - [复现：理论与实践](http://www.amazon.com/Replication-Practice-Lecture-Computer-Theoretical/dp/3642112935)，这是收录了分布式系统一致性的大量论文的一本巨著。网上有该书的诸多章节（[1](http://disi.unitn.it/~montreso/ds/papers/replication.pdf)，[4](http://research.microsoft.com/en-us/people/aguilera/stumbling-chapter.pdf)，[5](http://www.distributed-systems.net/papers/2010.verita.pdf)，[6](http://www.cs.cornell.edu/ken/history.pdf)，[7](http://www.pmg.csail.mit.edu/papers/vr-to-bft.pdf)，[8](http://engineering.linkedin.com/distributed-systems/www.cs.cornell.edu/fbs/publications/TrustSurveyTR.pdf)）。 - 流处理：这个话题要总结的内容过于宽泛，但还是有几件我所关注的要提一下： - 1. [TelegraphCQ](http://db.cs.berkeley.edu/papers/cidr03-tcq.pdf) - 2. [Aurora](http://cs.brown.edu/research/aurora/vldb03_journal.pdf) - 3. [NiagaraCQ](http://research.cs.wisc.edu/niagara/papers/NiagaraCQ.pdf) - 4. [离散流](http://www.cs.berkeley.edu/~matei/papers/2012/hotcloud_spark_streaming.pdf)：这篇论文讨论了Spark的流式系统。 - 5. [MillWheel](http://research.google.com/pubs/pub41378.html) 它是Google的流处理系统之一。 - 6. [Naiad:一个实时数据流系统](http://research.microsoft.com/apps/pubs/?id=201100) + 1. [`TelegraphCQ`](http://db.cs.berkeley.edu/papers/cidr03-tcq.pdf) + 2. [`Aurora`](http://cs.brown.edu/research/aurora/vldb03_journal.pdf) + 3. [`NiagaraCQ`](http://research.cs.wisc.edu/niagara/papers/NiagaraCQ.pdf) + 4. [离散流](http://www.cs.berkeley.edu/~matei/papers/2012/hotcloud_spark_streaming.pdf)：这篇论文讨论了`Spark`的流式系统。 + 5. [`MillWheel`](http://research.google.com/pubs/pub41378.html) 它是`Google`的流处理系统之一。 + 6. [`Naiad`：一个实时数据流系统](http://research.microsoft.com/apps/pubs/?id=201100) 7. [在数据流系统中建模和相关事件](http://infolab.usc.edu/csci599/Fall2002/paper/DML2_streams-issues.pdf)：它可能是研究这一领域的最佳概述之一。 8. [分布处式流处理的高可用性算法](http://cs.brown.edu/research/aurora/hwang.icde05.ha.pdf)。 9. 随机系统的一些论文： -企业级软件存在着同样的问题，只是名称不同，或者规模较小，或者是XML格式的。哈哈，开个玩笑。 +企业级软件存在着同样的问题，只是名称不同，或者规模较小，或者是`XML`格式的。哈哈，开个玩笑。 -- [事件驱动](http://cs.brown.edu/research/aurora/hwang.icde05.ha.pdf) —— 据我所知：它就是企业级应用的工程师们常说的“状态机的复现”。有趣的是同样的理念会用在如此迥异的场景中。事件驱动关注的是小的、内存中的使用场景。这种机制在应用开发中看起来是把发生在日志事件中的“流处理”和应用关联起来。因此变得不那么琐碎：当处理的规模大到需要数据分片时，我关注的是流处理作为独立的首要的基础设施。 +- [事件驱动](http://cs.brown.edu/research/aurora/hwang.icde05.ha.pdf) —— 据我所知：它就是企业级应用的工程师们常说的『状态机的复现』。有趣的是同样的理念会用在如此迥异的场景中。事件驱动关注的是小的、内存中的使用场景。这种机制在应用开发中看起来是把发生在日志事件中的『流处理』和应用关联起来。因此变得不那么琐碎：当处理的规模大到需要数据分片时，我关注的是流处理作为独立的首要的基础设施。 - [变更数据捕获](http://en.wikipedia.org/wiki/Change_data_capture) —— 在数据库之外会有些对于数据的舍入处理，这些处理绝大多数都是日志友好的数据扩展。 -- [企业级应用集成](http://en.wikipedia.org/wiki/Enterprise_application_integration)，当你有一些现成的类似客户类系管理CRM和供应链管理SCM的软件时，它似乎可以解决数据集成的问题。 -- [复杂事件处理（CEP）](http://en.wikipedia.org/wiki/Complex_event_processing)没有人知道它的确切涵义或者它与流处理有什么不同。这些差异看起来集中在无序流和事件过滤、发现或者聚合上，但是依我之见，差别并不明显。我认为每个系统都有自己的优势。 -- [企业服务总线（ESB）](http://en.wikipedia.org/wiki/Enterprise_service_bus) —— 我认为企业服务总线的概念类似于我所描述的数据集成。在企业级软件社区中这个理念取得了一定程度的成功，对于从事网络和分布式基础架构的工程师们这个概念还是很陌生的。 +- [企业级应用集成](http://en.wikipedia.org/wiki/Enterprise_application_integration)，当你有一些现成的类似客户类系管理`CRM`和供应链管理`SCM`的软件时，它似乎可以解决数据集成的问题。 +- [复杂事件处理（`CEP`）](http://en.wikipedia.org/wiki/Complex_event_processing)没有人知道它的确切涵义或者它与流处理有什么不同。这些差异看起来集中在无序流和事件过滤、发现或者聚合上，但是依我之见，差别并不明显。我认为每个系统都有自己的优势。 +- [企业服务总线（`ESB`）](http://en.wikipedia.org/wiki/Enterprise_service_bus) —— 我认为企业服务总线的概念类似于我所描述的数据集成。在企业级软件社区中这个理念取得了一定程度的成功，对于从事网络和分布式基础架构的工程师们这个概念还是很陌生的。 一些相关的开源软件： -- [Kafka](http://kafka.apache.org/)是把日志作为服务的一个项目，它是后边所列各项的基础。 -- [Bookeeper](http://zookeeper.apache.org/bookkeeper/) 和[Hedwig](http://zookeeper.apache.org/bookkeeper/) 另外的两个开源的“把日志作为服务”的项目。它们更关注的是数据库系统内部构件而不是事件数据。 -- [Databus](https://github.com/linkedin/databus)是提供类似日志的数据库表的覆盖层的系统。 -- [Akka](http://akka.io/) 是用于Scala的动作者架构。它有一个[事件驱动](https://github.com/eligosource/eventsourced)的插件，它提供持久化和记录。 -- [Samza](http://storm-project.net/)是我们在LinkedIn中用到的流处理框架，它用到了本文论述的诸多理念，同时与Kafka集成来作为底层的日志。 -- [Storm](http://storm-project.net/)是广泛使用的可以很好的与Kafka集成的流处理框架之一。 +- [`Kafka`](http://kafka.apache.org/)是把日志作为服务的一个项目，它是后边所列各项的基础。 +- [`Bookeeper`](http://zookeeper.apache.org/bookkeeper/) 和[`Hedwig`](http://zookeeper.apache.org/bookkeeper/) 另外的两个开源的『把日志作为服务』的项目。它们更关注的是数据库系统内部构件而不是事件数据。 +- [`Databus`](https://github.com/linkedin/databus)是提供类似日志的数据库表的覆盖层的系统。 +- [`Akka`](http://akka.io/) 是用于`Scala`的`Actor`框架。它有一个[事件驱动](https://github.com/eligosource/eventsourced)的插件，它提供持久化和记录。 +- [`Samza`](http://storm-project.net/)是我们在`LinkedIn`中用到的流处理框架，它用到了本文论述的诸多理念，同时与`Kafka`集成来作为底层的日志。 +- [`Storm`](http://storm-project.net/)是广泛使用的可以很好的与`Kafka`集成的流处理框架之一。 - [`Spark Streaming`](http://spark.incubator.apache.org/docs/0.7.3/streaming-programming-guide.html)一个流处理框架，它是[`Spark`](http://spark.incubator.apache.org/)的一部分。 - [`Summingbird`](https://blog.twitter.com/2013/streaming-mapreduce-with-summingbird)是在`Storm`或`Hadoop`之上的一层，它提供了便洁的计算摘要。