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修改过]

                   

14
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