The Log: What every software engineer should know about real-time data′s unifying abstraction（一）
前言
从中我学习到的最有益的事情是我们构建的许多东西的核心里都包含一个简单的概念：日志，有时候也称作预先写入日志（write-ahead logs）、提交日志（commit logs）或事务日志（transaction logs）。日志几乎和计算机形影不离，而且它还是许多分布式数据系统和实时应用结构的核心。
不懂得日志，你就不可能真正懂得数据库、NoSQL存储、键值存储、数据复制（replication）、Paxos、Hadoop、版本控制等几乎所有软件系统；然而，大多数软件工程师并不是很熟悉。我有意于改变这个现状。本文中，我将带你浏览有关日志需要了解的一切，包括日志是什么，如何在数据集成、实时处理和系统构建中使用日志等。
Part 1 何为日志
日志似乎是一种简单得不能再简单的存储抽象，它只能追加（append-only）、完全按时序（totally-ordered）的记录序列。日志看起来如下：
日志总向末尾添加记录，并且可以从左到右顺序读取日志记录。每一条记录都指定了一个唯一的顺序的日志记录编号。
日志记录的排序（ordering）是由“时间”来确定的，因为左边的日志记录总比右边的要早。日志记录编号可以视为这条日志记录的“时间戳”。在一开始就把这种次序说成是按时间排序显得有点怪异，但是这引入了一种可以将时间与物理时钟解耦的便利特性。这一特性在运行多个分布式系统时至关重要。
本文并不关注具体的日志记录的内容和格式。另外需要说明，由于存储空间总会耗尽，日志不可能一直添加记录。稍后我将会提到这个问题。
日志并不是完全不同于文件（file）或者数据表（table）的。文件由一系列字节组成，表由一系列记录组成，而日志实际上只是一种按照时间顺序存储记录的数据表或者文件。
此时，你可能奇怪为什么要讨论这么简单的概念？只能追加的有序的日志记录究竟又是怎样与数据系统生产关系的？答案是日志有其特定的应用目标：日志记录了什么时间发生了什么事情。在许多方面，这是分布式数据系统要解决的问题的真正核心。
不过在进行更深入的讨论前，需要澄清一些容易混淆的概念。每个程序员都熟悉另一种日志记录的定义——软件使用 syslog 或者 log4j 写入到本地文件里的无结构的错误信息或者追踪信息。为了区分，这种情形的日志称为应用日志记录（application logging）。应用日志记录是本文日志概念的一种退化。两者最大的区别是：文本日志主要用来方便人去阅读，而构建我所说的日志（journal）或者数据日志（data logs）要用于程序的访问。
（实际上，如果你深入地思考一下，会觉得人去阅读某个机器上的日志这样的想法有些过时了。当涉及很多服务和服务器时，这样的做法很快就变得难以管理，我们的目的很快就变成输入查询和输出用于理解多台机器的行为的图表，因此，文件中的文字文本肯定不如本文所描述的结构化日志更合适。）
数据库日志
我不知道日志概念的起源——可能就像二分查找（binary search）一样，发明者觉得太简单了以至于不认为是一项发明。早在 IBM 的 System R 出现时候日志就出现了。在数据库里的用法是在崩溃的时候用它来保持各种数据结构和索引的同步。为了保证操作的原子性（atomic）和持久性（durable)，在对数据库维护的所有各种数据结构做更改之前，数据库会把要做的更改操作的信息写入日志。日志记录了发生了什么，而每个表或者索引都是更改历史中的一个投影。由于日志是立即持久化的，发生崩溃时，可以作为恢复其他所有持久化结构的可靠来源。
随着时间的推移，日志的用途从ACID的实现细节成长为数据库间复制数据的一种方法。结果证明，发生在数据库上的更改序列即是与远程副本数据库（replica database）保持同步所需的操作。Oracle、MySQL 和PostgreSQL都包括一个日志传送协议（log shipping protocol），传输日志给作为备库（slave）的复本（replica）数据库。Oracle还把日志产品化为一个通用的数据订阅机制，为非Oracle数据订阅用户提供了XStreams和GoldenGate，在MySQL和PostgreSQL中类似设施是许多数据架构的关键组件。
正是由于这样的起源，机器可识别的日志的概念主要都被局限在数据库的内部。日志作为做数据订阅机制的用法似乎是偶然出现的。但这正是支持各种的消息传输、数据流和实时数据处理的理想抽象。
分布式系统日志
日志解决了两个问题：更改动作的排序和数据的分发，这两个问题在分布式数据系统中尤为重要。协商达成一致的更改动作的顺序（或者保持各个子系统原本做法但进行数据拷贝，虽然数据拷贝存在副作用）是分布式系统设计的核心问题之一。
以日志为中心实现分布式系统是受到了一个简单的经验常识的启发，我称这个经验常识称为状态机复制原理（State Machine Replication Principle）：
如果两个相同的、确定性的进程从同一状态开始，并且以相同的顺序获得相同的输入，那么这两个进程将会生成相同的输出，并且结束时状态相同。
也许有些晦涩，所以让我们更深入地探讨来弄懂它的真正含义。
确定性（deterministic）意味着处理过程与时间无关的，而且任何其他带外输入（out of band input）不会影响到处理结果。例如，如果一个程序的输出会受到线程执行的具体顺序影响，或者受到 gettimeofday 调用、或者其他一些非重复性事件的影响，那么一般认为该程序是非确定性的。
进程状态是指进程保存在机器上的任何数据，在进程处理结束的时候，这些数据要么保存在内存里，要么保存在磁盘上。
当碰到以相同的顺序输入相同的内容的情况时，应该引起注意，此处要引入日志。可以确定的是，给两段确定性代码相同的日志输入，它们应该会生产相同的输出。
应用到分布式计算中这一原理就相当明显了。你可以把用多台机器执行相同事情的问题化简为实现用分布式的一致性日志作为处理输入的问题。这里日志的目的是把所有非确定性的东西排除在输入流之外，以确保处理这些输入的各复本（replica）保持同步。
当你理解了这个以后，状态机复制原理就不再复杂或深奥了：它基本上相当于“确定性的处理过程就是确定性的”。尽管如此，我仍认为它是分布式系统设计中一个极为通用的工具。
这种方案的一个美妙之处就在于：索引日志的时间戳就可视作用于保持副本状态的时钟——可以仅用已处理的最大日志记录的时间戳这一个数字来描述一个副本。日志中的时间戳一一对应了副本的完整状态。
根据写进日志的内容不同，该原理有不同的应用方式。例如记录一个服务的请求，或者服务从请求到响应的状态变化，或者它执行命令的转换。理论上来说，我们甚至可以为每一个副本记录一系列要执行的机器指令或者调用的方法名和参数。只要两个进程用相同的方式处理这些输入，这些副本进程就会保持一致性。
不同人群认为日志有不同的用法。数据库工作者通常区分物理日志（physical logging）和逻辑日志（logical logging）。物理日志记录了每一行被改变的内容。逻辑日志并非记录改变的行，而是那些引起行的内容改变的 SQL 语句（insert、update、delete）。
分布式系统可粗略分为处理和复制两类方法。状态机模型（state machine model）常为被称为主主模型（active-active mode），即记录输入请求，各副本处理单个请求。细微更改后可得到主备模型（primary-backup model），就是选出一个副本做为 leader，并允许它按照请求到达的时间来进行处理并从处理过程中输出记录其状态改变的日志。其他的副本按照 leader 状态改变的顺序而应用那些改变，这样他们之间达到同步，并能够在 leader 失败的时候接替 leader 的工作。
为了理解两种方式的差异，我们来看一个不太严谨的例子。假定有一个算法服务的副本，维护一个独立的数字作为它的状态（初始值为0），且可对这个值做加法或乘法。主主方式会输出进行的变换的日志，比如“+1”、“*2”等。每一个副本都会应用这些变换，从而得到同样的结果。主备动方式会有一个独立的主体执行这些变换并输出结果的日志，比如“1”、“3”、“6”等。这个例子也清楚的展示了为什么说顺序是保证各副本间一致性的关键：加法和乘法的顺序的改变将会导致不同的结果。
分布式日志可以理解为一致性（consensus）问题模型的数据结构。因为日志代表了后续追加值的一系列决策。你需要重新审视 Paxos 算法簇，尽管日志模块是他们最常见的应用。在 Paxos 算法中，它通常通过使用称之为多 Paxos 的协议，这种协议将日志建模为一系列的问题，在日志中每个问题都有对应的部分。在ZAB、RAFT等其它的协议中，日志的作用尤为突出，它直接对维护分布式的、一致性的日志的问题建模。
我怀疑的是，我们就历史发展的观点是有偏差的，可能是由于过去的几十年中，分布式计算的理论远超过了其实际应用。在现实中，共识的问题是有点太简单了。计算机系统很少需要决定单个值，他们几乎总是处理成序列的请求。这样的记录，而不是一个简单的单值寄存器，自然是更加抽象。
此外，专注于算法掩盖了抽象系统需要的底层的日志。我怀疑，我们最终会把日志中更注重作为一个商品化的基石，不论其是否以同样的方式实施的，我们经常谈论一个哈希表而不是纠结我们得到是不是具体某个细节的哈希表，例如线性或者带有什么什么其它变体哈希表。日志将成为一种大众化的接口，为大多数算法和其实现提升提供最好的保证和最佳的性能。
变更日志101：表与事件的二相性
我们来继续聊数据库。数据库中存在着大量变更日志（changelog）和表之间的二相性（duality）。这些日志类似借贷清单和银行流水，而数据表就是当前的盈亏表。如果你有大量的变更日志，你就可以使用这些变更用以创建捕获当前状态的表。这张表将记录每个关键点（日志中一个特别的时间点）的状态信息。这就是为什么日志是非常基本的数据结构的意义所在：日志可用来创建基本表，也可以用来创建各类衍生表。（同时意味着可以存储非关系型的对象。）
这个过程也是可逆的：如果你对一张表进行更新，你可以记录这些变更，并把所有更新的变更日志发布到表的状态信息中。这些变更日志正是你所需要的支持准实时的复制。基于此，你就可以清楚的理解表与事件的二象性：表支持了静态数据，而日志记录了变更。日志的魅力就在于它是变更的完整记录，它不仅仅包含了表的最终版本的内容，而且可以用于重建任何存在过其它版本。事实上，日志可以看作是表每个历史状态的一系列备份。
你可能会联想到源代码的版本管理（version control）。它和数据库之间有密切关系。版本管理解决了一个大家非常熟悉的问题，那就是什么是分布式数据系统需要解决的——时时刻刻在变化着的分布式管理。版本管理系统通常以补丁的发布为基础，这实际上可能是一个日志。您可以直接对当前类似于表中的代码做出快照互动。你会注意到，与其他分布式状态化系统类似，版本控制系统当你更新时会复制日志，你希望的只是更新补丁并将它们应用到你的当前快照中。
最近，有人从一家销售日志数据库的公司 Datomic 得到了一些想法。这些想法使他们对如何在他们的系统应用这些想法有了开阔的认识。当然这些想法不是只针对这个系统，他们会成为十多年分布式系统和数据库文献的一部分。
这可能似乎有点过于理想化，但是别沮丧！后面会很快实现。
后续内容
在这篇文章的其余部分，我将重点讲述日志除了可用在分布式计算或者抽象分布式计算模型内部之外，还可用在哪些方面。其中包括：
- 数据集成-让机构的全部存储和处理系统里的所有数据很容易地得到访问。
- 实时数据处理-计算生成的数据流。
- 分布式系统设计-实际应用的系统是如何通过使用集中式日志来简化设计的。
所有这些用法都是通过把日志用做单独服务来实现的。
以上场景中，日志的好处都来自日志所能提供的简单功能：生成持久化的可重放的历史记录。令人意外的是，能让多台机器以确定性的方式按各自的速度重放历史记录的能力正是这些问题的核心。
Part 2 数据集成
首先说明数据集成的概念和为什么我认为这很重要，接着我们再来看看它是如何和日志建立关系的。
数据集成是指使一个组织的所有数据对这个组织的所有的服务和系统可用。
我暂时没有找到比数据集成更好更常见的用语，一般更为熟知的概念 ETL（extraction-transformation-loading）只是数据集成的有限子集——主要在关系型数据仓库的场景。但我描述的东西很大程度上可以理解为，将ETL推广至覆盖实时系统和处理流程。
你一定不会听到数据集成就兴趣盎然地屏住呼吸，并且天花乱坠地想到大数据的概念，尽管如此，我相信这个陈词滥调的让数据可用的问题是组织可以关注的更有价值的事情之一。
对数据的高效使用遵循马斯洛需求层次理论。金字塔的基础部分包括捕获所有相关数据，能够将它们全部放到适当的处理环境（那个环境应该是一个奇妙的实时查询系统，或者仅仅是文本文件和 python 脚本）。这些数据需要以统一的方式建模，这样就可以方便读取和数据处理。一旦这些以统一的方式捕获数据的基本需求得到满足，那么在基础设施上以不同方法处理这些数据就变得理所当然——映射化简（MapReduce），实时查询系统，等等。
但显然值得注意的是：如果没有可靠的、完整的数据流，Hadoop 集群只不过是个格外昂贵而且安装麻烦的供暖器。一旦数据和处理，大家的关注点就会转移到良好的数据模型和一致且易于理解的语义这些更精致的问题上来。最后，人们才会关注更加高级的处理——更好的可视化、报表以及处理和预测算法。
以我的经验，大多数机构在数据金字塔的底部存在巨大的漏洞——它们缺乏可靠的、完整的数据流——而是打算直接跳到高级数据模型技术上。这样做完全是反着来做的。
因此，问题是我们如何构建通过机构内所有数据系统的可靠的数据流？
数据集成的两个难题
两种趋势使数据集成变得更困难。
事件数据管道
第一个趋势是增长的事件数据（event data）。事件数据记录的是发生的事情，而不是存在的东西。在 Web 系统中，这就意味着用户活动日志，还有为了可靠的操作以及监控数据中心的机器的目的，所需要记录的机器级别的事件和统计数字。人们倾向称它们为“日志数据”，因为它们经常被写到应用的日志中，但是这混淆了形式与功能。这种数据位于现代 Web 的中心：归根结底，Google 的财富来自于建立在点击和展示上的相关性管道（relevance pipeline），而这些点击和展示正是事件。
这些东西并不是仅限于网络公司，只是网络公司已经完全数字化，所以它们更容易用设备记录。财务数据一直是面向事件的。RFID（无线射频识别）将这种跟踪能力赋予物理对象。我认为这种趋势仍将继续，伴随着这个过程的是传统商务活动的数字化。
这种类型的事件数据记录下发生的事情，而且往往比传统数据库应用要大好几个数量级。这对于处理提出了重大挑战。
专用数据系统的爆发
第二个趋势来自于专用数据系统（specialized data systems）的爆发，通常这些数据系统在最近的五年中开始变得流行，并且可以免费获得。专门的数据系统是为 OLAP、搜索、简单在线存储、批处理、图像分析等而存在的。
更多更广的数据组合，以及将这些数据应用到更多的系统中的期望，都导致了巨大的数据集成难题。
结构化日志数据流
处理系统之间的数据流，日志是最自然的数据结构。解决方法很简单：提取所有组织的数据，并放到一个用于实时订阅的中心日志中。
每个逻辑数据源都可以用它自己的日志作为模型。数据源可以看作一个输出事件日志的应用（如点击或页面的浏览），或是一个接受修改的数据库表。每个订阅消息的系统都尽可能快的从日志读取信息，将每条新的记录应用到自己的存储中，同时向前滚动日志文件中的自己的位置。订阅方可以是任意一种数据系统——缓存、Hadoop、另一个网站中的另一个数据库、一个搜索系统等。
例如，日志为每个变更提供了逻辑时钟的概念，所有订阅方都可通过逻辑时钟来衡量。这极大简化了如何去推断不同的订阅系统的状态彼此是否一致的，因为每个系统都持有了一个读到哪儿的时间点。
为了让讨论更具体些，我们考虑一个简单的案例，有一个数据库和一组缓存服务器集群。日志提供了一个方法可以同步更新到所有这些系统，并推断出每个系统的所处在的时间点。我们假设做了一个写操作，对应日志记录 X，然后要从缓存做一次读操作。如果我们想保证看到的不是过时的数据，我们只需保证不要去读取那些复制操作还没有跟上 X 的缓存即可。
日志也可起到缓存的作用，使数据的生产异步于数据的消费。有许多原因使得这一点很重要，特别是在多个订阅方消费数据的速度各不相同的时候。这意味着一个数据订阅系统可以宕机或是下线维护，在重新上线后再赶上来：订阅方可以按照自己的节奏来消费数据。批处理系统（如 Hadoop）或者是一个数据仓库，或许只能每小时或者每天消费一次数据，而实时查询系统可能需要及时到秒。无论是起始的数据源还是日志都感知各种各样的目标数据系统，所以消费方系统的添加和删除无需去改变传输管道。
“工作的数据管道都是设计得像日志；而损坏的数据管道各有各的损坏。”
——列夫·尼古拉耶维奇·托尔斯泰（由笔者改编）
特别重要的是：目标系统只知道日志，不知道数据源系统的任何细节。消费方系统自身无需考虑数据到底是来自于一个 RDBMS（关系型数据库管理系统，Relational Database Management System），一种新型的键值存储，或者它不是由任何形式的实时查询系统所生成的。这似乎是一个小问题，但实际上是至关重要的。
这里我使用术语日志取代了“消息系统”或者“发布-订阅”，因为它在语义上更明确，并且对支持数据复制的实际实现这样的需求，有着更接近的描述。我发现“发布订阅”并不比间接寻址的消息具有更多的含义——如果你比较任何两个发布-订阅的消息传递系统的话，你会发现他们承诺的是完全不同的东西，而且大多数模型在这一领域都不是有用的。你可以认为日志是一种消息系统，它具有持久性保证和强大的订阅语义。在分布式系统中，这种通信模型有时被（有些可怕地）称为原子广播（atomic broadcast）。
值得强调的是，日志仍然只是基础设施。这并不是管理数据流这个故事的结束：故事的其余部分围绕着元数据（metadata）、模式（schemes）、兼容性，以及处理数据结构的所有细节及其演化。除非有一种可靠的，一般的方法来处理数据流运作，语义在其中总是次要的细节。
在 LinkedIn
在 LinkedIn 从集中式关系数据库向分布式系统集合转化的过程中，我看到这个数据集成问题迅速的演变。
目前我们主要的数据系统包括：（译者注：已经修复过时的链接）
这些都是在其专业领域提供先进的功能的专用分布式系统。
使用日志作为数据流的思想，甚至在我到这里之前就已经与 LinkedIn 相伴了。我们最早开发的基础设施之一，是一个称为 databus 的服务，为我们早期的 Oracle 表之上提供了一种日志缓存抽象，可扩充数据库修改订阅能力，这样就可以满足我们的社交网络和搜索索引。
我先简单介绍一些历史以提供讨论的上下文。在发布我们自己键值存储之后，大约是2008年我开始参与这个项目。我的下一个项目是让一个工作中的 Hadoop 配置演进，迁移一些推荐处理过来。由于缺乏这方面的经验，我们只计划了几周时间完成数据的导入导出，剩下的时间则用来实现复杂的预测算法。就这样开始了长途跋涉。
我们原计划是仅仅将数据从现存的 Oracle 数据仓库中剥离。但是我们首先发现将数据从 Oracle 中迅速取出简直是一个黑魔法。更糟的是，数据仓库的处理过程并不适合于我们为 Hadoop 设计的批处理生产过程——大部分处理都是不可逆的，并且与将要生成的具体报表相关。最终我们采取的办法是，避免使用数据仓库，直接访问源数据库和日志文件。最后，我们为了完成加载数据到我们的键值存储并生成结果而实现了另一个管道。
这种普通常见的数据拷贝最终成为原来开发项目的主要内容之一。糟糕的是，只要在任何时间任意管道有一个问题，Hadoop 系统基本上就是废的——在错误的数据基础上运行复杂的算法只会产生更多的错误数据。
虽然我们已经使用了一种很通用的构建方式，但是每个数据源都需要自定义的安装配置。这也被证明是大量错误与失败的根源。我们用 Hadoop 实现的网站功能开始流行起来，而我们发现自己有一大把需要协作的工程师。每个用户都有他们想要集成的一系列系统，他们想要的一系列新数据源。
有些东西在我面前开始渐渐清晰起来。
首先，我们已建成的通道虽然有一些杂乱，但实质上它们是很有价值的。在采用诸如Hadoop的新的处理系统生成可用数据的过程，它开启了大量的可能性。 基于这些数据过去很难实现的计算，如今变为可能。 许多新的产品和分析技术都来源于把分片的数据放在一起，这些数据过被锁定在特定的系统中。
第二，众所周知，可靠的数据加载需要数据通道的深度支持。如果我们可以捕获所有我们需要的结构，我就就可以使得Hadoop数据全自动的加载，这样就不需要额外的操作来增加新的数据源或者处理模式变更，数据就会自动的出现在HDFS，Hive表就会自动的生成对应于新数据源的恰当的列。
第三，数据覆盖率仍然非常低。如果你查看存储于Hadoop中的可用的Linked 数据的全部百分比，它仍然是不完整的。花费大量的努力去使得各个新的数据源运转起来，使得数据覆盖度完整不是一件容易的事情。
我们正在推行的是为每个数据源和目标构建定制化的数据加载，然而这显然是不可行的。我们有大量的数据系统和数据仓库。把这些系统和仓库联系起来会导致我们需要在任意一对系统间建立定制通道，如下图：
需要注意的是：数据是双向流动的：例如许多系统诸如数据库和Hadoop既是数据转化的来源又是数据转化的目的地。这就意味着我们我们不必为每个系统建立两个通道：一个用于数据输入，一个用于数据输出。
这显然需要一大群人，而且也不具有可操作性。随着我们接近完全连接，最终我们将有差不多O(N^2)条管道。
替代的，我们需要像这样通用的东西：
我们需要尽可能的将每个消费者与数据源隔离。理想情形下，它们应该只与一个单独的数据仓库集成，并由此让他们能访问到所有东西。
这个思想是增加一个新的数据系统——或者它是一个数据源或者它是一个数据目的地——让集成工作只需连接到一个单独的管道，而无需连接到每个数据消费方。
这种经历使得我关注创建Kafka来关联我们在消息系统所见的与数据库和分布式系统内核所发布的日志。我们希望一些实体作为中心的通道，首先用于所有的活动数据，逐步的扩展到其他用途，例如Hadoop外的数据实施，数据监控等。
在相当长的时间内，Kafka是独一无二的底层产品，它既不是数据库，也不是日志文件收集系统，更不是传统的消息系统。但是最近Amazon提供了非常类似Kafka的服务，称之为Kinesis.相似度包括了分片处理的方式，数据的保持，甚至包括在Kafka API中，有点特别的高端和低端消费者分类。我很开心看到这些，这表明了你已经创建了很好的底层协议，AWS已经把它作为服务提供。他们对此的期待与我所描述的吻合：通道联通了所有的分布式系统，诸如DynamoDB, RedShift, S3等，它同时作为使用EC2进行分布式流处理的基础。
与ETL和数据仓库的关系
我们再来聊聊数据仓库。数据仓库是清洗和归一数据结构用于支撑数据分析的仓库。这是一个伟大的理念。对不熟悉数据仓库概念的人来说，数据仓库方法论包括了：周期性的从数据源抽取数据，把它们转化为可理解的形式，然后把它导入中心数据仓库。对于数据集中分析和处理，拥有高度集中的位置存放全部数据的原始副本是非常宝贵的资产。在高层级上，也许你抽取和加载数据的顺序略微调整，这个方法论不会有太多变化,无论你使用传统的数据仓库Oracle还是Teradata或者Hadoop。
数据仓库是极其重要的资产，它包含了原始的和规整的数据，但是实现此目标的机制有点过时了。
对以数据为中心的组织关键问题是把原始的归一数据联结到数据仓库。数据仓库是批处理的基础查询：它们适用于各类报表和临时性分析，特别是当查询包含了简单的计数、聚合和过滤。但是如果一个批处理系统仅仅包含了原始的完整的数据的数据仓库，这就意味着这些数据对于实时数据处理、搜索索引和系统监控等实时的查询是不可用的。
依我之见，ETL包括两件事：首先，它是抽取和数据清洗过程--特别是释放被锁在组织的各类系统中的数据，移除系统专有的无用物。第二，依照数据仓库的查询重构数据。例如使其符合关系数据库类型系统，强制使用星号、雪花型模式，或者分解为高性能的柱状格式等。合并这两者是有困难的。这些规整的数据集应当可以在实时或低时延处理中可用，也可以在其它实施存储系统索引。
在我看来，正是因为这个原因有了额外好处：使得数据仓库ETL更具了组织级的规模。数据仓库的精典问题是数据仓库负责收集和清洗组织中各个组所生成的全部数据。各组织的动机是不同的，数据的生产者并不知晓在数据仓库中数据的使用情况，最终产生的数据很难抽取，或者需要花费规模化的转化才可以转化为可用的形式。当然， 中心团队不可能恰到好处的掌握规模，使得这规模刚好与组织中其它团队相匹配，因此数据的覆盖率常常差别很大，数据流是脆弱的同时变更是缓慢的。
较好的方法是有一个中心通道，日志和用于增加数据的定义良好的API。与通道集成的且提供良好的结构化的数据文件的职责依赖于数据的生产者所生成的数据文件。这意味着在设计和实施其它系统时应当考虑数据的输出以及输出的数据如何转化为结构良好的形式并传递给中心通道。增加新的存储系统倒是不必因为数据仓库团队有一个中心结点需要集成而关注数据仓库团队。数据仓库团队仅需处理简单的问题，例如从中心日志中加载结构化的数据，向其它周边系统实施个性化的数据转化等。
...
译注
- 如何理解分布式系统的时间、次序、时钟的概念：Time, Clocks, and the Ordering of Events in a Distributed System acm.org，中文翻译。
- 带外数据，wikipedia.org，baike.baidu.com。
共有 0 条评论