大数据处理 Lambda 架构读书笔记 序言
|
我对于大数据处理架构的研究是从2017年开始的，最开始涉猎的资料都是零星的，一直没有一套完整的学习和研究资料。当然除了我本人不是研究数据架构出身这个原因外，另一个主要原因是大数据处理本身也是一个比较年轻的现象。 我最开始完整而详实地读一本大数据架构专著是从Nathan Marz 和James Warren的Big Data: Principles and best practices of scalable realtime data systems这本书开始的。 Nathan是斯坦福大学的高材生，后来在一家公司做首席架构师，这家公司后来被Twitter收购了。这哥们算是行业大牛了。 附上一个采访和一个他的github库的链接。 本来是不打算写这篇文章的，但是他这本书是英文，好像市面上当时也没看到什么中文版本，而我在书籍上做了很多读书笔记，有时候想看一下又反麻烦，毕竟带着这本书到处走也不是个好的选择。所以，在这里记录下来。一来方便自己查看，二来也做一个分享。 这个系列，基本是按照书中的顺序进行介绍的，是一种概括式的翻译，同时加入一些背景知识和自己的想法。 好了，闲话少叙，书归正文。 先说说序言吧。 当作者刚进入这个领域时，原始的关系型数据库已经逐渐被抛弃，而NoSQL，这种非关系型数据库开始大行其道。我目前的公司也在用MongoDB，它也是一种NoSQL。与此同时，Hadoop项目也开始流行，它能够对大规模数据进行深度分析。当作者进入这个行业时，采用哪些新的技术是让人困惑的，因为新的技术层出不穷，令人眼花缭乱。时至今日，其实依然如此。 Nathan当时所处的公司的数据架构是令人窒息的复杂，问题和bug极多，他所要做的就是看看是不是可以设计一个更好的架构。他的同事当时需要花费几周时间才能拿到需要分析的数据。而且谁要是一不小心删掉了一些数据，可能导致其他人好几周都无法完成分析工作。 他一直致力于这个架构设计，思想上逐渐形成的架构就是后来的Lambda架构，他所在的公司是BackType，后来被Twitter收购了。他们团队大概5个人后来完成一个社交媒体分析产品，这个产品可以实时分析100TB的数据。 本质上说，Nathan这个架构的特点就是精简。用他的话说“It is not what we are doing, but what we are not doing." 过高的复杂度是大数据领域大部分问题的根源，无论是SQL还是NoSQL。这本书就是关于Lambda架构设计的，用Nathan的话说，这是一个简洁、优雅并且有趣的架构。 目前，大数据系统都是通过很多计算机并行储存和处理数据的，在这本书的写作时期大数据架构图，估计这个理念还比较新。当然，现在已经是司空见惯了。传统数据分析都是用服务器，所有数据存在服务器上，数据量太大，就得不断优化数据结构，或者购置昂贵的服务器，但是这仍然是杯水车薪。采用廉价的计算机，将其并联，用作数据存储和数据分析的工具是一种不错的选择，也是目前的一个趋势。 这本书的1章是背景介绍。2到9章是batch layer的介绍，10和11章是关于serving layer的，12到17章是speed layer，最后的18章是关于一些新的知识。这些后文我也会分章节介绍。 lambda的基础机构应该是在第一章叙述的，这里我还是想给大家一个全面的介绍，谈谈我本人的粗浅理解。我是一个有大局观的人，如果不能在开头了解梗概，我很难读下去一本书。这种宏大叙事的世界观也让影响了我的历史观。这里也推荐一下“万历十五年”，黄仁宇的一本书，我读了2遍，深感不错。 传统应用的数据系统架构设计时，应用直接访问数据库系统。当用户访问量增加时，数据库无法支撑日益增长的用户请求的负载时，从而导致数据库服务器无法及时响应用户请求，出现超时的错误。 现在数据量从M的级别到G的级别到现在T的级、P的级别。数据量的变化数据管理系统（DBMS）和数仓系统（DW）也在悄然的变化着。这也是大数据架构的现实需求，所有的大型数据公司都在搞自己的研究，技术的进步是永无止尽的。 问题是不断出现的，解决了旧的才会有新的，我们这里不妨做做历史探究。 一般你访问一个数据，应该是实时的，但是如果用户不止你一个呢？如果有很多呢？ 传统应用的数据系统架构设计时，应用直接访问数据库系统。当用户访问量增加时，数据库无法支撑日益增长的用户请求的负载时，从而导致数据库服务器无法及时响应用户请求，出现超时的错误。这怎么办？买更好的服务器？ 当然这不是最好的办法，一般会采用软件优化，比如通过Queue，在数据库和应用中间过一层缓冲隔离，缓解数据库的读写压力。然而，当用户访问量持续增加时，就需要考虑读写分离技术（Master－Slave）架构则如下图，分库分表技术。现在，架构变得越来越复杂了，增加队列、分区、复制等处理逻辑。应用程序需要了解数据库的schema，才能访问到正确的数据。
面对这些问题，因此才有新的技术和架构不断出现。比如之前流行的Hadoop就是如此。
下图是Hadoop的一个基本架构。看起来相当不错，但它仍然是一种传统的批处理方式，具有所有已知的缺点，主要原因是客户端的数据在批处理花费大量时间完成之前的数据处理时，新的数据已经进入而导致数据过时。
这样，如果一个公司有大量的实时数据，这种数据处理方式显然是忽略掉很多数据的，对于数据分析的结果也是有很大影响的。虽然用 Storm 开发的实时流处理技术可以帮助解决延迟性的问题，但并不完美。其中的一个原因是，Storm 不支持 exactly-once 语义，因此不能保证状态数据的正确性，另外它也不支持基于事件时间的处理。 Nathan的Lambda架构的目标是设计出一个能满足实时大数据系统关键特性的架构，包括有：高容错、低延时和可扩展等。Lambda架构整合离线计算和实时计算，融合不可变性（Immunability），读写分离和复杂性隔离等一系列架构原则，可集成Hadoop，Kafka，Storm，Spark，Hbase等各类大数据组件。 一个数据系统本质上应该具有数据存储和数据查询的功能。 如果存储数据？这就要观察数据的特征了。一般来说我们的宇宙是4维的，三位空间和一维时间。当然，弦理论也认为宇宙是10.4维的。我们这里不做理论物理学的研究，对于一般人而言，他能感知的部分基本是4维。简单拆解，就是时间维度+空间维度。 所以我认为，数据也可以被分解为这2个维度，因为数据就是人类产生的，它离不开人类的生产生活。它可以被拆解为时间when，内容what。 Nathan的Lambda架构中对数据的存储采用的方式是：数据不可变，存储所有数据。 其实，github这种网站也是类似的思路，历史版本永远存在。在数据存储成本极低的今天，保存历史上发生的一切数据是重要而且聪明的。 除了数据的保存，另一项就是数据的查询了，这里的查询当然是广义的。 一个很流行的定义如下，即查询是应用于数据集上的函数： Query = Function(All Data) 因为查询是一个函数，函数的执行是可以拆解的。其实一切计算都可以拆分成更小的命令，学过汇编语言的人很容易理解这里面的道理。 既然函数的执行可以被拆解，那么既可以安排不同计算机并行计算，然后再结合各自的部分运算结果得到最终结果，这就是分布式处理了。更进一步，我们可以保留这个结果来供其他人使用，从而减少重复运算的工作量。这道理很简单。 前面是对数据系统本质的探讨。好了，那么我们如何实时地在任意大数据集上进行查询，且保证一定的准确性和效率？Lambda架构通过分解的三层架构来解决该问题：Batch Layer，Speed Layer和Serving Layer。 Batch Layer 理想状态下，任何数据访问都可以从表达式Query= function(all data)开始，但是，若数据达到相当大的一个级别（例如PB），且还需要支持实时查询时，就需要耗费非常庞大的资源。一个解决方式是预运算查询函数（precomputed query function）。书中将这种预运算查询函数称之为Batch View这样当需要执行查询时，可以从Batch View中读取结果。这样一个预先运算好的View是可以建立索引的，因而可以支持随机读取。Batch Layer采用不可变模型存储所有的数据。因为数据量比较大，可以采用HDFS之类的大数据储存方案。 这个办法很巧妙，但是Batch View怎么确定呢？怎么编写呢？这就和具体公司的经营业务相关了。 Batch Layer可以很好的处理离线数据，但有很多场景数据不断实时生成，并且需要实时查询处理。Speed Layer正是用来处理增量的实时数据。它俩的处理逻辑相似，只是处理对象不同。Speed Layer处理的数据是最近的增量数据流，Batch Layer处理的全体数据集。Speed Layer中处理的数据也不断写入Batch Layer，当Batch Layer中重新计算的数据集包含Speed Layer处理的数据集后，当前的Realtime View就可以丢弃，这也就意味着Speed Layer处理中引入的错误，在Batch Layer重新计算时都可以得到修正。 Lambda架构的Serving Layer用于响应用户的查询请求，合并Batch View和Realtime View中的结果数据集到最终的数据集。 上一张架构图吧
Lambda架构图 好了，序言部分先说到这。随后，我会继续介绍Big Data这部分的具体章节的内容。 （编辑：厦门网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
