构建流数据平台（stream data platform)实践指南-（part 1）

该指南讨论：

         如何构件一个企业的实时数据平台，以及如何利用这些数据构建应用程序。

第一部分将给出一个流数据平台的总揽：一个实时流数据的中心插槽（hub）。第二部分将为高效的实践提出一些建议。

什么是流数据平台？

流数据平台：一个用于Event存储的明亮干净的地方。（a clean,well-lighted place forevent）。

kafka的目的就是：作为一个数据流的中心仓库，为什么这么做呢？

动机：如何在系统之间传输数据。在LInkedIn公司，他们有许多数据系统：关系型在线事务处理（OLTP）数据库，Hadoop，Teradata(一个企业级数据仓库)，搜索系统、监控系统、线下分析处理(OLAP)存储和派生的key-value存储。每个系统都需要使用地理上分布式的数据作为输入。这就是传统的ETL，或者LinkedIn称之为的数据集成。

这是LinkedIn公司一开始使用管道方式（pipeline）实现的数据集成系统。随着时间的推移，该系统变得越来越复杂。其中的每个管道都有不同的问题，用于log data 的管道具有扩展性，但是数据有丢失，并且传输数据延时高。Oracle之间的管道速度快，并且是实时的，但是对其他系统来说是不可用的。连通搜索系统的管道延时低，但是不可扩展并且直接和数据库相连。他们的消息系统延时低,但是不可靠且不扩展。

         当他们添加数据到地理上分布式的系统中时，他们不得不将这些数据流在地理上做复制，当其中一个系统做扩展时，它所支持的管道也得做扩展。

         更加糟糕的是，系统的复杂性意味着数据总是不可靠的。他们做的报告不可信，派生得到的索引和存储也是问题重重，每个人都会花大量的时间来面对数据质量问题。

         同时他们希望将数据从一个地方搬到另一个地方。例如，利用Hadoop出色的批处理能力，数据归档，和即席查询（ad hoc）处理等能力。于是在2010，他们提出了实现这么一个架构。

于是LinkedIn公司极其复杂的数据系统体系结构变成了这样。

一个以流为中心，构建在Apache Kafka之上的体系结构。

在这个设计中，kafka只作为一个通用的数据管道。每个系统能够向kakfa递交（feed）数据，也能够从中获取(fed by)数据。应用程序或者流处理器能够接入到其中，来产生新的、派生的流，反过来，这些流也可以提供给这些系统。

         例如，一个用户更新了它的资料，那么这个更新将流到他们的流处理层，在那里这个更新将用来标准化该用户的公司信息，地址，和其他属性。同时这个流可能流向搜索索引并且被社交图用来查询;流向推荐系统，用于工作匹配等。所有的这些行为发生在毫秒之间。这个流同样可以加载到hadoop中，用于数据仓库。

流数据：大多数的业务都可以看作是一个Event流。零售商有一个订单流，销售流，价格调节流，回报流等等。金融有订单，股票价格和其他一些金融时间序列。网站有点击流，关注流，搜索流等等。大的软件系统有请求流，错误流，机器指标流和日志流。关于业务的一个观点是，一个数据处理系统，以不同的流作为输入，再输出相应的流。这对于将数据作为数据库中的表的列的人感觉有点奇怪。

Event和Event流的兴起：你的数据库存储的是你数据的当前状态。但是当前状态总是有之前的一些动作导致的，这些动作就是event。你的收入表是由已经交易和销售的Event产生的状态，银行的余额是由存款和贷款产生的结果。

         互联网公司收集日志信息，也就是事件信息，最后对这些日志进行分析处理。

数据库就是事件流：像订单，销售，点击等很明显由于事件的属性。大多数人将数据保存到数据库中，无论是关系型数据库，例如，Oracle,MySQL,Postgres或者是新兴的分布式数据库，例如，MongoDB,Cassandra,和Couchbase.这些看起来都跟事件流不相关。

         但是，事实上，数据库中的数据也可以看作是事件流。理解用事件流表示一个数据库最好的方式是想象备份或者拷贝一个数据库。一种简单的方法是定时的导出（dump）你数据库中的内容,并且将这些内容导入到备份的数据库。如果我们不是频繁地操作，并且我们的数据不是很大，那么相比全部导出整个数据库，该方法更为可行。事实上，许多数据库备份和ETL过程正是这样做的。然而当我们提高操作频率时，该方法不具有扩展性：如果我们一天对数据库做两次全dump,那么将使用两次系统资源，如果每小时做一次，那么将使用24次系统资源。更为合适的方法是做一个“diff”,找出变化的内容，并且只获取那些新建的、更新过的或者在最近一次diff后删除的行。如果我们使用两倍的操作频率，那么diff将大体上变为原来的一半。这样系统资源的使用不会因为操作频率的增加而增加。

         如果我们将这个过程的频率发挥到极致，我们就将得到每行变化的持续序列。这样的Event流就叫做变化抓取（change capture）,这是许多数据库（Oracle的XStream和GoldenGate,MySQL的binlog replication以及Postgresd的Logical Log Streaming Replication）的实现方式。

         通过发布数据库变化到流数据平台，你能够将其添加到其他的数据流中。你能够使用这些流来同步其他系统，例如Hadoop cluster,一个副本数据库，和一个搜索索引，或者你能够将这些变化输入到应用程序或者流处理器，直接计算得到其他的变化信息。这些变化信息反过来再作为流，提供给其他集成的系统所使用。

流数据平台做什么？

数据集成：流数据平台获取事件流或者其他数据变化，将其（feed）输入给其他数据系统，例如关系型数据库，key-value存储，Hadoop或者其他数据仓库。

流处理：它能够进行连续的、实时的处理和转换这些流，产生系统级的可用结果。

         第一个角色中，流数据平台是一个中心的数据流插座。集成的应用程序不必和数据源直接相连，更不必关心数据源的细节，所有流对他来说都一样。同样，他也作为一个这些系统间的数据buffer。数据发布不必关心最终消费这些数据的系统的细节，这就意味着数据的消费者能够来去自如，完全地和数据源解耦。

         如果你引入一个新的系统，你仅需要连接到中心插槽，打开数据流，而不需要去连接所有单个的数据源和数据流目的系统。所有的流看起来都是一样的，不论他是来自log file、数据库、Hadoop，或者是一个数据流处理器。（Hadoop作为这么一个数据池来说，1.集成每个数据源到HDFS非常耗时，而且最终的结果只对Hadoop可用；2.这种类型的数据获取不适合实时处理或者同其他实时系统保持同步）

         流处理，通过接入事件流到一个应用程序，同时该应用程序处理产生新的事件流。这类应用程序能够借组现成的流处理框架，例如storm，spark Streaming Samza来实现。这些框架提供了丰富的处理原语。所有的这些框架都可以和kafka很好的集成。

流数据平台需要做什么？

         之前提到的用例都跟事件流相关，但是每个事件流有不同的要求-有的需要快速（fast）,有的需要高吞吐量（hight-throughput）,有的需要扩展性等等。如果我们开发一个单一的平台来满足所有这些需要，我们应该做些什么呢？以下是对于一个流数据平台的主要要求：

1.它必须足够可靠，来处理重要的更新，例如复制一个数据库的changelog到一个副本存储，例如搜索索引，有序无损（loss）的递交数据。

2.它必须有足够高的吞吐量，来处理大量的log或者事件数据流。

3.它必须能够长时间的buffer或者持久化数据，来支持与批处理系统的集成。

4.它必须低延时地提供数据，来支持实时应用。

5.它必须可以作为一个中心系统，通过扩展存储一个公司的所有数据负载。并且能够处理成百个独立团队开发的应用的接入。

6.能够同流处理系统方便的集成。

（解决数据碎片问题。）

Apache Kafka 是什么？

Apache Kafka是一个设计用于流数据的分布式系统。它具有容错性（fault-tolerant）、高吞吐量（hight-throughput）,水平扩展（horizontally scalable）和允许地理分布的数据流和处理。

         通常，人们把kafka归类为消息系统，通常它也作为消息系统使用。但是具有不同的基础抽象。kafka的基础抽象是一个更新（update）的结构化提交日志。

一个数据的生产者（producer）将记录（record）流追加到该日志，一些数量的消费者（consumer）能够持续的以毫秒级别的延时从该log的尾部流式地读出数据。每个消费者有他自己的在该log中的一个位置（position），并且该位置独立地增加。这提供了一个可靠的、有序的更新流给所有的消费者。

         这个log能够分片（sharded）或者分布在一个机器集群中，每个分片（shard）进行复制来提供错误容忍性。这样就提供了一个并行，有序消费的模型，这对将kafka应用到数据库更新是很重要的（数据库 更新，更新的传递必须有序）。

         Kafka一个设计核心是它能够很好的处理数据持久化。一个kafka 代理（broker）能够存储TB级别的数据，这使得在传统数据库中不可行的使用模式成为可能：

1.一个由kafka提供数据的Hadoop集群或者其他线下系统能够停止服务来做维护，并且在几小时或者几天后开启服务，而不用担心数据丢失，因为流上游的（up-steam）kafka已经安全地将数据进行了持久化。

2.当从一个数据库表中同步数据时，能够开启一个“full dump”，下游的消费者可以访问到所有的数据。

事件驱动应用程序：

         例如，在LinkedIn公司，他们最开始获取网站上工作展现的查看流，其中的一个流feed给了Hadoop和他们的数据仓库。随着时间的推移，这个工作查看流被许都系统所使用：

值得注意的是，显示工作的应用不需要特别的修改来集成其他应用。它仅仅是产生工作查看流。其他应用接入该流，并且添加自己的处理。同样，如果当工作查看功能在其他应用中发生，例如一个移动应用，该应用也是仅仅将工作查看流添加到kafka,而下游的处理器不必做任何修改。

流数据平台和已有事物的联系：

消息系统：

         流数据平台同企业消息系统很相似，它接收消息，并且将消息发布到感兴趣的订阅者。这里有3个重要的不同之处。

1.消息系统通常是对不同应用一次性部署。而流数据平台是作为一个中心的数据插槽。

2.消息系统对批系统的集成支持不好，例如数据仓库或者Hadoop集群，并且他们的存储能力有限。

3.消息系统不包括同流处理兼容的语义。

换句话说，流数据平台是一个消息系统，它的职责被放在整个组织中重新定义了。

数据集成工具：

         流数据平台能够使得系统间的数据集成更为容易。然而，他的职责同Informatica等工具有所不同。

Engerprise Service buses（企业服务总线）

         流数据平台有许多企业服务总线思想在里面，但是是更好的实现。企业服务总线的一个挑战是它将数据转换和总线本身耦合（coupling）。使用企业服务总线的一些挑战是，转换时间的许多逻辑放到了消息总线本身，然而却没有为多租户（multi-tenant）云部署和运营环境进行好的逻辑建模。

         流数据平台的一个好处是数据的转换根本上同流本身的解耦。这部分代码能够在应用或者流处理任务中。

数据仓库和Hadoop：

       流数据平台不会替代数据仓库；相反，它作为数据的一个集聚地，将数据流向数据仓库环境做长时间的保存、即席（ad-hoc）查询分析和批处理。相反方向的管道（Hadoop到Kafka）能够允许批处理结果发布到流数据平台。