1.Lambda介绍：
提出者：Twitter工程师Nathan Marz提出，同时是Storm项目发起人
Lambda作用：Lambda系统架构提供了一个结合实时数据和Hadoop预先计算的数据环境下的混合平台，以提供一个实时的数据视图
2.分层架构
架构图如下：
1.批处理层
概述：离线处理数据，服务层会根据批处理层生成批处理视图，接着通过前端的交互式工具进行查询模型构建的视图（批处理层可以通过数据仓库建模的方式来将数据进行可视化建模，例如构建用户画像）
特点：
1.数据不可变（hdfs的特点，只可追加不可修改）
2.可进行任何计算：
1)可以有任何类型的输入和输出，并且在中间的转换过程中可以分成灵活的定制和配置
2)例如一个MapReduce种你可以实现多个MapReduce作业，或者一个MapReduce中可以实现多个map或者多个reduce，reduce之后再map，把作业串接起来，形成一整个工作流来进行复杂的作业
3)在spark当中也是一样，spark作业本质也是分成map和reduce两个阶段，只不过在每个阶段中已经提供了非常丰富的已有的一些实现或者算子能够让你基于这些算子快速的进行数据处理和分析，它在调度上是整体进行一个图的调度。（比如map端有map算子或者flatmap，或者filter，在reduce阶段有reducebykey，groupByKey或者sortByKey等等一系列算子，每一种map或者reduce阶段的操作其实本质上会生成一个RDD，它就不断去转换这个RDD，也可以完成一个复杂的数据处理）
所以说MapReduce和spark可以进行任何计算。
3.水平扩展：
得益于整个Hadoop集群主从架构，当我们增加更多的slave节点，也就使得hdfs存储量会更大，所以会存储更大的数据量，同时会扩展yarn的集群，使得它的MapReduce和spark并行处理能力也得到了提升。
4.高延迟：
通常是T+1的处理，也就是说我们今天处理的数据是昨天汇总的数据，通常很多大数据平台进行批处理都是在凌晨来进行跑批量，一天从早上9点到下午6点或者到晚上10点都是业务窗口期，而凌晨到5点之间就是批处理跑数据的时间，跑完之后第二天就可以看到前一天批处理得到的结果，所以说它是高延迟。延迟时间一般是4到5个小时。
组件：
1.flume日志收集
从web日志采集到hdfs，如下图：
2.sqoop日志收集
从关系型数据库的数据采集到hdfs，如下图：
分布式存储系统：
hdfs存储适合128M的大文件，不适合小文件，因为namenode会将所有元数据加载到内存的，如果小文件太多，其实会影响namenode的访问效率和扩展性，那么这时批处理层可以使用分布式存储系统HBASE来存储结构化数据。
HBASE和HDFS是互补的，HDFS适合连续的流式访问，但是它不能更新，而HBASE可以满足基于Rowkey的随机访问，所以HBASE是在随机读写方面的效率非常高的，还可以满足海量数据的存储。
如下图：
分布式计算：
MapReduce和spark之间的区别：
1.调度方式上
MapReduce是每个作业单独调度的，而spark是图调度的，根据整个RDD血缘关系进行整体的图调度，所以效率比MapReduce要优。
2.MapReduce计算中，map到reduce之间的shuffle过程会进行大量写磁盘操作，reduce阶段也会写HDFS，效率非常低。而spark全部是基于内存
3.对开发来说，开发spark更加方便，因为它提供了一些方便的算子，比如map，flatmap，只需要去调用这些函数，输入一些参数，就可以得到一个你想要的的结果，基于这个结果又
进行作为下一个函数的参数来输入，开发起来非常地方便。
产生视图:
数据集通过mr或者spark计算的结果推送到HDFS，HBASE，redis缓存。前端直接从redis去提取视图的结果。
数据序列化:
序列化：就是把内存的数据导出到磁盘，从磁盘读回到内存，就是反序列化。
数据通常是按照什么样的方式来序列化？
在开发过程中，你指定的schema或者类型，你的Java对象，比如指定的是string类型，就是按照string来进行序列化，
为数据设置schema（元数据）：
1.保证数据一致性，处理过程中是处理同一个schema（json自带schema）
2.保证数据合法性验证（读写规范）
3.避免数据损坏
选择序列化框架：
1.Thrift（Facebook）
hive自带了thrift，所以能通过jdbc直接访问hive
2.Protocol buffer（Google）
3.Avro（Apache）
Avro处理格式用的非常多的，通常会把Avro数据格式作为大数据平台通用存储的一种格式，它的通用性也比较好
视图存储数据库:
1.HBASE：
强调CP（一致性）
存储量大，使用HBASE，但HBASE不能进行汇总，这时可以采用hive做映射
2.Cassandra：
强调AP（高可用性），它是分布式，也是nosql的一种，但它的架构没有一个固定主节点，主节点是漂移的一个状态，它更加强调其他的可用性，挂掉了一个节点，照样可以对外提供服务
3.Impala：
满足前端交互式BI，提供了非常高效专用的sql引擎，架构师mpp架构，更符合BI多维的使用场景。
4.Rdis/memcache：
高效的向前端展现可以使用redis，但是可靠性不高，尤其是memcache，完全是存放内存中的，一旦宕机，数据就会丢失，但是它主要满足的就是非常高效和低延迟。redis相对来说更强大一些，比如支持多类型存储，持久化磁盘。
5.MySQL
2.实时处理层
以上是实时处理的简图，它跟批处理很大的不同点是：批处理是先把当天或最近一段时间的批量数据存储在HDFS，HDFS会存储所有的历史数据，再基于这些数据进行mr或spark计算。而流处理是对实时产生的点击流实时的进行处理，没有延迟。
实时层特点：
1.流式处理:
分两种：
1)spark-streaming微批次，可以设置批次的间隔时间，间隔时长设置非常小的时候，实际就是流处理。
2)storm：真正的流处理
2.持续计算：对批处理来说会有预期的起始和结束的时间，而实时计算不会停止
3.存储和分析某个窗口期内的数据：实时处理也可以理解为非常小的批次，但一般来讲是秒级，spark可以做到的最低粒度是秒级，而storm可以做到毫秒级
4.最终正确性：保证了最终的结果是正确的，有些算法很难实时运算，此时采用估算值即可。
实时数据收集
和批次数据采集基本一样，采用flume的OG或者NG，使用NG，把collector改为agent即可。flume数据在批次处理是直接写到hdfs，而在流处理中，保证数据处理的吞吐量，通常会采用kafka，因为kafka和许多流处理框架结合的比较好，并且flume也支持kafka的输出，flume默认有kafka sink的实现，可以直接把数据给到kafka，kafka再写入到storm中进行消费
实时数据分析
加入我们选择的是storm作为流式处理框架，那么构建的是Topology(拓扑结构)，在Topology中有一些组件（spout，bolt），spout把数据接收过来，然后发送给后端，这一步是分发数据的。而bolt实际做一些Transformation（转换）操作，所以会有很多bolt，bolt1处理完给bolt2等。把这一系列流程连接起来，就是拓扑结构了。
数据源像水龙头一样，storm处理的数据单元，叫做tuple，每一个数据是一个元祖，不断地流入进来，然后经过spout或者bolt源源不断地进行处理
实时处理层：视图存储数据库
和批次处理一样的，实时存储数据库如下：
HBASE
Cassandra
Impala
Redis/memcache
MySQL
和批次处理不一样的是，实时地进行数据插入。
3.服务层
对批处理层和实时处理层已经得到的数据结果基础之上，来把最终结果进行推荐或者展示等等
服务层特点
1.支持随机读
从批处理或者实时处理的视图中把结果进行合并，放到缓存中，然后通过web服务进行展现
2.需要在非常短的时间内返回结果
一般会用到一些内存数据库或者缓存机制等
3.读取batch layer和speed layer结果，并对其归并
3.应用
1.Lambda架构的实现demo1
这个案例是通过Lambda架构，去实现对Linux的一些操作日志进行审批，比如一些非法的行为，或者影响性能的操作，那么我们可以这样的架构来发现，对Linux性能也同时可以监控，比如磁盘使用超标或者用到大量虚拟内存，都可以用这样一套架构实时采集，实时报警，实时展现，大大方便了我们系统管理员来进行系统的维护。
这个demo中，首先在数据采集左边那部分，中间上半部分是批处理，中间下半部分是流处理。
左边部分采集用flume agent，采集给kafka。kafka给批处理层的CAMUS，(CAMUS是用来把kafka数据读取到hdfs或者mr，所以CAMUS就是一个MapReduce读取作业)读取完成后再给下一个MapReduce作业，mr结束后写入hdfs，多个MapReduce作业的调度使用Oozie进行统一调度，最终结果写入hbase。
实时层同理，将kafka的数据实时计算，结果存储到HBASE。
右边部分是服务层，服务层用来展现，展现用到kettle（etl框架），使用它将HBASE数据读进来，再进行前端展示（例如柱状图，饼状图等）
2.Lambda架构的实现demo2
第二个实例是要进行图像的展现
中间上半部分是数据收集层：kafka，采集到的数据给批处理层和实时层，左边上半部分是批处理层，右边是实时处理层。
批处理：pixel处理的是图片，S3是亚马逊的分布式存储系统，再通过spark作业进行批处理
流处理：storm集群，bolt实时对数据转换
Shared Libraries：spark和storm之间共享的库。结果spark写入到历史索引，storm写到实时索引
3.Lambda架构的实现demo3
应用举例：用户卡欺诈系统，系统架构如下图
1.数据采集：
判断用户是否为欺诈用户，我们可以通过前端埋点实时采集到用户请求行为，可以通过flume采集到hdfs，交易数据存储到MySQL或者Oracle，这些数据我们可以加载到HBASE活hdfs上。
2.建模：
构建用户画像，了解这个用户的特征是否是欺诈的用户，可以抽取一些特征值，借助一些机器学习的算法来进行分类判断，计算过程可以通过MapReduce或者spark
3.实时采集：
通过flume对接kafka消息队列，kafka来提供消息的可靠和高吞吐，然后将数据发送给storm，storm里面构建一个拓扑，这个拓扑回去计算这个用户他的行为跟我们前面的批处理的结果进行比较，最后把结果推送到redis等缓存区。然后让我们的系统执行下一步操作，如果结果是欺诈用户，就自动冻结他的资产或者进行告警灯。
4.批处理层：
4.Lambda在推荐系统中的应用：
1.批处理层：放模型
2.实时层：实时采集用户访问行为，然后给用户实时推荐
具体框架图如下：
上图中MapReduce可以用spark替代，storm可以用sparkstreaming来替代
