（七）Lambda架构：Twitter亿级实时数据分析架构背后的倚天剑 作者: lovingyu_er 时间: 2019-05-11 16:57:00 分类: 大规模数据处理 评论 ###Lambda架构 案例需求:用户端广告精准投放，拥有海量的用户网站访问行为。根据用户的行为分析建立一个模型，然后根据这个模型来投放用户洗好的广告。 我们知道，批处理架构和流处理架构的各自特点: 批处理架构：高延迟性的，数据的处理量很大，数据都是PB,EB,ZB的级别，显然，案例需求这个批处理架构不合适处理这个场景 流处理架构：如果用流处理架构，只能使用现在的访问信息，对于用户历史访问行为，流处理架构不能处理，我们只能忽略，这种可能导致我们服务头发错误的广告信息。 那么既然选择批处理架构和流处理架构都不能满足，那么我们该如何解决这种问题(⊙o⊙)?呢？ ###Lambda架构 来源：Lambda j架构是Twitter工程师提出的大数据处理架构。这一架构的提出是基于南森-马刺(Nathan Marz)在BackType 和Twitter 上的分布式数据处理系统的经验。 Lamdba 架构使开发人员能够构建大规模分布式数据处理系统。具有很好的灵活性和可扩展性，也对硬件故障和人为失误有很好的容错性。 Lambda 架构总共有三层系统组成：批处理层（Batch Layer)，速度处理层（Speed Layer），以及用于响应查询的服务器层（Serving Layer)，其架构以及处理流程如下：  上图中，Lambda 架构每一层都有自己所肩负的任务。 Batch Layer 存储和管理主数据集（不可变数据集或者历史数据集)，和预先批处理计算好的视图。 1）.批处理层一般是使用可处理大量数据的分布式处理系统预先计算结果。它通过处理所有的已有的历史数据来实现数据的准确性。这意味着它是基于**完整的数据集来重新计算**的，能够**修复任何错误**，然后**再更新现有的数据视图**,输出通常存储在**只读数据库中**，**更新则完全取代现有的预先计算好的视图**。 2）.速度处理层会实时处理新来的数据，速度层通过提供最新数据的实时视图来最小化延迟。速度层所产生的数据视图可能不如批处理层最终生成的视图那样准确或者完成，但是它们几乎在收到数据后可以立刻使用，而当同样的数据在批处理层处理完成后，在速度层的数据就可以被替换掉了。 从上面的分析:本质上，速度层弥补了批处理层所导致的数据视图滞后。比如说，批处理层的每个任务都需要 1 个小时才能完成，而在这 1 个小时里，我们是无法获取批处理层中最新任务给出的数据视图的。而速度层因为能够实时处理数据给出结果，就弥补了这 1 个小时的滞后。 所有的批处理层和速度层处理完的结果都输出存储在服务层中，服务层通过返回预先计算的数据视图或从速度层处理构建好数据视图来响应查询。 回到刚才的问题，我们如何既能做到实时分析用户新的网站浏览行为又能兼顾到用户的网站浏览行为历史(⊙o⊙)?呢？这种情况下，我们可以选择Lambda架构。 **的新用户行为数据都可以同时流入批处理层和速度层**。批处理层会**永久保存数据并且对数据进行预处理**，得到我们想要的**用户行为模型**并写入服务层。而**速度层也同时对新用户行为数据进行处理**，得到**实时的用户行为模型**。 根据上面的需求，应该对用户投放什么样的广告，当这个查询的时候，我们从服务层既可以查询服务器层中保存好的批处理输出模型，也对速度层中处理的实时行为进行查询，这样我们就可以得到一个完整的用户行为历史了。如果一个查询如下图，批处理层兼顾了数据的完整性，通过速度层弥补了批处理层的高延迟性，让整个查询具有实时性。 根据Lambda 架构在一线大公司的应用已经十分的广泛，下面可以罗列一下具体的使用场景： #####Twitter 的数据分析案例: Twitter 在欧美十分受欢迎，而Twitter中人们所发的Tweet里面的Hashtag也常常引爆一些热搜词汇，也就是Most Popular Hashtags 下面看看他们如何使用Lambda架构来实时分析这些Hashtags，如下图：  在这个案例中，使用twitter 4J（```http://twitter4j.org/en/```）的流处理API 抓取实时的Twitter推文，同事利用Apache Kafka 将抓取到的数据保存并实时推送给批处理层和速度层，大概流程就是： User New Twitter -> Apache Kafka -> Batch&&Speed Layer 因为Apache Spark 平台中，既有批处理架构，也兼容了流处理架构，所以在选择批处理层和速度层凑采用Apache Spark 来读取来自Apache Kafka的数据。 批处理层和速度层在分析处理好数据后会将数据视图输出存储在服务层中，我们将使用 Apache Cassandra 平台来存储他们的数据视图。Apache Cassandra 将批处理层的视图数据和速度层的实时视图数据结合起来，就可以得到一系列有趣的数据。 例如，我们根据每一条 Tweet 中元数据（Metadata）里的 location field，可以得知发推文的人的所在地。而服务层中的逻辑可以根据这个地址信息进行分组，然后统计在不同地区的人所关心的 Hashtag 是什么。 时间长达几周或者的几个月的数据，我们可以结合批处理层和速度层的数据视图来得出，而快至几个小时的数据我们又可以根据速度层的数据视图来获知，怎么样？这个架构是不是十分灵活？ 对于初创公司来说，Lambda架构也是可以采用的。
(六)CAP定理：三选二，架构师必须学会的取舍 作者: lovingyu_er 时间: 2019-05-08 00:02:00 分类: 大规模数据处理 评论 #####CAP定理：三选二，架构师必须学会的取舍 详情可以参考文章:```https://darrykinger.com/index.php/archives/69/```
(五)发布/订阅模式：流处理架构中的瑞士军刀 作者: lovingyu_er 时间: 2019-05-07 23:07:00 分类: 大规模数据处理 评论 发布/订阅模式,又可以称为生产者/消费者模式,(Publish/Sbuscribe Pattern ) 或者(Pub/Sbu) 首先介绍几个概念:消息和消息队列 ##消息 在分布式架构中,架构中的每个组件(Componet)需要相互联系沟通.组件可以是后台的数据库,可以是前端浏览器,也可以是公司内部不同的服务器端(Service Endpoint),各个组件之间是通过依靠发送消息互相通讯的 ** Componet A ---------------send messsage------------------> ComponetB ** ** Componet B ----------------send Message ------------------->Componet A** 其中,发送的消息,其格式可以是任意的,比如:json,xml 或者自定义的格式 ##消息队列 消息队列在发布/订阅模式中,起到的是一个持久化缓冲(Durable Buffer )的作用. 消息的发送方可以发送任意消息到这个消息队列中,消息队列在接受到消息以后,会讲消息存储好,一直到消息的接收方确认已经从这个消息队列中拿到了这个消息,才会将消息从消息队列中删除. 有的消息系统平台,比如Apache Kafka 它能够让用户自定义消息队列对消息的保留时间. 有了消息队列以后,整个消息的流程就变成了下图:  ##发布/订阅模式 发布/订阅模式:**消息的发送方可以讲消息异步地发送给一个系统中不同的组件,而无需知道接收方是谁**. 再发布/订阅模式中,发送方被称为发布者(Publisher),接收方则被称为订阅者(Subscriber). 发布者只需要将消息发送到消息队列中,订阅者可以取出自己感兴趣的消息. 在发布/订阅模式中,可以有任意多个发布者,也可以有任意多个订阅者,它们是多对多的关系,如下图:  采用这种数据处理模式,作为消息的发送者不需要考虑以后后期有多少新增需要同样数据的团队,只需要设计好自己提供的数据的内容和格式,在每一次需要发送消息的时候,发送到消息队列中就可以了.任何对这个感兴趣的团队,经过授权都可以从消息队列中自行读取. ##优点和缺点: ###优点 1)松耦合性(Loose Coupling ):消息的发布者和消息的订阅者在开发的时候,完全不需要知道对方的存在,可以进行独立的开发,只需要定义好数据的格式即可 2) 高伸缩性(High Scalability ):发布/订阅模式的消息队列可以独立的作为一个数据存储中心存在.在分布式的环境中,更是消息队列可以扩展至上千个服务器中.Linkedin 公司在2016年维护和开发了将近1400个消息队列 3)系统组件间通信更加的简洁:发布者不需要为每一个新订阅者准备消息格式,只要知道了消息队列中保存消息的格式,发布者就可以按照这个格式发送数据,订阅者只需要按照这个数据格式接受消息即可. ###缺点 1)整个数据模式中,我们不能保证发布者发送的数据一定发送到订阅者.如果要保证数据一定送达的话,需要开发者实现自己的响应机制. 使用发布/订阅模式的一些公司: google -> CLoud Pub/Sub AWS -> Amazon Simple Notifiation Service (SNS) linkedin ,Uber -> Apache Kafka Redis也有消息发布订阅功能 下面着重介绍Apache Kafka ####介绍: 在Apache Kafka中,消息的发送发被称为生产者(Producer) 消息的的接收方被称为消费者(Consumer)而,消息直接被称为Topic . Aapche Kafka有一个响应机制,判断消息的接收方是否接受了消息采用的Log offset 机制. Log offset 机制的介绍: 假设发送方连续发送了 5 条数据到消息队列 Topics 中，这 5 条消息被编号为 10000、10001、10002、10003 和 10004。 如果接收方读取数据之后回应消息队列它接收的 Log offset 是 10000、10001 和 10003，那么消息队列就会认为接收方最多只接收了消息 10000 和 10001，剩下的消息 10002、10003 和 10004 则会继续发送给接收方，直到接收方回应接收了消息 10002、10003 和 10004。 ### 发布/订阅模式的使用场景: 1)消息的发送方需要向大量的接收方广播消息 2)系统中某一个组件需要与多个独立开发的组件或者服务进行通信,而这些独立开发的组件或者服务可以使用不同的变成语言和通信协议 3)系统的发送方在向接收方发送消息以后,无需接收方进行实时响应 4)系统中对数据一致性的要求只需要支持数据的最终一致性(Eventual COnsistency)模型. Tips:如果系统的发送方在向接收方发送消息以后,需要接收方进行实时的响应的话,那么绝大多少情况下,都不需要考虑使用这种模型
(四)workflow设计模式 作者: lovingyu_er 时间: 2019-05-07 01:28:00 分类: 大规模数据处理 评论 在上一节中，主要介绍了有边界数据，无边界数据，事件事件，处理事件，批处理，流处理（实时处理，准实时处理)等一些比较常见的基本概念，可以帮助让我们根据实际需求确认是用批处理或者是流处理，或者是这两种情况的融合．这一节我们主要讲解大规模数据处理中常见的四中设计模式： 复制模式，过滤模式,分离模式,合并模式,下面我们进行逐一的讲解 学大数据处理的时候，比较常见的案例就是ＷordCount的案例：一个单词集合作为输入，数据处理后是统计单词出现的次数．中间只是一次数据处理的转换,案例如下:  图片来自ｇeekbang 这种场景比较简单，实际的生活中，要比这个不知道复杂多少倍． 下面根据一些案例讲解处理系统中的集中设计模式: ###复制模式(Copier Pattern) 复制模式通常是将单个数据处理模块中的数据，完整地复制到**两个或更多的数据处理模块**中，然后再由**不同的数据处理模块进行处理**。工作流系统图通常如下图所示。  但我们处理大规模数据的时候，需要对同一个数据集采用多种不同的数据处理转换，我们就可以优先考虑**复制模式** 案例：youtube的视频平台，一个视频很多时候会提供不同的分辨率720p,1080p，4k等，根据用户带宽的不同，会讲视频转换成不同的高低分辨率格式的视频，或者生成360这样的视频给用户．在youtube的视频列表中，如果你将鼠标放到某个视频的上方，会自动播放已经生成好的动画缩略图(Animated GIF Thumbnail),在后台，一个视频可以被自然语言理解(NLP)的数据处理模块分析，自动生成视频的字幕（有条件可以看youtube上的视频演讲).根据这个视频，做相关推荐（youtube 的推荐系统真的很让人恐怖),它的工作流程可以看成下图:  这个案例就照应了上面的Copier Pattern ，一个视频可以被不同的处理架构进行分析处理 ###过滤模式(Filter Pattern): 过滤模式的作用就是过滤掉不符合特定条件的数据. 数据经过这个数据处理模块之后，输出的就是只剩下符合条件的数据．工作的流程如下:  如果我们针对一个数据集中某些特定的数据采集数据的时候，我们就可以有限考虑过滤模式． 案例: 商城会员系统:一个商城有几种等级的会员:五星会员(FIve-stars Membership),金牌会员(Golden Membership)和钻石会员(Diamond Membership) 如果我们需要对五星级的会员发送邮件邀请通知，这个时候，我们就可以通过过滤模式将五星级的用户从所有的用户中筛选出来. All Users -> filter ->filterd data set ->five-stars membership->EMail 邮件通知 ###分离模式(Splitter Pattern) 如果你不想过滤掉不符合条件的数据，你想要讲数据分类为不同的类别来进行处理时，这个时候，就可以考虑使用分离模式，其工作流程图如下：  我们以过滤模式的商城会员为例，分离模式会讲数据集进行分组，分成商城会员的三组（五星，金牌，钻石),对三种会员进行email.Five-stars.Notification email.gold notifiaction email.diamond.Notification 通过splitter 进行分离，然后再进行email notification 处理 注意，这里的分离，可以讲相同的数据放到不同的处理模块中去的 比如data set 中有Ａ,B,C三个数据集，我们可以通过一定的splitter 讲Ａ,B 进行workflow1处理,那么也可以Ｂ,C 进行workflow2处理，这种情况很常见．常见的有银行的通知：你选中了邮件和短信通知，那么这两种银行都可以同时处理发送给你． ###合并模式(Joiner Pattern) 合并模式，有点想开发中的两个ＡＰＩ的兼容合并处理成一种新的格式的 New API ;合并模式讲多个不同的数据集转换集中到一起，成为一个总的数据集，然后再讲这个数据集放到一个工作流中进行处理．  以美团外卖的车的数量来预测美团的股市价格，这里输入的数据有自己团队在街上排到的美团外卖图片和第三方公司提供的美团外卖车辆图片，那么要合并这两个数据来源，然后再处理 A+B -> Joiner处理->All Data ->Ingestion 这就是所谓的合并模式 本节也就讲到这些比较简单的数据处理模式，下一节我们将讲解订阅和发布模式在流处理中的作用.
(三)大规模数据批处理和流处理的区别 作者: lovingyu_er 时间: 2019-05-06 20:52:00 分类: 大规模数据处理 评论 大数据处理无论如何也绕不开的两种处理模式: 1）批处理(Batching Processing) 2) 流处理(Streaming Processing) 大规模的视频流系统，大规模物联网（loT)数据监控系统等大数据系统的大量出现，导致了大数据处理越来越受到关注 为了更好的理解大数据的处理模式，先介绍几个概念 #####有边界数据和无边界数据 现在大数据有两种形式：一种是无边界数据（Unbounded Data) ；一种是有边界数据（Bounded Data) 无边界数据的定义：一种不断增长的数据，无限增长的数据集，无法判断到底什么时候这类数据就停止发送 比如：移动支付数据，只要网络一直存在，这种交易就不会停止，无法确定最终数据的停止发送．也可以称之为：流数据（Streaming Data) 有边界数据：一种有限的数据集，常见的就是数据库中已经保存好的数据．例如：数据库中的数据，或者CSＶ格式的数据． 比如：如果我们从无边界数据中取出一定时间间隔的数据，比如从２018-01-01 到２０１８-01-02的之间的数据，那边间隔之间的数据就成了右边界数据了． 可以这样理解：有边界数据是无边界数据的一个子集． ####事件时间和处理时间 大数据中，比较注重的一个因素：时域(Time Domain) 我们需要处理的数据都会有两种时域（ＴＩｍｅ Ｄomain): 事件时间(Event TIme) 和处理时间(Precessing TIme). 事件时间(Event TIme ):一个数据实际产生的时间． 处理时间(Precessing TIme):处理数据的系统架构实际接受到这个数据的时间点 比如：点外卖，下单时间是11:30 ，由于网络信号不好，外卖系统的服务器收不到你的下单指令，外卖客户端一直Retry...到了11:45，网络正常，外卖系统开始处理支付请求．那么这里的事件时间是11:30 ，处理时间是11:45 ##批处理 数据的批处理：一系列相关联的任务按照顺序（或者并行）一个接着一个地执行．批处理的输入是一段时间内已经收集和保存好的数据，每次批处理所产生的输出，也可以作为下一次批处理的输入． 绝大部分情况，批处理的都是有边界数据，同样，输出的结果也一样是有边界数据． 在批处理中，我们更注重的是数据中的事件的时间． 常见的案例; 1. 支付的年账单，支付宝将过去一年中的消费数据存储起来，这些是有边界的数据，数据中包含了每笔交易的时间，也就是交易这个事件发生的时间，经过业务处理，得到了每个人的账单的详情信息． 2. 银行信用卡的消费账单，会在每个账单日前后处理，根据消费账单和最低还款额度都是预定义好在一个月间隔内执行一次，按照时间间隔进行运行． ######批处理常用的场景: 批处理的特点： 大部分处理的是有边界数据，故而在下面场景中用的比较多： 1).日志分析：日志系统一般都是在一定时间段内收集的（比如nginx的访问日志),而日志的数据处理分析是在不同的时间内执行，以得出有关系统的一些关键性指标． 2)计费应用程序:上面的银行信用卡账单的案例 3)数据仓库:数据仓库的主要目标是根据收集好的数据事件时间，将数据信息合并为静态快照(static snapshot),并将它们聚合为每周，每月，每季度的报告等. Google MapReduce 衍生出来的开源项目Apache Hadoop或者 Apache Spark等开源架构都是支持这种大数据处理架构的． 这种处理模式的另外一个特点就是：数据的处理时间比较长，几个小时，几天，几周都不等，如果需要对用户的请求快速响应，我们就要考虑流处理了 ##流处理 可以这样理解：系统需要接收并处理一系列连续不断变化的数据．比如：旅行预定系统，处理社交媒体更新的有关系统等等 与批处理不同的是，由于起实时性，其一般处理的都是最新的数据，＂新鲜的数据＂，也就是无边界数据，其对时域(Time Domain)的关注点依赖于业务的需求． 常见的案例: 1)像网页监控系统这样的流处理系统要计算网站的 QPS，它所关心的更多是处理时间，也就是网页请求数据被监控系统接收到的时间，从而计算 QPS。 2)而在一些医疗护理监控系统的流处理系统中，他们则更关心数据的事件时间，这种系统不会因为接收到的数据有网络延时，而忽略数据本来产生的时间。 从上面的一些场景我们可以总结流处理的特点: 1.足够快，低延迟 2.响应时间应该以毫秒(或者微妙)为单位计算．特别是我们常常接触到的搜索引擎，系统必须以用户输入关键字以后一毫秒级的响应返回结果给用户 3.基于大规模数据的特点，那么流处理架构一般又有高吞吐量的特点 流处理快的根本原因是:**数据到达磁盘之前就对其进行了分析** 流处理系统的架构，处理数据的快慢可以分成两种概念： １．实时处理(Real-Time Processing )：当处理架构拥有一定时间间隔的响应速度(比如毫秒级)内产生逻辑正确的结果. 2. 准实时处理(Near Real-Time Processing ):处理架构能够在以分钟为单位的延时完成数据的处理． 常见的场景: <ul> <li>实时监控：捕获和分析各种来源发布的数据，如传感器，新闻源，点击网页等。</li> <li>实时商业智能：智能汽车，智能家居，智能病人护理等。</li> <li>销售终端（POS）系统：像是股票价格的更新，允许用户实时完成付款的系统等。</li> </ul> 如今的开源架构生态圈中，有Apahce Kafka,Apache Flink，Apache Storm ,Apache Samza等等，都是比较流行的流处理架构平台．