Lambda架构

13-03-10 banq

sentric » Lambda Architecture, Part 1

Hadoop框架带来了批量数据处理，但是网络规模大数据的实时处理仍然是一个挑战。有很多技术可以用来建立这样一个完整的数据处理系统 - 但要选择合适的工具并且编排使用它们却是复杂和艰巨的。

Nathan Marz将任何数据系统都可定义为：

“query = function(all data)”

Lambda系统架构定义了一套明确的架构原则，如果要建立一套强大的和可扩展的数据系统，必须服从上面的公式。

Lambda基于下列原则：

1.人为容错性human fault-tolerance – 系统易数据丢失或数据损坏，大规模时可能是不可挽回的。

2.数据不可变性data immutability – 数据存储在它的最原始的形式不变的，永久的。

3.重新计算recomputation – 因为上面两个原则，运行函数重新计算结果是可能的。

Lambda架构是由三层组成：批处理层，服务层和速度层：

批处理层：Hadoop 是理想的批处理层工具

服务层：用于加载和现实数据库中的批处理视图，以便用户能够查询，不一定需要随机写，但是支持批更新和随机读，推荐：ElephantDB or Voldemort。

速度层：

主要处理新数据和服务层更新造成的高延迟补偿，利用流处理系统如 (Storm, S4, Spark) 和随机read/write数据存储库来计算实时视图(HBase). 这些视图有效期一直到它们已经能通过批处理和服务层获得时为止。

为了获得一个完整结果，批处理和实时视图都必须被同时查询和融合(实时代表新数据)。

Lambda架构通过定义一些很清晰的原则来处理复杂大数据 Big Data .

[该贴被admin于2013-03-10 16:18修改过]

banq

2013-03-11 08:21

有人提出所谓Hadoop困境：

【Hadoop的困境】进，由于天生的批量处理基因，无法适应实时处理的需求；退，由于没有坚实的关系代数逻辑基础，根本无法满足关系型的查询，它无法真正解决与传统SQL工具的兼容问题。

这实际陷入关系数据库思维出不来，无法摆脱，从Lambda架构看出，实时部分也就是Speed速度层由Storm之类完成。

我非常赞同@SpeedVan

预测：函数式未来与数据库磨合，sql消失，如果说我以前鼓吹OO，只是采取不同于关系数据库的思维方法，有时还能共存，尽管存在各种不匹配，那么函数化Lambda真的可能会完全替代关系数据库，所谓关系数据库的代数逻辑基础可被对象的关联逻辑替代。

所有数据系统都将可用query = function(all data)完美实现，可参见：Big Data – Principles and best practices of scalable realtime(实时) data systems

banq

2013-07-17 14:01

Big Data: Principles and best practices of scalable realtime

《大数据：可扩展实时系统的原理和最佳实践》是分布式实时处理系统Storm的作者及另一位twitter老兄合作写的。

书中主要描述上述三层主要概念：自底向上分别是：

1. Batch Layer

主要进行批量处理，其特点是延时较高、高吞吐量，并且是append-only（没有delete和update的概念）的。本书采用Hadoop实现，包括HDFS和Hadoop MapReduce。包括对全部数据集的预计算。

2. Serving Layer

主要进行批量更新，其特点是延时相对较低，一般数小时更新一次。本书主要采用HBase和Cassandra实现。

3. Speed Layer

主要进行低延时更新（与Serving Layer的批量更新相比，这里更接近于实时更新），是一种流处理（stream processing），采用各种复杂的增量算法实现。本层是对Serving Layer的补充，即只处理Serving Layer中间“没有”的“数小时”的数据，并且一旦这些数据在Serving Layer存在了，Speed Layer就将它们丢弃，并重新处理来着应用层的新数据。注意，查询的结果将来自于Serving Layer和Speed Layer处理结果的merge。本书采用Storm实现。

此外，作者还将big data相关的开源项目做了以下分类：

1. 批量计算系统：延时较高、吞吐量大，如Hadoop。

2. 序列化框架：为对象和字段提供一种模式定义语言，实现传输通信以及不同语言环境之间的转化。如Thrift, Protocol Buffers, 和Avro。

3. 支持任意存取的NoSQL数据库：牺牲了SQL强大的表现力优势，根据应用场景不同仅支持部分操作。按照CAP理论来说，就是牺牲C（一致性）或A（可用性）来实现AP或CP。如Cassandra, HBase, MongoDB,Voldemort, Riak, CouchDB等。

4. 消息/排队系统：保证进程之间以容错和异步的方式传递消息，在实时处理系统中非常重要。如Kestrel。

5. 实时计算系统：高吞吐、低延时的流处理系统。如Storm。

其他参考：The Lambda architecture: principles for architecting realtime Big Data systems

猜你喜欢