大规模数据处理实战--基础知识

最新推荐文章于 2024-01-11 01:11:50 发布

hixiaoxiaoniao

最新推荐文章于 2024-01-11 01:11:50 发布

阅读量1.3k

点赞数

分类专栏：分布式

本文链接：https://blog.csdn.net/hixiaoxiaoniao/article/details/89815262

版权

分布式专栏收录该内容

28 篇文章 0 订阅

订阅专栏

SLA

服务等级协议 Service-Level Agreement 服务等级协议
是系统服务提供者Provider对客户Customer的一个服务承诺
包括可用性，准确性，系统容量，延迟

1.可用性 Availabilty
表示系统可用的时间

2.准确性 Accuracy

是指我们设计的系统服务中，是否允许某些数据是不准确的或者是丢失了的，如果允许这样的情况发生，用户可以接受的概率是多少，系统架构会以错误率Error Rate来定义这一项SLA

可以采用性能测试，或者查看系统日志来评估

3.系统容量Capacity
通常指系统能够支付的预期负载量是多少，一般以每秒的请求数为单位来表示
评估系统QPS的方案

使用限流的方式，一台机器1000，N台机器就是N*1000了
系统交付之前进行性能测试，但要注意缓存对测试结果的影响
分析系统在实际使用时产生的日志

4.延迟 Latency
指系统在接收到用户的请求到响应这个请求之间的时间间隔
在定义延迟的SLA时，会看到SLA有p95或者p99这样的声明
这里的p是percentile，就是百分位的意思，p95表示延迟是1秒的话，那么100个请求有95个是小于1秒的

三个指标

可扩展性 Scalability
包括水平扩展 Horzontal Scaling
垂直扩展 Vertical Scaling

一致性
强一致性
弱一致性，系统中某个数据被更新后，等待一个时间窗口才变成新值
最终一致性，在没有更新的条件下，最终所有的访问都是最后更新的值

此外还有顺序一致性
因果一致性
支付宝，银行转账，12306买票，其实不是强一致性的

持久性
数据一旦被成功存储就可以一直继续使用，即使系统中的节点下线，宕机或者数据损坏也是如此
有些系统支持机器/节点级别的持久性，也有些是集群，有些根本就没有持久性
提高持久性的做法就是复制，把数据复制到不同的节点上

分布式系统中，还有一个持久性的概念是消息持久性
节点需要经常互发送消息去同步以保证一致性
消息通讯由分布式消息服务完成，包括两个方案

当消息服务的节点发生了错误，已经发送的消息仍然会在错误解决之后被处理
如果一个消息队列声明了持久性，即使在消息发送之后掉线，仍然会在重新上线之后收到这个消息

批处理和流处理

所有的数据都可以分为两种
无边界的数据(Unbounded Data)
有边界的数据(Bounded Data)

在处理数据的时候，我们要处理的任意数据都有两种时域
事件事件(Event Time)，一个数据实际产生的时间点
处理事件(Processing Time)，是处理数据的系统架构实际接收到的这个数据的时间点

批处理
处理的输入是有边界的，输出的结果也是有边界的，关心的是数据的事件事件
如支付宝的年度账单
批处理的适用场景

日志分析，日志系统是在一定时间段内收集的，而日志的数据处理分析是在不同的时间内执行，得出有关系统的一些关键性能指标
计费应用程序，会计算出一段时间内一项服务的使用程度，并生成计费信息，如银行在每个月末生成的信用卡还款单
数据仓库，主要目标是根据收集好的数据事件事件，将数据信息合并为静态快照(static snaphost)，并将他们聚合为每周，每月，每季度的报告等

谷歌的MapReduce以及Hadoop，Spark等架构都是支持这种大数据的批处理架构
这种任务一般延迟高，如果要求快速响应，则可以使用流处理/实时处理

流处理
流处理的输入是无边界的，流处理系统关系的数据时间需要根据具体场景耳钉
像网页这样的流处理系统要计算网站QPS，关心的是处理事件
医疗护理系统流处理中，关心的是事件事件
流处理的特点是足够快以便能够处理来自各种数据源的大规模数据，其原理是在数据到达磁盘之间就进行了处理

当流处理架构拥有在一定时间间隔(毫秒)内产生逻辑上正确的结果是，这种架构可以定义为实时处理
如果是分钟级别的延迟，就是准实时处理
流处理架构特点是高吞吐量和低延迟

流处理架构的适用场景

实时监控，铺货和分析各种来源发布的数据，如传感器，新闻源，点击网页等
实时商业智能，智能汽车，智能家居，智能病人护理等
销售终端POS系统，像是股票价格更新，允许用户实时完成付款的系统等

开源生态圈中，Apache Kafka，Flink，Strom，Samza等都是流处理架构平台

Workflow

将不同的处理模块连接在一起，最后得出一个自己需要的结果的有向无环图(Directed Acyclic Graph)，就称为一个工作流系统 Workflow System

在工作流系统的每个处理模块里，系统要执行的才做有可能不是单单一个数据转换这么简单的操作，是需要将多个不同的数据集合并在一起，也需要将不合格的数据过滤掉
Apache Spark1.4以上版本，就有完整的工作流图
下面介绍四种不同的工作流设计模式，复制模式，过滤模式，分离模式，合并模式

复制模式(Copier Pattern)
通常将单个数据处理模块中的数据，完整的复制到两个或者更多的数据处理模块中，然后再由不同的数据处理模块进行处理，如下图所示

在处理大规模数据时，需要对同一个数据集采取多种不同的数据处理转换，优先考虑复制模式
以YouTube为例，视频平台很多时候会提供不同分辨率的视频，4K或者1080P的视频提供给带宽高的用户，在网络很慢时提供360P这样的视频格式
一个视频数据集可能会字段语言理解NLP 的数据处理模块分析，用以自动生成视频字幕，还有可能被视频分析的处理模块分析，用以产生更好的内容推荐系统，它的整个工作流如下

过滤模式(Filter Pattern)
过滤掉不符合特定条件的数据
针对一个数据集中某些特定数据采取数据处理时，可以优先采用过滤模式
在商城中有各种会员，现在要求只针对钻石会员才发出邀请，这时候采用过滤模式，将钻石用户从所有用户中筛选出来

再这个工作流系统中，一个数据处理模块会将输入的数据集过滤成符合条件的数据，然后传输到下一个数据处理模块进行单独处理

分离模式(Splitter Pattern)
如果在处理数据集时候并不想丢弃里面的任何数据，而是想把数据分类为不同的类别来进行处理
分离模式不会过滤任何数据，只是将原来的数据集分组了
假设系统针对商城不同的等级的用户，做不同的活动邀请
需要注意的是，分离模式下，同样的数据是可以被划分到不同的数据处理模块的

数据B是可以同时划分到工作流1 和工作流2中
比如用户可以通过勾选短信通知，邮件通知的方式来提醒用户一笔交易成功，如果用户同时勾选了这两种方式，那么属于这个用户的交易信息就会收到短信和邮件两个通知

合并模式(Joiner Pattern)
将多个不同的数据集转换集中到一起，成功一个总数据集，然后将这个总的数据集放在一个工作流中进行处理

以美团外卖电动车数据评估股价为例
数据接入在这一处理模块中，我们的输入数据有自己团队在街道上拍摄到的美团外卖电动车图片，以及第三方公司提供的美团外卖电动车图片
我们打算先整合所有数据，然后再进行其他数据处理的话，工作流系统如下所示

发布-订阅模式

两个基本的概念，消息和消息队列
消息队列发送流程如下

发布/订阅模式，是消息的发送方可以将消息异步的发送给一个系统中不同组件，而不需知道接收方是谁

如果A系统做了改动，B和C系统根据这个改动做相应的动作
这个是观察者模式Observer Pattern，系统中的各个组件紧耦合Tightly Coupled
采用发布/订阅模式后，整个系统就解耦合了

发布/订阅模式的优缺点

松耦合Loose Coupling，消息的发布者和消息的订阅者在开发的时候完全不需要事先知道对方的存在
高伸缩性High Scalability，消息队列可以横向扩展，2016年Linked维护了1400个消息队列
系统组件通讯更加简洁，只要知道消息队列中保持消息的格式，订阅者就按照这个格式接收即可

缺点是
不能保证发送的消息一定会送达订阅者，如果要保证数据一定送达，需要开发者自己实现响应机制

Kafka架构，Producer，Consumer，消息队列Topic

Kafka在判断消息是否接收是利用了Log offset机制
假设发送方连续发送了5条数据到消息队列Topic中，编号分别为100，101，102，103,104
如果接收方读取数据之后回应消息队列它接收的Log offset是100,101,103，那么消息队列会认为接收方最多只接收了100,101，剩下的102,103,104会继续发送给接收方，直到收到了确认回应

发布/订阅模式适用的场景