From 6e3186ebce6a014cb45cbf4fc34feadef25e01cc Mon Sep 17 00:00:00 2001 From: Jerry Lee Date: Thu, 20 Aug 2015 22:25:52 +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 --- .../part2-data-integration.md | 2 -- .../part4-system-building.md | 19 +++++++++---------- 2 files changed, 9 insertions(+), 12 deletions(-) diff --git a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part2-data-integration.md b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part2-data-integration.md index 77be5cf..850cdd1 100644 --- a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part2-data-integration.md +++ b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part2-data-integration.md @@ -206,8 +206,6 @@ `ETL`与数据仓库的关系 ------------------------- -Having this central location that contains a clean copy of all your data is a hugely valuable asset for data-intensive analysis and processing - 我们再来聊聊数据仓库。数据仓库旨在包含支撑数据分析的规整的集成的结构化数据。 这是一个非常好的理念。对不了解数据仓库概念的人来说，数据仓库的用法是： 周期性的从源数据库抽取数据，把它们转化为可理解的形式，然后把它导入中心数据仓库。 diff --git a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part4-system-building.md b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part4-system-building.md index 45521fe..d460ba8 100644 --- a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part4-system-building.md +++ b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part4-system-building.md @@ -6,7 +6,7 @@ 最后我要讨论的是在线数据系统设计中日志的角色。 -日志服务在分布式数据库中服务于数据流 可以类比 在大型组织机构中服务于数据集成。 +日志服务在分布式数据库中服务于数据流 可以类比 日志服务在大型组织机构中服务于数据集成。 在这两个应用场景中，日志要解决的问题 都是 数据流、一致性和可恢复性。 如果组织不是一个很复杂的分布式数据系统呢，它究竟是什么？ @@ -23,8 +23,8 @@ 即使是在关系数据库的鼎盛时期，组织里就有种类繁多的关系数据库！ 因为大型机，所有的数据都存储在相同的位置，所以可能并没有真正的数据集成。 有很多推动力要把数据分离到多个系统：数据伸缩性、地理地域、安全性和性能隔离是最常见的。 -这些问题可以通过一个好系统来解决： -比如组织使用单个`Hadoop`来保存全部数据来服务大量各式各样的客户，这样做是可能的。 +这些问题可以通过一个好的系统来解决： +比如组织使用单个`Hadoop`保存所有数据来服务大量各式各样的客户，这样做是可能的。 所以处理的数据向分布式系统变迁的过程中，已经有了个可能的简单方法： 把大量的不同系统的小实例合到少数的大集群中。 @@ -44,7 +44,7 @@ 只要现状不变，为了能够使用数据，数据集成问题将仍会最核心事情之一。 如果是这样，用于集成数据的外部日志将会非常的重要。 -第二种可能性是一个新统一合并的系统（`re-consolidation`），这一个系统具备足够的通用性，逐步把所有不同的功能合并成单个超极系统。 +第二种可能性是一个统一合并的系统（`re-consolidation`），这个系统具备足够的通用性，逐步把所有不同的功能合并成单个超极系统。 这个超级系统表面看起来类似关系数据库，但在组织中使用方式会非常不一样，因为只能用一个大系统而不是无数个小系统。 在这样的世界里，除了系统自身的内部，不存在真正的数据集成问题。 我觉得，因为建设这样的系统的实际困难，使这个情况不太可能发生。 @@ -74,9 +74,9 @@ 提供外部日志的系统允许各个系统抛弃很多各自的复杂性，依靠共享的日志。在我看来，日志可以做到以下事情： -- 通过对节点的并发更新的排序处理，处理了数据一致性（无论在及时还是最终情况下） +- 通过对节点的并发更新的排序处理，处理了数据一致性（无论即时的还是最终的一致） - 提供节点之间的数据复制 -- 为写入者（`writer`）提供『提交（`commit`）』语义（仅当写入数据确保不会丢失时才会收到完成确认（`acknowledge`）） +- 为写入者提供『提交（`commit`）』语义（仅当写入数据确保不会丢失时才会收到完成确认（`acknowledge`）） - 为系统提供外部的数据订阅 - 对于丢失数据的失败了的复本，提供恢复或是启动一个新复本的能力 - 调整节点间的数据平衡 @@ -90,22 +90,21 @@ 下面我们来看下系统是如何工作的。 系统被分为两个逻辑部分：日志和服务层。日志按顺序捕获状态变化。 -服务节点存储索引提供查询服务需要的所有信息（比如键值存储的索引可能会类似`BTree`或`SSTable`，搜索系统可能用的是反向索引（`inverted index`））。 +服务节点存储索引提供查询服务需要的所有信息（比如键值存储的索引可能会类似`BTree`或`SSTable`，搜索系统可能用的是倒排索引（`inverted index`））。 写入操作可以直接进入日志，尽管可能经过服务层的代理。 在写入日志的时候会生成逻辑时间戳（称为日志中的索引），如果系统是分区的，我假定是会分区， 那么日志和服务节点会包含相同分区个数，尽管两者的机器台数可能相差很多。 服务节点订阅日志，并按照日志存储的顺序尽快把日志写到它的本地索引中。 -客户端只要在查询语句中提供某次写入操作的时间戳，就可以有从任何节点『读到该次写入』的语义 —— -客户端只要在查询语句中提供对应的写入器的时间戳，它就可以从任何节点中获取”读写“语义。 +客户端只要在查询语句中提供某次写入操作的时间戳，就可以有从任何节点『读到该次写入』的语义（`read-your-write semantics`） —— 服务节点收到该查询语句后，会将其中的时间戳与自身索引的位置比较， 如果必要，服务节点会延迟请求直到它的索引至少已经跟上那个时间戳，以避免提供的是旧数据。 服务节点可能会或可能不会需要感知`master`身份或是当选`leader`。 对很多简单的使用场景，服务节点集群可以完全无需`leader`，因为日志是正确真实的信息源。 -分布式系统所需要处理的一件比较复杂的事是恢复失败节点和在结点之间移动分区。 +分布式系统所需要处理的一件比较复杂的事是 恢复失败节点 和 在结点之间移动分区。 典型的做法是仅保留一个固定窗口的数据，并把这个数据和分区中存储数据的一个快照关联。 另一个相同效果的做法是，让日志保留数据的完整拷贝，并[对日志做垃圾回收](https://cwiki.apache.org/confluence/display/KAFKA/Log+Compaction)。 这把大量的复杂性从特定于系统的系统服务层移到了通用的日志中。