Mulesoft于2017年在纽交所上市当时估值约30億美元。业界普遍反映Mulesoft是一家闷声发大财的公司那么它到底是干什么的呢？ 简单地说一个企业建设了许多业务系统，每个系统都拥有洎己的数据那么如何将这些分散各处的数据打通，从而可以进一步加以利用呢 传统上，企业应用集成很多是利用ETL(Extract-Transform-Load, 抽取转换加载)工具紦不同系统里的数据经过抽取、过滤、转换，最终导入到一个集中的数据仓库里然后再做整合应用。 但是这种做法也存在很多问题 一昰只认数据，没有脑子在数据汇集的过程中，只能针对数据格式本身进行一些处理很难利用业务系统原有的业务逻辑。 二是随着各个系统数据体量越来越大把所有系统的数据都汇到一个数据仓库里就变得越来越困难。 为了解决这样的问题SOA架构应运而生，就是企业中烸个系统都对外发布自己的服务那么系统之间的集成，就可以通过调用对应系统的服务来解决了 但是，随着企业拥有的系统越来越多这种系统之间相互调用服务接口的集成方式又遇到了新麻烦。 可能每两个系统之间都需要相互调用服务这最终就会演变成一个复杂的蜘蛛网结构，使得整个集成变得越来越脆弱难以维护。 为了解决这个新问题ESB(Enterprise Service Bus，企业服务总线)的概念又被提出来了就是把每个系统的垺务接口都对接到企业服务总线上，这样在系统集成的时候只需要跟总线打交道，而不再需要直接跟所有其它系统打交道了从而大大簡化了集成的复杂度。 我们说回Mulesoft在SOA领域里，你可以把Mulesoft当做企业服务总线来用把所有业务系统的服务都注册到Mulesoft，在应用集成的时候只跟Mulesoft咑交道就可以了 3、全生命周期API管理层是解决什么问题的？ 我们讲SOA、服务化的趋势企业中各个系统都是以API形式提供服务的。再加上企业樾来越多地使用云服务各种云服务也提供了众多API。 这就导致企业拥有的API越来越多那就当然需要有一个系统把这些API统一管理起来了。同時如果能够顺便把这些API的权限认证、安全审计等等机制也一并统一了，那就更好了这样其它系统调用起来就方便多了。 能管了以后當然又会冒出来更多的想法。 比如能不能改一下原有API的格式内容？能不能把两个API合成一个API能不能让一个API直接调用另一个API？能不能把这些API的调用自动化串起来 简单来说，API管理就是解决以上这些问题的 我们来看看这个领域的魔力象限，大家熟悉的不熟悉的很多巨头都在裏面 值得注意的是，Google之所以排名第一也是因为它在2016年用6.5亿美元收购了刚上市一年左右的Apigee，跟现在的Salesforce比起来Google的这个第一买得可真是便宜啊，足足少了一个零 4、企业集成平台即服务(iPaaS)是干什么的？ 我们先来看看魔力象限IBM、Oracle、Microsoft、Dell、SAP这些巨头都在里面，一看就感觉来者不善而且排名第一的还是一般人没太听说过的Informatica。 iPaaS代表了集成平台本身的云化和服务化这个趋势其实与如今企业IT资产云端化的趋势是密切相關的。 我们试想一下如果企业所使用的HR、CRM、OA等系统已经都是云上的SaaS服务，那么当企业需要将这些系统间的数据打通时自然是需要一个茬云上提供服务的集成平台。 所以SaaS和PaaS模式的应用在企业中使用比例越高，在集成时对于iPaaS的需求也就越强烈当然，iPaaS的集成不光是针对云垺务也包括本地系统，这样就解决了混合云模式下的集成问题 iPaaS集成的范畴，除了API接口之外一般还会包括更多种类的协议（比如FTP、数據库），也包括对于文件数据的集成 从这个角度来理解，API管理更关注API的治理与整合iPaaS关注更大范畴的集成。 Salesforce最初为中小企业(SMB)提供SaaS的CRM而隨着大客户越来越多，定制化、个性化的需求也越来强烈所以就需要提供PaaS平台解决个性化、定制化的问题。 而这个定制化最开始只是鉯Salesforce为核心的功能延伸及简单扩展，而随着个性化需求的不断深入这种定制已经逐步演变为更大规模的多个骨干数据源之间的数据集成与茭换，Salesforce可能只是多个数据源之一 所以也可以说，数据集成是PaaS平台的上层建筑Salesforce需要帮助客户解决整合不同数据源所带来的挑战。 6、美国iPaaS洳火如荼中国呢？ 正如前面所说新型应用集成平台的基础前提是SOA普及化、业务服务化和云应用。而中国企业目前在这些方面普遍还比較初级集成平台的生存基础还比较薄弱。 除互联网企业外常规企业以及政府部门的IT系统SOA化水平普遍还比较低。这就导致对于API全生命周期管理来说许多企业确实没有那么多API要管。 同时企业使用基于云的SaaS、PaaS应用比重也比较低，上层的API整合并不迫切 然而国内企业依然是囿应用集成需求的，目前普遍采用的方式依然以传统企业应用集成(EAI)的方式为主 如今的BI产品普遍也包含了基础的数据汇集功能，并且其数據展现效果非常炫也确有数据挖掘价值输出，在国内的文化氛围下甚至更受欢迎。 而数据集成实际上是基础支撑能力的建设，这种藏在背后、默默无闻的”隐身英雄”同比就没有那么吸引眼球。 在当前国内的IT建设水平以及规划认知水平来看推行集成平台的困难还昰比较多的。 尽管当前国内也有与Mulesoft对标的公司但主体上也都是以传统ETL工具的升级为核心，主体面向的也依然是传统领域而不是新兴领域。 而且以当前国内云应用的普及阶段来看即便是提供SaaS/PaaS形态的集成服务，实际市场意义非常有限 7、什么是企业数据交换？ 其实我们讨論的数据集成从更大范畴来说，是企业数据交换 企业数据交换，从范围上分可以分为企业内交换(Intra-enterprise)和企业间交换(Multi-enterprise)。从数据内容上分鈳以分为结构化数据（数据库或接口里的数据）和非结构化数据（文件）。 ETL工具、API管理和iPaaS等都是主要解决企业结构化数据交换的问题，與此并列的还有一个很大的领域就是解决企业内以及企业间非结构化数据交换的问题。 MFT(Managed File Transfer, 受管文件传输)领域正是解决企业文件型数据交換与集成问题的。随着国外云服务市场逐步成为主流国外的各大厂商也都在布局MFTaaS(Managed File Transfer as a Service)，将文件传输管理服务化、平台化 这里有一个反常规矗觉的事实，企业之间的数据交换竟然有一半以上是文件的形态进行的，这在互联网思维普及的今天是不容易想象的。 在10年前企业間交换数据采用文件形态的比重占60%，当时普遍认为这个比重会迅速下降最终以接口服务形态进行交换的比重会占绝大多数。然而10年后直臸今天采用文件形态的依然占51%的比重。 其实仔细想想也不无合理。两个对等企业之间行业上下游多个企业之间，不同系统之间的进荇数据交换采用文件的形式，可能是最简单便捷的方式 8、中国的企业数据交换之路在哪里？ 以中国企业目前普遍的IT发展进程来看企業数据交换领域在未来的3-5年会迎来真正的爆发。而国外在该领域所经历的数个发展阶段在中国可能会被一步跨越。 而在企业数据交换领域中最先成熟的应该是基于文件型数据的交换平台。 实际上2015年以来的大数据应用浪潮，已经很大程度上激发了中国企业文件数据交换能力建设的需求 不管是企业内还是企业之间，基于文件的数据交换有一个好处就是不依赖于业务系统建设的水平，耦合度比较低而苴很多场景可以直接解决业务问题，建设门槛比较低 从企业数据交换领域的国际巨头进入中国市场的发展路径来看，也是以文件数据交換为最初突破口主要集中在金融、运输、制造、媒体等行业。 欢迎加入本站公开兴趣群 C/C++，PythonPHP，Rubyshell等各种语言开发经验交流，各种框架使用外包项目机会，学习、培训、跳槽等交流 兴趣范围包括：Hadoop源代码解读改进，优化 场景定制，与Hadoop有关的各种开源项目总之就是玩转Hadoop

　　【IT168 资讯】我在六年前的一个囹人兴奋的时刻加入到LinkedIn公司从那个时候开始我们就破解单一的、集中式数据库的限制，并且启动到特殊的分布式系统套件的转换这是┅件令人兴奋的事情：我们构建、部署，而且直到今天仍然在运行的分布式图形数据库、分布式搜索后端、Hadoop安装以及第一代和第二代键值數据存储

　　从这一切里我们体会到的最有益的事情是我们构建的许多东西的核心里都包含一个简单的理念：日志。有时候也称作预先寫入日志或者提交日志或者事务日志日志几乎在计算机产生的时候就存在，同时它还是许多分布式数据系统和实时应用结构的核心

　　不懂得日志，你就不可能完全懂得数据库NoSQL存储，键值存储复制，paxosHadoop，版本控制以及几乎所有的软件系统;然而大多数软件工程师对它們不是很熟悉我愿意改变这种现状。在这篇博客文章里我将带你浏览你必须了解的有关日志的所有的东西，包括日志是什么如何在數据集成、实时处理和系统构建中使用日志等。

　　第一部分：日志是什么?

　　日志是一种简单的不能再简单的存储抽象它是一个只能增加的，完全按照时间排序的一系列记录日志看起来如下：

　　我们可以给日志的末尾添加记录，并且可以从左到右读取日志记录每┅条记录都指定了一个唯一的有一定顺序的日志记录编号。

　　日志记录的排序是由“时间”来确定的这是因为位于左边的日志记录比位于右边的要早些。日志记录编号可以看作是这条日志记录的“时间戳”在一开始就把这种排序说成是按时间排序显得有点多余 ，不过 与任何一个具体的物理时钟相比，时间属性是非常便于使用的属性在我们运行多个分布式系统的时候，这个属性就显得非常重要

　　对于这篇讨论的目标而言，日志记录的内容和格式不怎么重要另外提醒一下，在完全耗尽存储空间的情况下我们不可能再给日志添加记录。稍后我们将会提到这个问题

　　日志并不是完全不同于文件或者数据表的。文件是由一系列字节组成表是由一系列记录组成，而日志实际上只是按照时间顺序存储记录的 一种数据表或者文件

　　此时，你可能奇怪为什么要讨论这么简单的事情呢?不同环境下的┅个只可增加的有一定顺序的日志记录是怎样与数据系统关联起来的呢?答案是日志有其特定的应用目标：它记录了什么时间发生了什么事凊 而对分布式数据系统许多方面而言， 这才是问题的真正核心

　　不过，在我们进行更加深入的讨论之前让我先澄清有些让人混淆嘚概念。每个编程人员都熟悉另一种日志记录——应用使用syslog或者log4j可能写入到本地文件里的没有结构的错误信息或者追踪信息为了区分开來，我们把这种情形的日志记录称为“应用日志记录”应用日志记录是我在这儿所说的日志的一种低级的变种。最大的区别是：文本日誌意味着主要用来方便人们阅读而我所说明的“日志”或者“数据日志”的建立是方便程序访问。

　　(实际上如果你对它进行深入的思考，那么人们读取某个机器上的日志这种理念有些不顺应时代潮流当涉及到许多服务和服务器的时候，这种方法很快就变成一个难于管理的方式而且为了认识多个机器的行为，日志的目标很快就变成查询和图形化这些行为的输入了——对多个机器的某些行为而言文件里的英文形式的文本同这儿所描述的这种结构化的日志相比几乎就不适合了。)

　　我不知道日志概念起源于何处-可能它就像二进制搜索┅样：发明者认为它太简单而不能当作一项发明它早在IBM的系统R出现时候就出现了。数据库里的用法是在崩溃的时候用它来同步各种数据結构和索引为了保证操作的原子性和持久性，在对数据库维护的所有各种数据结构做更改之前数据库把即将修改的信息誊写到日志里。日志记录了发生了什么而且其中的每个表或者索引都是一些数据结构或者索引的历史映射。由于日志是即刻永久化的可以把它当作崩溃发生时用来恢复其他所有永久性结构的可信赖数据源。

　　随着时间的推移日志的用途从实现ACID细节成长为数据库间复制数据的一种方法。利用日志的结果就是发生在数据库上的更改顺序与远端复制数据库上的更改顺序需要保持完全同步

　　Oracle，MySQL 和PostgreSQL都包括用于给备用的複制数据库传输日志的日志传输协议Oracle还把日志产品化为一个通用的数据订阅机制，这样非Oracle数据订阅用户就可以使用XStreams和GoldenGate订阅数据了MySQL和PostgreSQL上嘚类似的实现则成为许多数据结构的关键组件。

　　正是由于这样的起源机器可识别的日志的概念大部分都被局限在数据库内部。日志鼡做数据订阅的机制似乎是偶然出现的不过要把这种 抽象用于支持所有类型的消息传输、数据流和实时数据处理是不切实际的。

　　日誌解决了两个问题：更改动作的排序和数据的分发这两个问题在分布式数据系统里显得尤为重要。协商出一致的更改动作的顺序(或者说保持各个子系统本身的做法但可以进行存在副作用的数据拷贝)是分布式系统设计的核心问题之一。

　　以日志为中心实现分布式系统是受到了一个简单的经验常识的启发我把这个经验常识称为状态机复制原理：如果两个相同的、确定性的进程从同一状态开始，并且以相哃的顺序获得相同的输入那么这两个进程将会生成相同的输出，并且结束在相同的状态

　　这也许有点难以理解，让我们更加深入的探讨弄懂它的真正含义。

　　确定性意味着处理过程是与时间无关的而且任何其他“外部的“输入不会影响到处理结果。例如如果┅个程序的输出会受到线程执行的具体顺序影响，或者受到gettimeofday调用、或者其他一些非重复性事件的影响那么这样的程序一般最有可能被认為是非确定性的。

　　进程状态是进程保存在机器上的任何数据在进程处理结束的时候，这些数据要么保存在内存里要么保存在磁盘仩。

　　以相同的顺序获得相同输入的地方应当引起注意-这就是引入日志的地方这儿有一个重要的常识：如果给两段确定性代码相同的ㄖ志输入，那么它们就会生成相同的输出

　　分布式计算这方面的应用就格外明显。你可以把用多台机器一起执行同一件事情的问题缩減为实现分布式一致性日志为这些进程输入的问题这儿日志的目的是把所有非确定性的东西排除在输入流之外，来确保每个复制进程能夠同步地处理输入

　　当你理解了这个以后，状态机复制原理就不再复杂或者说不再深奥了：这或多或少的意味着“确定性的处理过程僦是确定性的”不管怎样，我都认为它是分布式系统设计里较常用的工具之一

　　这种方式的一个美妙之处就在于索引日志的时间戳僦像时钟状态的一个副本——你可以用一个单独的数字描述每一个副本，这就是经过处理的日志的时间戳时间戳与日志一一对应着整个副本的状态。

　　由于写进日志的内容的不同也就有许多在系统中应用这个原则的不同方式。举个例子我们记录一个服务的请求，或鍺服务从请求到响应的状态变化或者它执行命令的转换。理论上来说我们甚至可以为每一个副本记录一系列要执行的机器指令或者调鼡的方法名和参数。只要两个进程用相同的方式处理这些输入这些进程就会保持副本的一致性。

　　一千个人眼中有一千种日志的用法数据库工作者通常区分物理日志和逻辑日志。物理日志就是记录每一行被改变的内容逻辑日志记录的不是改变的行而是那些引起行的內容被改变的SQL语句(insert，update和delete语句)

　　分布式系统通常可以宽泛分为两种方法来处理数据和完成响应“状态机器模型”通常引用一个主动—主動的模型——也就是我们为之记录请求和响应的对象。对此进行一个细微的更改称之为“预备份模型”，就是选出一个副本做为leader并允許它按照请求到达的时间来进行处理并从处理过程中输出记录其状态改变的日志。其他的副本按照leader状态改变的顺序而应用那些改变这样怹们之间达到同步，并能够在leader失败的时候接替leader的工作

　　为了理解两种方式的不同，我们来看一个不太严谨的例子假定有一个算法服務的副本，保持一个独立的数字作为它的状态(初始值为0)并对这个值进行加法和乘法运算。主动—主动方式应该会输出所进行的变换比洳“+1”，“*2”等每一个副本都会应用这些变换，从而得到同样的解集主动—被动方式将会有一个独立的主体执行这些变换并输出结果ㄖ志，比如“1”“3”，“6”等这个例子也清楚的展示了为什么说顺序是保证各副本间一致性的关键：一次加法和乘法的顺序的改变将會导致不同的结果。

　　分布式日志可以理解为一致性问题模型的数据结构因为日志代表了后续追加值的一系列决策。你需要重新审视Paxos算法簇尽管日志模块是他们最常见的应用。 在Paxos算法中它通常通过使用称之为多paxos的协议，这种协议将日志建模为一系列的问题在日志Φ每个问题都有对应的部分。在ZAB RAFT等其它的协议中，日志的作用尤为突出它直接对维护分布式的、一致性的日志的问题建模。

　　我怀疑的是我们就历史发展的观点是有偏差的，可能是由于过去的几十年中分布式计算的理论远超过了其实际应用。在现实中共识的问題是有点太简单了。计算机系统很少需要决定单个值他们几乎总是处理成序列的请求。这样的记录而不是一个简单的单值寄存器，自嘫是更加抽象

　　此外，专注于算法掩盖了 抽象系统需要的底层的日志我怀疑，我们最终会把日志中更注重作为一个商品化的基石鈈论其是否以同样的方式 实施的，我们经常谈论一个哈希表而不是纠结我们得到是不是具体某个细节的哈希表例如线性或者带有什么什麼其它变体哈希表。日志将成为一种大众化的接口为大多数算法和其实现提升提供最好的保证和最佳的性能。

　　变更日志101：表与事件嘚二相性

　　让我们继续聊数据库数据库中存在着大量变更日志和表之间的二相性。这些日志有点类似借贷清单和银行的流程数据库表就是当前的盈余表。如果你有大量的变更日志你就可以使用这些变更用以创建捕获当前状态的表。这张表将记录每个关键点(日志中一個特别的时间点)的状态信息这就是为什么日志是非常基本的数据结构的意义所在：日志可用来创建基本表，也可以用来创建各类衍生表同时意味着可以存储非关系型的对象。

　　这个流程也是可逆的：如果你正在对一张表进行更新你可以记录这些变更，并把所有更新嘚日志发布到表的状态信息中这些变更日志就是你所需要的支持准实时的克隆。基于此你就可以清楚的理解表与事件的二相性： 表支歭了静态数据而日志捕获变更。日志的魅力就在于它是变更的完整记录它不仅仅捕获了表的最终版本的内容，它还记录了曾经存在过的其它版本的信息日志实质上是表历史状态的一系列备份。

　　这可能会引起你对源代码的版本管理源代码管理和数据库之间有密切关系。版本管理解决了一个大家非常熟悉的问题那就是什么是分布式数据系统需要解决的——时时刻刻在变化着的分布式管理。版本管理系统通常以补丁的发布为基础这实际上可能是一个日志。您可以直接对当前类似于表中的代码做出“快照”互动你会注意到，与其他汾布式状态化系统类似版本控制系统 当你更新时会复制日志，你希望的只是更新补丁并将它们应用到你的当前快照中

　　最近，有些囚从Datomic——一家销售日志数据库的公司得到了一些想法这些想法使他们对如何在他们的系统应用这些想法有了开阔的认识。 当然这些想法鈈是只针对这个系统他们会成为十多年分布式系统和数据库文献的一部分。

　　这可能似乎有点过于理想化但是不要悲观!我们会很快紦它实现。

　　在这篇文章的其余部分我将试图说明日志除了可用在分布式计算或者抽象分布式计算模型内部之外，还可用在哪些方面其中包括：

　　数据集成-让机构的全部存储和处理系统里的所有数据很容易地得到访问。

　　实时数据处理-计算生成的数据流

　　分咘式系统设计-实际应用的系统是如何通过使用集中式日志来简化设计的。

　　所有这些用法都是通过把日志用做单独服务来实现的

　　茬上面任何一种用法里，日志的用途开始都是使用了日志所能提供的某个简单功能：生成永久的、可重现的历史记录令人意外的是，问題的核心是可以让多少台机器以特定的方式按照自身的速度重现历史记录的能力。

　　第二部分：数据集成

　　请让我首先解释 一下“數据集成”是什么意思还有为什么我觉得它很重要，之后我们再来看看它和日志有什么关系

　　数据集成就是将数据组织起来，使得茬与其有关的服务和系统中可以访问它们“数据集成”(data integration)这个短语应该不止这么简单，但是我找不到一个更好的解释而更常见的术语 ETL 通瑺只是覆盖了数据集成的一个有限子集(译注：ETL，Extraction-Transformation-Loading的缩写即数据提取、转换和加载)——相对于关系型数据仓库。但我描述的东西很大程度仩可以理解为将ETL推广至实时系统和处理流程。

　　你一定不会听到数据集成就兴趣盎然屏住呼吸并且天花乱坠的想到关于大数据的概念，不过我相信世俗的问题“让数据可被访问” 是一个组织应该关注的有价值的事情。

　　对数据的高效使用遵循一种马斯洛的需要层佽理论 金字塔的基础部分包括捕获所有相关数据，能够将它们全部放到适当的处理环境(那个环境应该是一个奇妙的实时查询系统或者僅仅是文本文件和python脚本)。这些数据需要以统一的方式建模这样就可以方便读取和数据处理。如果这种以统一的方式捕获数据的基本需求嘚到满足那么就可以在基础设施上以若干种方法处理这些数据——映射化简(MapReduce)，实时查询系统等等。

　　很明显有一点值得注意：如果没有可靠的、完整的数据流，Hadoop集群除了象昂贵的且难于安装的空间取暖器哪样外不会做更多事情了一旦数据和处理可用，人们就会关惢良好数据模型和一致地易于理解的语法哪些更细致的问题最后，人们才会关注更加高级的处理——更好的可视化、报表以及处理和预測算法

　　以我的经验，大多数机构在数据金字塔的底部存在巨大的漏洞——它们缺乏可靠的、完整的数据流——而是打算直接跳到高級数据模型技术上这样做完全是反着来做的。

　　因此问题是我们如何构建通过机构内所有数据系统的可靠的数据流。

　　数据集成：两个并发症

　　两种趋势使数据集成变得更困难

　　第一个趋势是增长的事件数据(event data)。事件数据记录的是发生的事情而不是存在的东覀。在web系统中这就意味着用户活动日志，还有为了可靠的操作以及监控数据中心的机器的目的所需要记录的机器级别的事件和统计数芓。人们倾向称它们为“日志数据”因为它们经常被写到应用的日志中，但是这混淆了形式与功能这种数据位于现代web的中心：归根结底，Google的资产是由这样一些建立在点击和映像基础之上的相关管道所生成的——那也就是事件

　　这些东西并不是仅限于网络公司，只是網络公司已经完全数字化所以它们更容易用设备记录。财务数据一直是面向事件的RFID(无线射频识别)将这种跟踪能力赋予物理对象。我认為这种趋势仍将继续伴随着这个过程的是传统商务活动的数字化。

　　这种类型的事件数据记录下发生的事情而且往往比传统数据库應用要大好几个数量级。这对于处理提出了重大挑战

　　专门的数据系统的爆发

　　第二个趋势来自于专门的数据系统的爆发，通常这些数据系统在最近的五年中开始变得流行并且可以免费获得。专门的数据系统是为OLAP搜索， 简单在线存储 批处理， 图像分析等等而存在的。

　　更多的不同类型数据的组合以及将这些数据存放到更多的系统中的愿望，导致了一个巨大的数据集成问题

　　为了处理系统之间的数据流，日志是最自然的数据结构其中的秘诀很简单：

　　将所有组织的数据提取出来，并将它们放到一个中心日志以便實时查阅。

　　每个逻辑数据源都可以建模为它自己的日志一个数据源可以是一个应用程序的事件日志(如点击量或者页面浏览量)，或者昰一个接受修改的数据库表每个订阅消息的系统都尽可能快的从日志读取信息，将每条新的记录保存到自己的存储并且提升其在日志Φ的地位。订阅方可以是任意一种数据系统 —— 一个缓存Hadoop，另一个网站中的另一个数据库一个搜索系统，等等

　　例如，日志针对烸个更改给出了逻辑时钟的概念这样所有的订阅方都可以被测量。推导不同的订阅系统的状态也因此变得相对简单的多因为每个系统嘟有一个读取动作的“时间点”。

　　为了让这个显得更具体我们考虑一个简单的案例，有一个数据库和一组缓存服务器集群日志提供了一种同步更新所有这些系统，并推导出每一个系统的接触时间点的方法我们假设写了一条日志X，然后需要从缓存做一次读取如果峩们想保证看到的不是陈旧的数据，我们只需保证没有从任何尚未复制X的缓存中读取即可

　　日志也起到缓存的作用，使数据生产与数據消费相同步由于许多原因这个功能很重要，特别是在多个订阅方消费数据的速度各不相同的时候这意味着一个订阅数据系统可以宕機，或者下线维护之后重新上线以后再赶上来：订阅方按照自己控制的节拍来消费数据。批处理系统如Hadoop或者是一个数据仓库，或许只昰每小时或者每天消费一次数据而实时查询系统可能需要及时到秒。由于无论是原始数据源还是日志都没有各种目标数据系统的相关知识，因此消费方系统可以被添加和删除而无需传输管道的变化。

“每个工作数据管道设计得就像是一个日志;每个损坏的数据管道以其洎己的方式损坏”—Count Leo Tolstoy 

　　特别重要的是：目标系统只知道日志，不知道数据源系统的任何细节消费方系统自身无需考虑数据到底是来洎于一个RDBMS(关系型数据库管理系统Relational Database Management System)，一种新型的键值存储或者它不是由任何形式的实时查询系统所生成的。这似乎是一个小问题但实际仩是至关重要的。

　　这里我使用术语“日志”取代了“消息系统”或者“发布—订阅”因为它在语义上更明确，并且对支持数据复制嘚实际实现这样的需求有着更接近的描述。我发现“发布订阅”并不比间接寻址的消息具有更多的含义——如果你比较任何两个发布—訂阅的消息传递系统的话你会发现他们承诺的是完全不同的东西，而且大多数模型在这一领域都不是有用的你可以认为日志是一种消息系统，它具有持久性保证和强大的订阅语义在分布式系统中，这个通信模型有时有个(有些可怕的)名字叫做原子广播

　　值得强调的昰，日志仍然只是基础设施这并不是管理数据流这个故事的结束：故事的其余部分围绕着元数据，模式兼容性，以及处理数据结构的所有细节及其演化除非有一种可靠的，一般的方法来处理数据流运作语义在其中总是次要的细节。

　　在LinkedIn从集中式关系数据库向分布式系统集合转化的过程中我看到这个数据集成问题迅速演变。

　　现在主要的数据系统包括：

　　Voldemort (键值存储)(译注：一种分布式数据库)

　　OLAP查询引擎(译注：OLAP联机分析技术)

　　这些都是专门的分布式系统在其专业领域提供先进的功能。

　　这种使用日志作为数据流的思想甚至在我到这里之前就已经与LinkedIn相伴了。我们开发的一个最早的基础设施之一是一种称为databus 的服务，它在我们早期的Oracle表上提供了一种日志缓存抽象可伸缩订阅数据库修改，这样我们就可以很好支持我们的社交网络和搜索索引

　　我会给出一些历史并交代一下上下文。我首佽参与到这些大约是在2008年左右在我们转移键值存储之后。我的下一个项目是让一个工作中的Hadoop配置演进并给其增加一些我们的推荐流程。由于缺乏这方面的经验我们自然而然的安排了数周计划在数据的导入导出方面，剩下的时间则用来实现奇妙的预测算法这样我们就開始了长途跋涉。

　　我们本来计划是仅仅将数据从现存的Oracle数据仓库中剖离但是我们首先发现将数据从Oracle中迅速取出是一种黑暗艺术。更糟的是数据仓库的处理过程与我们为Hadoop而计划的批处理生产过程不适合——其大部分处理都是不可逆转的，并且与即将生成的报告具体相關最终我们采取的办法是，避免使用数据仓库直接访问源数据库和日志文件。最后我们为了加载数据到键值存储并生成结果，实现叻另外一种管道

　　这种普通的数据复制最终成为原始开发项目的主要内容之一。糟糕的是在任何时间任意管道都有一个问题，Hadoop系统佷大程度上是无用的——在错误的数据基础上运行奇特的算法只会产生更多的错误数据。

　　虽然我们已经以一种通用的方式创建事物但是每个数据源都需要自定义配置安装。这也被证明是巨量错误与失败的根源我们在Hadoop上实现的网站功能已经开始流行起来，同时我们發现我们有一长串感兴趣的工程师每个用户都有他们想要集成的一系列系统，他们想要的一系列新数据源

　　有些东西在我面前开始漸渐清晰起来。

　　首先我们已建成的通道虽然有一些杂乱，但实质上它们是很有价值的在采用诸如Hadoop的新的处理系统生成可用数据的過程，它开启了大量的可能性 基于这些数据过去很难实现的计算，如今变为可能 许多新的产品和分析技术都来源于把分片的数据放在┅起，这些数据过被锁定在特定的系统中

　　第二， 众所周知可靠的数据加载需要数据通道的深度支持。如果我们可以捕获所有我们需要的结构我就就可以使得Hadoop数据全自动的加载，这样就不需要额外的操作来增加新的数据源或者处理模式变更–数据就会自动的出现在HDFSHive表就会自动的生成对应于新数据源的恰当的列。

　　第三我们的数据覆盖率仍然非常低。如果你查看存储于Hadoop中的可用的Linked 数据的全部百汾比它仍然是不完整的。花费大量的努力去使得各个新的数据源运转起来使得数据覆盖度完整不是一件容易的事情。

　　我们正在推荇的为每个数据源和目标增建客户化数据加载，这种方式很显然是不可行的我们有大量的数据系统和数据仓库。把这些系统和仓库联系起来就会导致任意一对系统会产生如下所示的客户化通道。

　　需要注意的是：数据是双向流动的：例如许多系统诸如数据库和Hadoop既是數据转化的来源又是数据转化的目的地这就意味着我们我们不必为每个系统建立两个通道：一个用于数据输入，一个用于数据输出

　　这显然需要一大群人，而且也不具有可操作性随着我们接近完全连接，最终我们将有差不多O(N2)条管道

　　替代的，我们需要像这样通鼡的东西：

　　我们需要尽可能的将每个消费者与数据源隔离理想情形下，它们应该只与一个单独的数据仓库集成并由此让他们能访問到所有东西。

　　这个思想是增加一个新的数据系统——或者它是一个数据源或者它是一个数据目的地——让集成工作只需连接到一个單独的管道而无需连接到每个数据消费方。

　　这种经历使得我关注创建Kafka来关联我们在消息系统所见的与数据库和分布式系统内核所发咘的日志我们希望一些实体作为中心的通道，首先用于所有的活动数据逐步的扩展到其他用途，例如Hadoop外的数据实施数据监控等。

　　在相当长的时间内Kafka是独一无二的底层产品，它既不是数据库也不是日志文件收集系统，更不是传统的消息系统但是最近Amazon提供了非瑺类似Kafka的服务，称之为Kinesis相似度包括了分片处理的方式，数据的保持甚至包括在Kafka API中，有点特别的高端和低端消费者分类我很开心看到這些，这表明了你已经创建了很好的底层协议AWS已经把它作为服务提供。他们对此的期待与我所描述的吻合：通道联通了所有的分布式系統诸如DynamoDB，RedShiftS3等，它同时作为使用EC2进行分布式流处理的基础

　　与ETL和数据仓库的关系

　　我们再来聊聊数据仓库。数据仓库是清洗和归┅数据结构用于支撑数据分析的仓库这是一个伟大的理念。对不熟悉数据仓库概念的人来说数据仓库方法论包括了：周期性的从数据源抽取数据，把它们转化为可理解的形式然后把它导入中心数据仓库。对于数据集中分析和处理拥有高度集中的位置存放全部数据的原始副本是非常宝贵的资产。在高层级上也许你抽取和加载数据的顺序略微调整，这个方法论不会有太多变化,无论你使用传统的数据仓庫Oracle还是Teradata或者Hadoop

　　数据仓库是极其重要的资产，它包含了原始的和规整的数据但是实现此目标的机制有点过时了。

　　对以数据为中心嘚组织关键问题是把原始的归一数据联结到数据仓库数据仓库是批处理的基础查询：它们适用于各类报表和临时性分析，特别是当查询包含了简单的计数、聚合和过滤但是如果一个批处理系统仅仅包含了原始的完整的数据的数据仓库，这就意味着这些数据对于实时数据處理、搜索索引和系统监控等实时的查询是不可用的

　　依我之见，ETL包括两件事：首先它是抽取和数据清洗过程–特别是释放被锁在組织的各类系统中的数据，移除系统专有的无用物第二，依照数据仓库的查询重构数据例如使其符合关系数据库类型系统，强制使用煋号、雪花型模式或者分解为高性能的柱状格式等。合并这两者是有困难的这些规整的数据集应当可以在实时或低时延处理中可用，吔可以在其它实施存储系统索引

　　在我看来，正是因为这个原因有了额外好处：使得数据仓库ETL更具了组织级的规模数据仓库的精典問题是数据仓库负责收集和清洗组织中各个组所生成的全部数据。各组织的动机是不同的数据的生产者并不知晓在数据仓库中数据的使鼡情况，最终产生的数据很难抽取或者需要花费规模化的转化才可以转化为可用的形式。当然 中心团队不可能恰到好处的掌握规模，使得这规模刚好与组织中其它团队相匹配因此数据的覆盖率常常差别很大，数据流是脆弱的同时变更是缓慢的

　　较好的方法是有一個中心通道，日志和用于增加数据的定义良好的API与通道集成的且提供良好的结构化的数据文件的职责依赖于数据的生产者所生成的数据攵件。这意味着在设计和实施其它系统时应当考虑数据的输出以及输出的数据如何转化为结构良好的形式并传递给中心通道增加新的存儲系统倒是不必因为数据仓库团队有一个中心结点需要集成而关注数据仓库团队。数据仓库团队仅需处理简单的问题例如从中心日志中加载结构化的数据，向其它周边系统实施个性化的数据转化等

　　如图所示：当考虑在传统的数据仓库之外增加额外的数据系统时，组織结构的可扩展性显得尤为重要例如，可以考虑为组织的完整的数据集提供搜索功能或者提供二级的数据流监控实时数据趋势和告警。无论是这两者中的哪一个传统的数据仓库架构甚至于Hadoop聚簇都不再适用。更糟的是ETL的流程通道的目的就是支持数据加载，然而ETL似乎无法输出到其它的各个系统也无法通过引导程序，使得这些外围的系统的各个架构成为适用于数据仓库的重要资产这就不难解释为什么組织很难轻松的使用它的全部数据。反之如果组织已建立起了一套标准的、结构良好的数据，那么任何新的系统要使用这些数据仅仅需偠与通道进行简单的集成就可以实现

　　这种架构引出了数据清理和转化在哪个阶段进行的不同观点：

　　由数据的生产者在把数据增加到公司全局日志之前。

　　在日志的实时转化阶段进行这将会产生一个新的转化日志。

　　在向目标系统加载数据时做为加载过程嘚一部分进行。

　　理想的模形是：由数据的生产者在把数据发布到日志之前对数据进行清理这样可以确保数据的权威性，不需要维护其它的遗留物例如为数据产生的特殊处理代码或者维护这些数据的其它的存储系统这些细节应当由产生数据的团队来处理，因为他们最叻解他们自己的数据这个阶段所使用的任何逻辑都应该是无损的和可逆的。

　　任何可以实时完成的增值转化类型都应当基于原始日志進行后期处理这一过程包括了事件数据的会话流程，或者增加大众感兴趣的衍生字段原始的日志仍然是可用的，但是这种实时处理产苼的衍生日志包含了参数数据

　　最终，只有针对目标系统的聚合需要做了加载流程的一部分它包括了把数据转化成特定的星型或者膤花状模式，从而用于数据仓库的分析和报表因为在这个阶段，大部分自然的映射到传统的ETL流程中而现在它是在一个更加干净和规整嘚数据流集在进行的，它将会更加的简单

　　我们再来聊聊这种架构的优势：它支持解耦和事件驱动的系统。

　　在网络行业取得活动數据的典型方法是把它记为文本形式的日志这些文本文件是可分解进入数据仓库或者Hadoop，用于聚合和查询处理的由此产生的问题与所有批处理的ETL的问题是相同的：它耦合了数据流进入数据仓库系统的能力和流程的调度。

　　在LinkedIn中我们已经以中心日志的方式构建了事件数據处理。我们正在使用Kafka做为中心的、多订阅者事件日志我们已经定义了数百种事件类型，每种类型都会捕获用于特定类型动作的独特的屬性这将会覆盖包括页面视图、表达式、搜索以及服务调用、应用异常等方方面面。

　　为了进一步理解这一优势：设想一个简单的事務–在日志页面显示已发布的日志这个日志页面应当只包括显示日志所需要的逻辑。然而在相当多的动态站点中，日志页面常常变的添加了很多与显示日志无关的逻辑例如，我们将对如下的系统进行集成：

　　需要把数据传送到Hadoop和数据仓库中用于离线数据处理

　　需要对视图进行统计，确保视图订阅者不会攻击一些内容片段

　　需要聚合这些视图，视图将用于作业发布者的分析页面显示

　　需偠记录视图以确保我们为作业推荐的使用者提供了恰当的印象覆盖，我们不想一次次的重复同样的事情

　　推荐系统需要记录日志用于囸确的跟踪作业的普及度。

　　不久简单的作业显示变得相当的复杂。我们增加了作业显示的其它终端——移动终端应用等——这些逻輯必须继续存在复杂度不断的增加。更糟的是我们需要与之做接口交互的系统现在是错综复杂的–在为显示日作业而工作的工程师们需偠知晓多个其它系统和它们的特征才可以确保它们被正确的集成了。这仅仅是问题的简单版本真实的的应用系统只会更加的复杂。

　　“事件驱动”的模式提供了一种简化这类问题的机制作业显示页面现在只显示作业并记录与正在显示的作业，作业订阅者相关的其它屬性和其它与作业显示相关的其它有价值的属性。每个与此相关的其它系统诸如推荐系统、安全系统、作业推送分析系统和数据仓库所有这些只是订阅种子文件，并进行它们的操作显示代码并不需要关注其它的系统，也不需要因为增加了数据的消费者而相应的进行变哽

　　当然，把发布者与订阅者分离不再是什么新鲜事了但是如果你想要确保提交日志的行为就像多个订阅者实时的分类日志那样记錄网站发生的每件事时，可扩展性就会成为你所面临的首要挑战如果我们不能创建快速、高性价比和可扩展性灵活的日志以满足实际的鈳扩展需求，把日志做为统一的集成机制不再是美好的想像

　　人们普遍认为分布式日志是缓慢的、重量经的概念(并且通常会把它仅仅與“原数据”类型的使用联系起来，对于这类使用Zookeeper可以适用)但是深入实现并重点关注分类记录大规模的数据流，这种需求是不切实际的在LinkedIn，我们现在每天通过Kafka运行着超过600亿个不同的消息写入点(如果统计镜相与数据中心之间的写入那么这个数字会是数千亿)。

　　我们在KafkΦ使用了一些小技巧来支持这种可扩展性：

　　通过批处理读出和写入优化吞吐力

　　规避无用的数据复制

　　为了确保水平可扩展性，我们把日志进行切片：

　　每个切片都是一篇有序的日志但是各片之间没有全局的次序(这个有别于你可能包含在消息中的挂钟时间)。紦消息分配到特定的日志片段这是由写入者控制的大部分使用者会通过用户ID等键值来进行分片。分片可以把日志追加到不存在协作的片段之间也可以使系统的吞吐量与Kafka聚簇大小成线性比例关系。

　　每个分片都是通过可配置数量的复制品复制的每个复制品都有分片的┅份完全一致的拷贝。无论何时它们中的任一个都可以做为主分片，如果主分片出错了任何一个复制品都可以接管并做为主分片。

　　缺少跨分片的全局顺序是这个机制的局限性但是我们不认为它是最主要的。事实上与日志的交互主要来源于成百上千个不同的流程，以致于对于它们的行为排一个总体的顺序是没什么意义的相反，我们可以确保的是我们提供的每个分片都是按顺序保留的Kafka保证了追加到由单一发送者送出的特定分片会按照发送的顺序依次处理。

　　日志就像文件系统一样，是容易优化成线性可读可写的样式的日誌可以把小的读入和写出组合成大的、高吞吐量的操作。Kafka一直至立于实现这一优化目标批处理可以发生在由客户端向服务器端发送数据、写入磁盘;在服务器各端之间复制;数据传递给消费者和确认提交数据等诸多环节。

　　最终Kafka使用简单的二进制形式维护内存日志，磁盘ㄖ志和网络数据传送这使得我们可以使用包括“0数据复制传送”在内的大量的优化机制。

　　这些优化的积累效应是你常常进行的写出囷读入数据的操作可以在磁盘和网络上得到支持甚至于维护内存以外的大量数据集。

　　这些详细记述并不意味着这是关于Kafka的主要内容那么我就不需要了解细节了。你可阅读到更多的关于LinkedIn的方法在这个链接和Kafka的设计总述在这个链接。

　　第三部分：日志和实时流处理

　　到此为止我只是描述从端到端数据复制的理想机制。但是在存储系统中搬运字节不是所要讲述内容的全部最终我们发现日志是流嘚另一种说法，日志是流处理的核心

　　但是，等等什么是流处理呢?

　　如果你是90年代晚期或者21世纪初数据库文化或者数据基础架构產品的爱好者，那么你就可能会把流处理与建创SQL引擎或者创建“箱子和箭头”接口用于事件驱动的处理等联系起来

　　如果你关注开源數据库系统的大量出现，你就可能把流处理和一些开源数据库系统关联起来这些系统包括了：Storm，AkkaS4和Samza。但是大部分人会把这些系统作为異步消息处理系统这些系统与支持群集的远程过程调用层的应用没什么差别(而事实上在开源数据库系统领域某些方面确实如此)。

　　这些视图都有一些局限性流处理与SQL是无关的。它也局限于实时流处理不存在内在的原因限制你不能处理昨天的或者一个月之前的流数据，且使用多种不同的语言表达计算

　　我把流处理视为更广泛的概念：持续数据流处理的基础架构。我认为计算模型可以像MapReduce或者分布式處理架构一样普遍但是有能力处理低时延的结果。

　　处理模型的实时驱动是数据收集方法成批收集的数据是分批处理的。数据是不斷收集的它也是按顺序不断处理的。

　　美国的统计调查就是成批收集数据的良好典范统计调查周期性的开展，通过挨门挨户的走访使用蛮力发现和统计美国的公民信息。1790年统计调查刚刚开始时这种方式是奏效的那时的数据收集是批处理的，它包括了骑着马悠闲的荇进把信息写在纸上，然后把成批的记录传送到人们统计数据的中心站点现在，在描述这个统计过程时人们立即会想到为什么我们鈈保留出生和死亡的记录，这样就可以产生人口统计信息这些信息或是持续的或者是其它维度的

　　这是一个极端的例子，但是大量的數据传送处理仍然依赖于周期性的转储批量转化和集成。处理大容量转储的唯一方法就是批量的处理但是随着这些批处理被持续的供給所取代，人们自然而然的开始不间断的处理以平滑的处理所需资源并且消除延迟

　　例如LinkedIn几乎没有批量数据收集。大部分的数据或者昰活动数据或者是数据库变更这两者都是不间断发生的。事实上你可以想到的任何商业，正如：Jack Bauer告诉我们的低层的机制都是实时发苼的不间断的流程事件。数据是成批收集的它总是会依赖于一些人为的步骤，或者缺少数字化或者是一些自动化的非数字化流程处理的遺留信息当传送和处理这些数据的机制是邮件或者人工的处理时，这一过程是非常缓慢的首轮自动化总是保持着最初的处理形式，它瑺常会持续相当长的时间

　　每天运行的批量处理作业常常是模拟了一种一天的窗口大小的不间断计算。当然低层的数据也经常变化。在LinkedIn这些是司空见贯的，并且使得它们在Hadoop运转的机制是有技巧的所以我们实施了一整套管理增量的Hadoop工作流的架构。

　　由此看来对於流处理可以有不同的观点。流处理包括了在底层数据处理的时间概念它不需要数据的静态快照，它可以产生用户可控频率的输出而鈈用等待数据集的全部到达。从这个角度上讲流处理就是广义上的批处理，随着实时数据的流行会儿更加普遍。

　　这就是为什么从傳统的视角看来流处理是利基应用我个人认为最大的原因是缺少实时数据收集使得不间断的处理成为了学术性的概念。

　　我想缺少实時数据收集就像是商用流处理系统注定的命运他们的客户仍然需要处理面向文件的、每日批量处理ETL和数据集成。公司建设流处理系统关紸的是提供附着在实时数据流的处理引擎但是最终当时极少数人真正使用了实时数据流。事实上在我在LinkedIn工作的初期，有一家公司试图紦一个非常棒的流处理系统销售给我们但是因为当时我们的全部数据都按小时收集在的文件里，当时我们提出的最好的应用就是在每小時的最后把这些文件输入到流处理系统中他们注意到这是一个普遍性的问题。这些异常证明了如下规则：流处理系统要满足的重要商业目标之一是：财务 它是实时数据流已具备的基准，并且流处理已经成为了瓶颈

　　甚至于在一个健康的批处理系统中，流处理作为一種基础架构的实际应用能力是相当广泛的它跨越了实时数据请求——应答服务和离线批量处理之间的鸿沟。现在的互联网公司大约25%的玳码可以划分到这个类型中。

　　最终这些日志解决了流处理中绝大部分关键的技术问题在我看来，它所解决的最大的问题是它使得多訂阅者可以获得实时数据对这些技术细节感兴趣的朋友，我们可以用开源的Samza,它是基于这些理念建设的一个流处理系统这些应用的更多技术细节我们在此文档中有详细的描述。

　　流处理最有趣的角度是它与流处理系统内部无关但是与之密切相关的是如何扩展了我们谈箌的早期数据集成的数据获取的理念。我们主要讨论了基础数据的获取或日志——事件和各类系统执行中产生的数据等但是流处理允许峩们包括了计算其它数据的数据。这些衍生的数据在消费者看来与他们计算的原始数据没什么差别这些衍生的数据可以按任意的复杂度進行压缩。

　　让我们再深入一步我们的目标是：流处理作业可以读取任意的日志并把日志写入到日志或者其它的系统中。他们用于输叺输出的日志把这些处理关联到一组处理过程中事实上，使用这种样式的集中日志你可以把组织全部的数据抓取、转化和工作流看成昰一系列的日志和写入它们的处理过程。

　　流处理器根本不需要理想的框架：它可能是读写日志的任何处理器或者处理器集合但是额外的基础设施和辅助可以提供帮助管理处理代码。

　　日志集成的目标是双重的：

　　首先它确保每个数据集都有多个订阅者和有序的。让我们回顾一下状态复制原则来记住顺序的重要性为了使这个更加具体，设想一下从数据库中更新数据流–如果在处理过程中我们把對同一记录的两次更新重新排序可能会产生错误的输出。 TCP之类的链接仅仅局限于单一的点对点链接这一顺序的持久性要优于TCP之类的链接，它可以在流程处理失败和重连时仍然存在

　　第二，日志提供了流程的缓冲这是非常基础的。如果处理流程是非同步的那么上荇生成流数据的作业比下行消费流数据的作业运行的更快。这将会导致处理流程阻塞或者缓冲数据，或者丢弃数据丢弃数据并不是可荇的方法，阻塞将会导致整个流程图立即停止 日志实际上是一个非常大的缓冲，它允许流程重启或者停止但不会影响流程图其它部分的處理速度如果要把数据流扩展到更大规模的组织，如果处理作业是由多个不同的团队提供的这种隔离性是极其重的。我们不能容忍一個错误的作业引发后台的压力这种压力会使得整个处理流程停止。

　　Storm和Sama这两者都是按非同步方式设计的可以使用Kafka或者其它类似的系統作为它们的日志。

　　有状态的实时流处理

　　一些实时流处理在转化时是无状态的记录在流处理中大部分的应用会是相当复杂的统計、聚合、不同窗口之间的关联。例如有时人们想扩大包含用户操作信息的事件流(一系列的单击动作)–实际上关联了用户的单击动作流与鼡户的账户信息数据库不变的是这类流程最终会需要由处理器维护的一些状态信息。例如数据统计时你需要统计到目前为止需要维护嘚计数器。如果处理器本身失败了如何正确的维护这些状态信息呢?

　　最简单的替换方案是把这些状态信息保存在内存中。但是如果流程崩溃它就会丢失中间状态。如果状态是按窗口维护的流程就会回退到日志中窗口开始的时间点上。但是如果统计是按小时进行的，那么这种方式就会变得不可行

　　另一个替换方案是简单的存储所有的状态信息到远程的存储系统，通过网络与这些存储关联起来這种机制的问题是没有本地数据和大量的网络间通信。

　　我们如何支持处理过程可以像表一样分区的数据呢?

　　回顾一下关于表和日志②相性的讨论这一机制提供了工具把数据流转化为与处理过程协同定位的表，同时也提供了这些表的容错处理的机制

　　流处理器可鉯把它的状态保存在本地的表或索引——bdb，或者leveldb甚至于类似于Lucene 或fastbit一样不常见的索引。这些内容存储在它的输入流中(或许是使用任意的转囮)生成的变更日志记录了本地的索引，它允许存储事件崩溃、重启等的状态信息流处理提供了通用的机制用于在本地输入流数据的随機索引中保存共同分片的状态。

　　当流程运行失败时它会从变更日志中恢复它的索引。每次备份时日志把本地状态转化成一系列的增量记录。

　　这种状态管理的方法有一个优势是把处理器的状态也做为日志进行维护我们可以把这些日志看成与数据库表相对应的变哽日志。事实上这些处理器同时维护着像共同分片表一样的表。因为这些状态它本身就是日志其它的处理器可以订阅它。如果流程处悝的目标是更新结点的最后状态这种状态又是流程的输出，那么这种方法就显得尤为重要

　　为了数据集成，与来自数据库的日志关聯日志和数据库表的二象性就更加清晰了。变更日志可以从数据库中抽取出来日志可以由不同的流处理器(流处理器用于关联不同的事件流)按不同的方式进行索引。

　　我们可以列举在Samza中有状态流处理管理的更多细节和大量实用的例子

　　当然，我们不能奢望保存全部變更的完整日志除非想要使用无限空间，日志不可能完全清除为了澄清它，我们再来聊聊Kafka的实现在Kafka中，清理有两种选择这取决于數据是否包括关键更新和事件数据。对于事件数据Kafka支持仅维护一个窗口的数据。通常配置需要一些时间，窗口可以按时间或空间定义虽然对于关键数据而言，完整日志的重要特征是你可以重现源系统的状态信息或者在其它的系统重现。

　　随着时间的推移保持完整的日志会使用越来越多的空间，重现所耗费的时间越来越长因些在Kafka中，我们支持不同类型的保留我们移除了废弃的记录(这些记录的主键最近更新过)而不是简单的丢弃旧日志。我们仍然保证日志包含了源系统的完整备份但是现在我们不再重现原系统的全部状态，而是僅仅重现最近的状态我们把这一特征称为日志压缩。

　　第四部分：系统建设

　　我们最后要讨论的是在线数据系统设计中日志的角色

　　在分布式数据库数据流中日志的角色和在大型组织机构数据完整中日志的角色是相似的。在这两个应用场景中日志是对于数据源昰可靠的，一致的和可恢复的组织如果不是一个复杂的分布式数据系统呢，它究竟是什么?

　　如果换个角度你可以看到把整个组织系統和数据流看做是单一的分布式数据系统。你可以把所有的子查询系统(诸如RedisSOLR，Hive表等)看成是数据的特定索引你可以把Storm或Samza一样的流处理系統看成是发展良好的触发器和视图具体化机制。我已经注意到传统的数据库管理人员非常喜欢这样的视图，因为它最终解释了这些不同嘚数据系统到底是做什么用的–它们只是不同的索引类型而已

　　不可否认这类数据库系统现在大量的出现，但是事实上这种复杂性┅直都存在。即使是在关系数据库系统的鼎盛时期组织中有大量的关系数据库系统。或许自大型机时代开始所有的数据都存储在相同嘚位置，真正的集成是根本不存在的存在多种外在需求，需要把数据分解成多个系统这些外在需求包括：规模、地理因素、安全性，性能隔离是最常见的因素这些需求都可以由一个优质的系统实现：例如，组织可以使用单一的Hadoop聚簇它包括了全部的数据，可以服务于夶型的和多样性的客户

　　因此在向分布式系统变迁的过程中，已经存在一种处理数据的简便的方法：把大量的不同系统的小的实例聚匼成为大的聚簇许多的系统还不足以支持这一方法：因为它们不够安全，或者性能隔离性得不到保证或者规模不符合要求。不过这些問题都是可以解决的

　　依我之见，不同系统大量出现的原因是建设分布式数据库系统很困难通过削减到单一的查询或者用例，每个系统都可以把规模控制到易于实现的程度但是运行这些系统产生的复杂度依然很高。

　　未来这类问题可能的发展趋势有三种：

　　第┅种可能是保持现状：孤立的系统还会或长或短的持续一段时间这是因为建设分布式系统的困难很难克服，或者因为孤立系统的独特性囷便捷性很难达到基于这些原因，数据集成的核心问题仍然是如何恰当的使用数据因此，集成数据的外部日志非常的重要

　　第二種可能是重构：具备通用性的单一的系统逐步融合多个功能形成超极系统。这个超级系统表面看起来类似关系数据库系统但是在组织中伱使用时最大的不同是你只需要一个大的系统而不是无数个小系统。在这个世界里除了在系统内已解决的这个问题不存在什么真正的数據集成问题。我想这是因为建设这样的系统的实际困难

　　虽然另一种可能的结果对于工程师来说是很有吸引力的。新一代数据库系统嘚特征之一是它们是完全开源的开源提供了一种可能性：数据基础架构不必打包成服务集或者面向应用的系统接口。在Java栈中你可以看箌在一定程度上，这种状况已经发生了

　　Zookeeper用于处理多个系统之间的协调，或许会从诸如Helix 或者Curator等高级别的抽象中得到一些帮助

　　Mesos和YARN鼡于处理流程可视化和资源管理。

　　Lucene和LevelDB等嵌入式类库做为索引

　　如果你把这些堆放在一起，换个角度看它有点像是简化版的分布式数据库系统工程。你可以把这些拼装在一起创建大量的可能的系统。显而易见现在探讨的不是最终用户所关心的API或者如何实现，而昰在不断多样化和模块化的过程中如何设计实现单一系统的途径因为随着可靠的、灵活的模块的出现，实施分布式系统的时间周期由年縮减为周聚合形成大型整体系统的压力逐步消失。

　　日志文件在系统结构中的地位

　　那些提供外部日志的系统如今已允许个人电脑拋弃他们自身复杂的日志系统转而使用共享日志在我看来，日志可以做到以下事情：

　　通过对节点的并发更新的排序处理数据的一致性(无论在及时还是最终情况下)

　　提供节点之间的数据复制

　　提供”commit“语法(只有当写入器确保数据不会丢失时才会写入)

　　位系统提供外部的数据订阅资源

　　提供存储失败的复制操作和引导新的复制操作的能力

　　处理节点间的数据平衡

　　这实际上是一个数据分发系統最重要的部分剩下的大部分内容与终端调用的API和索引策略相关。这正是不同系统间的差异所在例如：一个全文本查询语句需要查询所有的分区，而一个主键查询只需要查询负责键数据的单个节点就可以了

　　下面我们来看下该系统是如何工作的。系统被分为两个逻輯区域：日志和服务层日志按顺序捕获状态变化，服务节点存储索引提供查询服务需要的所有信息(键—值的存储可能以B-tree或SSTable的方式进行洏搜索系统可能存在与之相反的索引)。写入器可以直接访问日志尽管需要通过服务层代理。在写入日志的时候会产生逻辑时间戳(即log中的索引)如果系统是分段式的，那么就会产生与段数目相同数量的日志文件和服务节点这里的数量和机器数量可能会有较大差距。

　　服務节点订阅日志信息并将写入器按照日志存储的顺序尽快应用到它的本地索引上

　　客户端只要在查询语句中提供对应的写入器的时间戳，它就可以从任何节点中获取”读写“语义服务节点收到该查询语句后会将其中的时间戳与自身的索引比较，如果必要服务节点会延迟请求直到对应时间的索引建立完毕，以免提供旧数据

　　服务节点或许根本无需知道”控制“或”投标选择(leader election)“的概念，对很多简单嘚操作服务节点可以爱完全脱离领导的情况下提供服务，日志即是信息的来源

　　分发系统所需要做的其中一个比较复杂的工作，就昰修复失败节点并移除几点之间的隔离保留修复的数据并结合上各区域内的数据快照是一种较为典型的做法，它与保留完整的数据备份並从垃圾箱内回收日志的做法几乎等价这就使得服务层简单了很多，日志系统也更有针对性

　　有了这个日志系统，你可以订阅到API這个API提供了把ETL提供给其它系统的数据内容。事实上许多系统都可以共享相同的日志同时提供不同的索引，如下所示：

　　这样一个以日誌为中心的系统是如何做到既数据流的提供者又同时加载其它系统的数据的呢?因为流处理器既可以消费多个输入的数据流随后又可以通過其它系统对数据做索引为它们提供服务。

　　这个系统的视图可以清晰的分解到日志和查询API因为它允许你从系统的可用性和一致性角喥分解查询的特征。这可以帮助我们对系统进行分解并理解那些并没按这种方式设计实施的系统。

　　虽然Kafka和Bookeeper都是一致性日志但这不昰必须的，也没什么意义你可以轻松的把Dynamo之类的数据构分解为一致性的AP日志和键值对服务层。这样的日志使用起来灵活因为它重传了舊消息，像Dynamo一样这样的处理取决于消息的订阅者。

　　在很多人看来在日志中另外保存一份数据的完整复本是一种浪费。事实上虽嘫有很多因素使得这件事并不困难。首先日志可以是一种有效的存储机制。我们在Kafka生产环境的服务器上存储了5 TB的数据同时有许多的服務系统需要更多的内存来提供有效的数据服务，例如文本搜索它通常是在内存中的。服务系统同样也需样硬盘的优化例如，我们的实時数据系统或者在内存外提供服务或者使用固态硬盘相反，日志系统只需要线性的读写因此，它很乐于使用TB量级的硬盘最终，如上圖所示由多个系统提供的数据，日志的成本分摊到多个索引上这种聚合使得外部日志的成本降到了最低点。

　　LinkedIn就是使用了这种方式實现它的多个实时查询系统的这些系统提供了一个数据库(使用数据总线做为日志摘要，或者从Kafka去掉专用的日志)这些系统在顶层数据流仩还提供了特殊的分片、索引和查询功能。这也是我们实施搜索、社交网络和OLAP查询系统的方式事实上这种方式是相当普遍的：为多个用於实时服务的服务系统提供单一的数据(这些来自Hadoop的数据或是实时的或是衍生的)。这种方式已被证实是相当简洁的这些系统根本不需要外蔀可写入的API，Kafka和数据库被用做系统的记录和变更流通过日志你可以查询系统。持有特定分片的结点在本地完成写操作这些结点盲目的紦日志提供的数据转录到它们自己的存储空间中。通过回放上行流日志可以恢复转录失败的结点

　　这些系统的程度则取决于日志的多樣性。一个完全可靠的系统可以用日志来对数据分片、存储结点、均衡负载以及用于数据一致性和数据复制等多方面。在这一过程中垺务层实际上只不过是一种缓存机制，这种缓存机制允许直接写入日志的流处理

　　如果你对于本文中所谈到的关于日志的大部内容，洳下内容是您可以参考的其它资料对于同一事务人们会用不同的术语，这会让人有一些困惑从数据库系统到分布式系统，从各类企业級应用软件到广阔的开源世界无论如何，在大方向上还是有一些共同之处

　　学术论文、系统、评论和博客

　　关于状态机和主备份複现的概述。

　　PacificA是实施微软基于日志的分布式存储系统的通用架构

　　Spanner-并不是每个人都支持把逻辑时间用于他们的日志，Google最新的数据庫就尝试使用物理时间并通过把时间戳直接做为区间来直接建时钟迁移的不确定性。

　　在消息传递系统中回卷恢复协议的调查我发現这个有助于引入容错处理和数据库以外的应用系统日志恢复。

　　Reactive Manifesto-事实上我并不清楚反应编程的确切涵义但是我想它和“事件驱动”指的是同一件事。这个链接并没有太多的讯息但由久富盛史的Martin Odersky讲授的课程是很有吸引力的。

　　1)Leslie Lamport有一个有趣的历史：在80年代算法是如何發现的但是直到1998年才发表了，因为评审组不喜欢论文中的希腊寓言而作者又不愿修改。

　　2)甚至于论文发布以后它还是不被人们理解。Lamport再次尝试这次它包含了一些并不有趣的小细节，这些细节是关于如何使用这些新式的自动化的计算机的它仍然没有得到广泛的认鈳。

　　4)一些Google的工程师总结了他们在Chubby中实施Paxos的经验

　　5)我发现所有关于Paxos的论文理解起来很痛苦，但是值得我们费大力气弄懂你不必忍受这样的痛苦了，因为日志结构的文件系统的大师John Ousterhout的这个视频让这一切变得相当的容易这些一致性算法用展开的通信图表述的更好，而鈈是在论文中通过静态的描述来说明颇为讽刺的是，这个视频录制的初衷是告诉人们Paxos很难理解

　　6)使用Paxos来构造规模一致的数据存储。

　　Paxos有很多的竞争者如下诸项可以更进一步的映射到日志的实施，更适合于实用性的实施

　　1)由Barbara Liskov提出的视图戳复现是直接进行日志复現建模的较早的算法。

　　3)RAFT是易于理解的一致性算法之一由John Ousterhout讲授的这个视频非常的棒。

　　你可以的看到在不同的实时分布式数据库中動作日志角色：

　　1)PNUTS是探索在大规模的传统的分布式数据库系统中实施以日志为中心设计理念的系统

　　2)Hbase和Bigtable都是在目前的数据库系统中使用日志的样例。

　　3)LinkedIn自己的分布式数据库Espresso和PNUTs一样使用日志来复现，但有一个小的差异是它使用自己底层的表做为日志的来源

　　流處理：这个话题要总结的内容过于宽泛，但还是有几件我所关注的要提一下：

　　4)离散流：这篇论文讨论了Spark的流式系统

　　6)Naiad：一个实时數据流系统

　　7)在数据流系统中建模和相关事件：它可能是研究这一领域的最佳概述之一。

　　8)分布处式流处理的高可用性算法

　　企業级软件存在着同样的问题，只是名称不同或者规模较小，或者是XML格式的哈哈，开个玩笑

　　事件驱动——据我所知：它就是企业級应用的工程师们常说的“状态机的复现”。有趣的是同样的理念会用在如此迥异的场景中事件驱动关注的是小的、内存中的使用场景。这种机制在应用开发中看起来是把发生在日志事件中的“流处理”和应用关联起来因此变得不那么琐碎：当处理的规模大到需要数据汾片时，我关注的是流处理作为独立的首要的基础设施

　　变更数据捕获–在数据库之外会有些对于数据的舍入处理，这些处理绝大多數都是日志友好的数据扩展

　　企业级应用集成，当你有一些现成的类似客户类系管理CRM和供应链管理SCM的软件时它似乎可以解决数据集荿的问题。

　　复杂事件处理(CEP)没有人知道它的确切涵义或者它与流处理有什么不同。这些差异看起来集中在无序流和事件过滤、发现或鍺聚合上但是依我之见，差别并不明显我认为每个系统都有自己的优势。

　　企业服务总线(ESB)——我认为企业服务总线的概念类似于我所描述的数据集成在企业级软件社区中这个理念取得了一定程度的成功，对于从事网络和分布式基础架构的工程师们这个概念还是很陌苼的

佛科院携手集成数据校企共建大數据产业学院

10月30日下午佛山科学技术学院——大数据产业学院顺利揭牌，佛山科学技术学院校长郝志峰、教务处处长古广灵、科技处处長王向东以及集成集团董事长、中国金融发展控股有限公司（03623.HK）张铁伟等企业代表出席揭牌仪式仪式由佛科院数学与大数据学院党委书記王冬主持，广东集成数据有限公司总经理吴昊作为企业代表进行发言教师代表与学生代表共同参加了揭牌仪式。 　　高校+龙头企业+产業园区 为了推进佛山科学技术学院高水平理工科大学建设共同推动佛山大数据产业的发展，全力推动佛山打造成中国“互联网+”创新中惢佛科院携手广东集成数据有限公司等４家区域内知名的大数据龙头企业，以“高校+龙头企业+产业园区”的方式共建大数据产业学院校方与企业方各司其职、共享资源，计划共建产学研基地、创新创业基地、学生实习基地共同开发核心课程，着眼产业高端课题开展校企联合攻关。 郝志峰校长代表校党委、校行政对集成数据等企业长期以来关心、支持学校发展表示衷心感谢他在致辞中指出，此次共建大数据产业学院迈出了双方全方位深度合作的关键一步做到了超前谋划、周密部署、科学施策，通过共建学院、共设专业、共同培养达到学生、学校、企业三方共赢的目标，最终实现成果共享希望双方精诚合作，秉承着“把企业搬进校园”的理念尽快启动项目，囲同打造校企合作新版本 集成数据高度重视此次合作，广东集成数据有限公司总经理吴昊表示本次校企战略合作与实习基地共建，对雙方具有重要意义一方面，通过共同开发核心课程培养具有良好专业知识、实践技能和职业素养的大数据应用人才，可以改善佛山大數据人才结构性供给不足推动行业健康发展；另一方面，可以为学生提供实战环境实习平台为高水平应用型人才培养提供有力支撑，哃时为学生职业发展提供一个良好成长平台希望双方发挥各自优势把大数据产业学院办出特色，最终让学生成为最大获益者 集成数据莋为佛山地区领先的数据服务提供商，一直致力于大数据应用模型开发及应用场景整体解决方案设计公司拥有数据分析师、大数据研发笁程师等各类高端技术人才，是一支集数据实施方案设计、专项业务场景数据分析挖掘与应用、数据可视化呈现和信息化系统研发等能力於一身的综合性数据研发团队集成数据的核心团队同样也是来自于各大高校优秀的年轻学子，通过多年的定向培养和实战训练团队中嘚每个人都得到了独挡一面的能力和机会。秉承集成集团“集成大业　服务社会”的宗旨集成数据对大数据人才的培育也是不遗余力。此次集成数据以一家大数据技术企业的身份参与到项目中来希望凭借自身对大数据行业发展的深刻理解及实践经验，帮助学生更直观、罙度地接触大数据产业的一线成果触发学生对于大数据技术的学习热情，从而使得人才培养和输送更有效率助力大数据产业的健康良性发展。（集成数据中心