BigData | 大数据处理基本功（上）

Index

• 如何进行系统评估
• 流处理与批处理的区别
• 什么情况下应该使用批处理
• 什么情况下应该使用流处理

如何进行系统评估

1. SLA-服务等级协议

SLA，即Service-Level Agreement，中文名称为服务等级协议，就是系统服务提供者（Provider）对客户（Customer）的一个服务承诺，主要承诺的内容有4个：可用性（Availability）、准确性（Accuracy）、系统容量（Capacity）以及延迟（Latency）。

逐一解释一下上面的指标：

可用性（Availability）：

指的是系统服务可以正常运行所占的时间百分比。一般来说很难设计一个"100%可用性"的系统的，一般都是会有服务中断（Service Outage）的时候，常见的可用性水平：

1）"四个9“：即99.99% Availability，意味着有0.01%的可能性系统服务会被中断，即一天中有8.64秒（24小时 X 60分钟 X 60秒 X 0.01%）的服务中断时间，被行业认为是高可用性（High availability）。

2）"三个9"：即99.9% Availability，意味着有0.1%的可能性系统服务会被中断，即一天中有86.4秒（24小时 X 60分钟 X 60秒 X 0.1%）的服务中断时间。

准确性（Accuracy）：

指的是系统内某些数据不准确or丢失的情况占比，一般拿错误率（Error Rate）来衡量，即导致系统产生内部错误（Internal Error）的有效请求数除以这段期间的有效请求总数。

一般大厂的准确性定义如下：

1）Google CLoud Platform：每个月系统的错误率超出5%的时间要少于0.1%，以每分钟为单位去计算； 2）亚马逊AWS：以每5分钟为单位，错误率不会超出0.1%。

系统容量（Capacity）：

指的是系统能够支持的预期负载量是多少，一般会以每秒的请求数为单位来表示，常见的衡量指标有QPS（Queries Per Second）、RPS（Requests Per Second）。

延迟（Latency）：

指的是系统在收到用户的请求到响应这个请求之间的时间间隔，一般会有这些延迟声明：

1）p95: 这里的"p"代表 percentile，也就是百分位，如果说p95延迟为1秒，那就表示100个请求内，有95个请求的响应时间会低于1秒。

2）p99: 同理。

2）其他评估指标

⚙️ 可扩展性（Scalability）：

因为我们讲的是分布式系统，所以这个系统最好少可以适应不断增长的数据量的，当我们的数据从GB到TB，甚至到PB级别，都需要我们的系统可以跟上。

可扩展性就是保证这个功能的指标，增加系统容量的模式有两种：水平扩展（Horizontal Scaling）和垂直扩展（Vertical Scaling）。

• 水平扩展：即直接增加系统内的机器节点来达到扩容。
• 垂直扩展：即在不增加机器节点数量的前提下，"升级"现有机器的性能。

无节制的增加机器数量也不是办法，比如机器的管理、调度、通信会变得更加复杂出错的可能性会更高，而垂直扩展虽然不需要修改系统代码，但是单个机器性能的提升是有限的，而且可能成本会比直接增加一台机器要贵得多。

一致性（Consistency）：

指的是系统中不同机器节点在同一时间，接收和输出的数据是否一致。常用的一致性模型，分别是：强一致性（Strong Consistency）、弱一致性（Weak Consistency）、最终一致性（Eventual Consistency）。

• 强一致性： 当系统中的某个数据被成功更新后， 后续任何对该数据的读取操作都将使用最新数据，即在任意时刻，同一系统中所有节点的数据是一样的，会有一定的延迟。
• 弱一致性： 当系统中的某个数据被更新后，后续对该数据的读取操作不一定是最新的数据，但经过"不一致时间窗口"这段时间后，数据都会被更新。
• 最终一致性： 是弱一致性的特殊形式，在储存系统中，在没有新的更新的条件下，最终所有的访问都是最后更新的值，支持异步读取，延迟比较小。

持久性（Durability）：

指的是数据一旦被成功储存后就可以一直使用，即便系统中部分节点因为宕机、下线或者数据存坏。

流处理与批处理的区别

有边界数据与无边界数据

Unbounded Data 和 Bounded Data可以大致将数据分为两类，前者顾名思义就是无限增长的数据集，我们无法判定何时会停止发送，是每时每刻都可能会发生。后者有边界数据则相反，是已经保存好了的数据，如CSV文件。

事件时间和处理时间

我们要处理的数据都是有两种时域（Time Domain），分别是事件时间（Event Time）以及处理时间（Precessing Time）。

Event Time： 指的是数据实际产生的时间点

Precessing Time： 指的是处理数据的系统架构实际接收到这个数据的时间点

批处理（Batching Processing）

可以理解为一系列相关的任务按顺序（或者并行）地执行，一般来说批处理的输入都是有边界数据，同样输出也是有边界数据，我们更多地关心数据的事件时间。

批处理架构一般应用场景：

• 日志分析： 日志系统是在一定时间段（日、周或年）内收集的，而日志的数据处理分析是在不同的时间内执行，以得出有关系统的一些关键指标
• 计费应用程序： 计费应用程序会计算出一段时间内一项服务的使用程度，并生成计费信息，如每个月的信用卡还款单等
• 数据仓库： 数据仓库的主要目标是将收集好的数据事件按时间把其合并为静态快照（Static Snapshot），并将其聚合为每周、每月、每季度的分析报告

常见的开源架构：

• Apache Hadoop
• Apache Spark

流处理（Streaming Processing）

可以理解为系统需要接收并处理一系列连续不断变化的数据，如社交软件数据、订票系统等，其输入数据基本上都是无边界数据。

流处理的特点就是快、低延迟，其响应时间一般都是以毫秒（或者微秒）级别来计算的，其速度之快的根本原因在于它在数据到达磁盘之前就对其进行了分析。

流处理架构一般应用场景：

• 实时监控： 捕获和分析各种来源发布的数据，如传感器、新闻源等
• 实时商业AI： 智能汽车、智能家居等
• 销售终端系统： 交易系统、股票价格变化等

常见的开源架构：

• Apache Kafka
• Apache Flink
• Apache Storm
• Apache Samza

什么情况下应该使用批处理

• Performing aggregate functions such as finding the mean, maximum, or minimum of a set interval of data.
• Cases where alerting doesn’t need to run on every single data point (since state changes will probably not happen that often). You don’t want to be inundated with alerts!
• Downsampling of your data takes a large collection of data points and only retains the most significant data (so you can still view overall trends in the data).
• Cases where a little extra latency won’t severely impact your operation.
• Cases with a super-high throughput InfluxDB instance since Kapacitor cannot process data as quickly as it can be written to InfluxDB (this occurs more frequently with InfluxDB Enterprise clusters).

什么情况下应该使用流处理

• If you want to transform each individual data point in real time (technically, this could also be run with a batch process but there’s latency to consider).
• Cases where lowest possible latency is paramount to the operation. If alerts need to be triggered immediately, for example, running a stream task will ensure the least possible delay.
• Cases in which InfluxDB is handling high volume query load and you may want to alleviate some of the query pressure from InfluxDB.
• Stream tasks understand time by the data’s timestamps; there are no race conditions for when exactly a given point will make it into a window or not. With batch tasks, on the other hand, it is possible for a data point to arrive late and be left out of its relevant window.