转自： http://confluent.io/blog/stream-data-platform-2
http://www.infoq.com/cn/news/2015/03/apache-kafka-stream-data-advice/
在《流数据平台构建实战指南》第一部分中，Confluent联合创始人Jay Kreps介绍了如何构建一个公司范围的实时流数据中心。InfoQ前期对此进行过报道。本文是根据第二部分整理而成。在这一部分中，Jay给出了一些构建数据流平台的具体建议。
限制集群数量
Kafka集群数量越少，系统架构就越简单，也就意味着集成点更少，新增应用程序的增量成本更低，数据流推理更简单。但出于以下几个方面的考虑，再少也不可能只有一个集群：
- 将活动限制在本地数据中心。Jay建议将所有的应用程序都连接到本地数据中心的集群。
- 安全方面的原因。Kafka没有安全控制，通常，这意味着要实现网络级安全和数据类型的物理隔离。
- SLA控制方面的原因。Kafka有一些多租户特性，但并不完善。
简化数据流
以单个基础设施平台为中心实现数据交换可以极大地简化数据流。如果所有系统直接互连，会是下面的样子：
如果有一个数据流平台作为中心，则会是下面的样子：
在第一幅图中，每两个系统之间需要建立两条数据管道，而在第二幅图中，只需要为每个系统创建一个输入和输出连接器来连接流数据管道。系统较多时，这两种情况下的管道数量会有很大差别。
不仅如此，不同的系统可能会有不同的数据模型。点对点集成时，每个系统都需要处理不同系统提供的不同的数据格式，而以数据流平台为中心进行集成的话，每个系统都只需要处理流数据平台的数据格式。这样可以尽量减少价值不高的语法转换。
指定一种数据格式
Kafka并不强制事件数据采用任何特定的格式，使用JSON、XML或Avro都可以。但为事件指定一种在公司范围内通用的数据格式非常关键。数据遵循类似的规范，数据生产者和消费者就不用针对不同的格式编写不同的适配器。这在实现流数据平台之初是最重要的事情。
根据经验，Jay建议选择Apache Avro作为统一的数据格式。Avro是一种类似JSON的数据模型，可以用JSON或二进制形式进行表示。它有如下优点：
- 可以与JSON直接映射；
- 有一个非常紧凑的格式；
- 效率非常高；
- 提供了到多种编程语言的绑定；
- 是一个用纯JSON定义的、可扩展的模式语言；
- 有最好的兼容性理念。
这在保证数据质量和易用性方面非常关键。Avro可以为数据定义一个“模式（schema）”，后者会带来如下好处：
- 增强架构健壮性：在以流数据平台为中心的架构中，应用程序之间是松耦合的,如果没有任何模式，那么系统间极易出现数据不一致的情况。
- 明确语义：模式中每个字段的doc属性明确定义了字段的语义。
- 兼容性：模式处理数据格式变化，使像Hadoop或Cassandra这样的系统可以跟踪上游数据变化，只将有变化的数据传给它们自己的存储，而不必进行重新处理。
- 减少了数据科学家的体力劳动：模式使得数据非常规范，使他们不再需要进行低级的数据再加工。
除了上述建议外，Jay还介绍了他们在LinkedIn的一些做法。
共享事件模式
当一项活动在多个系统中都比较常见，就应该为它指定一个通用的模式。一个常见的例子是应用程序错误，它可以以一种非常通用的方式建模，让ErrorEvent流捕获整个企业的错误。
具体数据类型建模
Kafka数据模型是构建来表示数据流的。在Kafka中，一个流被建模成一个topic，即数据的逻辑名称。每条消息都包含一个用于在集群上进行数据划分的键和一个包含Avro数据记录的数据体。Kafka会根据SLA（如保留7天）或大小（如保留100GB）或键来维护流的历史记录。
- 纯事件流：纯事件流描述企业内发生的活动。比如，在一家Web企业里，这些活动是点击、显示页面和其它各种用户行为。每种行为类型的事件可以表示为一个单独的逻辑流。为了简单起见，建议Avro模式和topic使用相同的名称。纯事件流将总是按时间或大小来保留。单个topic中混合多种事件会导致不必要的复杂性。
- 应用程序日志：结构化日志可以像上文描述的其它事件那样同等对待，这里说的日志是指半结构化应用程序日志。在LinkedIn，所有的应用程序日志都通过自定义的log4j输出源发布到Kafka。
- 系统指标：收集Unix性能数据及应用程序定义的指标等统计数据，然后使用一个通用的格式发布成一个统计数据流，供企业中的监控平台使用。
- Hadoop数据加载：最重要的是实现数据加载过程的自动化，不需要任何自定义设置或者在Kafka topic和Hadoop数据集之间作映射。LinkedIn专门为此开发了一个名为Camus的系统。
- Hadoop数据发布：将由Hadoop计算生成的派生流发布到流数据平台。
- 数据库变更：由于轮询可能会丢失中间状态，因此，LinkedIn选择直接集成数据库日志。对于纯事件数据，Kafka通常只保留一个较短的时间。但对于数据库变更流，系统可能需要从Kafka变更日志实现完全恢复。Kafka特性Log Compaction可以帮助实现这种需求。
- 按原样抽取数据库数据，然后转换：把数据清理后再发布给客户不是一个好主意，因为可能会有许多要求各不相同的消费者，导致清理工作需要针对不同的消费者做许多次，而且清理过程本身可能会丢失信息。所以，发布原始数据流，然后基于它创建一个完成清理工作的派生流。
流处理
流数据平台的一个目标是在数据系统之间以流的方式传递数据，另一个目标是在数据到达时进行数据流处理。在流数据平台中，流处理可以简单地建模成流之间的转换，如下图所示：
在流处理过程中，将处理结果重新发布到Kafka有诸多好处。它将流处理的各部分解耦，不同的处理任务可以由不同的团队使用不同的技术实现，下游处理过程缓慢不会对上游过程造成反压，Kafka起到了缓冲区的作用。
实现流处理最基本的方法是使用Kafka API读取输入数据流进行处理，并产生输出数据流。这个过程可以用任何编程语言实现。这种方法比较简单，易于操作，适应于任何有Kafka客户端的语言。不过，有些流处理系统提供了额外的功能，使用它们构建复杂实时流处理会更简单。常见的流处理框架包括Storm、Samza和Spark Streaming。关于它们之间的差别，感兴趣的读者可以查看这里、这里和这里。