开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 大数据 -> 数据仓库知识点 -> 正文阅读

[大数据]数据仓库知识点

简介

诞生背景

主要为了满足两个需要，一是历史数据积存，二是企业数据分析需要

首先是历史数据积存，线上业务系统随着企业的运行会源源不断地产生数据，这些数据就会被存储在业务数据库中，例如mysql,oracle等。但是随着线上的业务系统运行一定时间之后，积压的数据就会越来越多，这就会对业务数据库产生一定的负载，导致运行速度缓慢，而这里堆积的相当一部分数据属于冷数据，即较早的调动相对不频繁的数据，为了避免冷数据对数据库产生的影响，妨碍数据库运行，这时就需要企业定期将冷数据从业务数据库中转移，存储到专门存放历史数据的仓库中，这个仓库就称之为数据仓库

其次就是企业数据分析的需要，各个部门如果自己建立独立的数据抽取系就会导致数据不一致。例如各个部门如果直接从业务数据库抽取数据，部门A从早上九点抽取数据，而部门B从下午两点抽取，每个部门都需要给个数据库权限，数据库的权限管理有很大的风险。为了解决这个问题，企业统一建立一个数据仓库，使用专门的数据抽取系统，定期从业务数据库把数据抽取到数据仓库中。这样比如，数据仓库每天凌晨抽取数据，那么各个部门用到数据的时候是一致的，都是前一天的。再者，数据仓库可以直接开放接口，这样业务数据库和数据仓库的权限管理更具有针对性，数据仓库面向数据分析，业务数据库面向业务系统，各司其职。

什么是数据仓库

数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、随时间变化（Time Variant）的数据集合，它用于支持企业或组织的决策分析处理。

面向主题的：数据集合是以主题为单位进行数据汇聚，一个主题内只存储与本主题有关系的数据。

集成的：数据来源多种多样，需要ETL操作。

相对稳定的：一般只进行写入与查询操作，不进行更新与删除。

反映历史变化：关键数据隐式或显式的基于时间变化

这里可能就纳闷了，数据仓库是不让修改的，那么怎么去改变呢？
可以把最新的数据追加到系统中，然后以时间戳标记版本，修改后的数据所在的时间戳最新，之前的旧数据因为时间戳是旧的，所以在查询的时候不去查询，当然也可以定期删除旧的

传统数据库vs大数据仓库

传统数据库-单机数据库集成

传统数据库是单个关系型数据库组成MPP（大规模并行处理）集群，说人话就是多个单机数据库集群产生。

优点：由于是由关系型数据库改造，所以完全兼任原有的SQL语法
缺点：

扩展性有限，MPP集群是由一个节点把数据分发到各个节点，其实每个节点本质上还是一个数据库，他可以独立进行计算，但是涉及到数据交换，就得通过高速网络与其他节点连接，这样直接限制了节点上限。其次，运用到了分库分表，即一张很大的表拆分成几个部分，存储到不同节点上，分库分表也有上限，因为分库分表越细，数据库处理数据时性能也越差
热点问题：还是分库分表，当一张比如说100万行的大表被拆分成多分，交由不同数据库节点存储的时候，可能会出现其中最被频繁使用的的数据都在同一个节点中，这就导致这个节点存在的压力特别大。当然，可以用数据加盐的方式解决，即给表中的数据增加前缀，把他打乱随机分布到各个表中

大数据仓库-分布式

有极强的扩展性

大数据诞生初期，易用性差，因为大数据数据处理时有自己的数据引擎，有自己的语法，但企业的数据一般是用Sql处理的，

大数据仓库的架构是分布式文件系统，把数据库中的结构化数据看成是文件，把这些文件自动拆分成默认是按照128M拆分，拆分完后分发到各个节点，不用考虑传统的很精细的分库分表。

大数据仓库在上层处理的时候，采用元数据，把这些提取的文件还原为表结构

正是这种粗犷的方式解决了延展性，再者也解决了热点问题，因为将数据存储到节点的时候，会备份几份，比如说存在节点1,2,3都存了，那么到时候我们要用到这个数据的时候，分布式架构的好处就在于提取数据的时候可以在1,2,3中选择一个最空闲的节点，这样就解决了热点问题。

缺点：1. sql支持率问题 2.缺少事务支持，对事务支持不全 3. 数据量较小时，计算较慢。在数据量没有达到一定规模的时候，光是任务的拆分，分配，调度，合并，整个过程就会花费大量的时间。

MPP和分布式批数据架构（Hadoop架构）

MPP架构

传统数仓中用的结构，就是将单机数据库节点组成集群，从而提升整体的性能

其中每个节点都是独立计算的，有自己的独立存储和内存系统，是非共享架构。每个节点通过专业网络相连，协同计算。

设计上优先考虑C（一致性）、A（可用性）、P（分区容错性）

缺点：

存储位置不透明，通过Hash（哈希）确定数据所在节点，查询任务会在所有节点均被执行

并行计算的时候，单节点瓶颈会成为整个系统短板，容错性较差。在整个节点协同计算的过程中，当一个节点运行缓慢的时候，其他节点势必等待。

分布式批数据架构

MPP不共享数据，而分布式批数据架构在集群中共享

特点：

可以单独进行局部应用
每个节点共享数据
同时又因为共享数据，所以扩展性极强

分布式批数据架构每个节点有计算和存储资源，这俩是分开的，并且每个节点的存储资源拿出来，共同组成了一个分布式的公共数据存储系统。各个节点存储资源被拿走后，剩下的就是计算资源，当任务分配到每个节点，每个节点在运算的时候，就可以共享整个公共数据存储系统，因此可以单独进行局部应用，同时也可以共享数据

节点间不是通过高速网络交互，每个节点是通过局域网或者广域网相连，因此致力于减少数据移动
优先考虑P（分区容错性）、A（可用性）、C（一致性）
数据存储的时候是多个备份存储到节点，比如说保存三份，分别存储到1,2,3节点，就保证了容错性

MPP+分布式架构

数据存储用分布式架构的公告存储，提高分区容错性

上层架构采用MPP，减少运算延迟

常见的数仓产品

传统型数仓
Oracle RAC
DB2
Teradata
Greenplum
分布式

Hive

Hadoop分布式架构，原理：将sql转换成大数据的计算引擎MapReduce进行运算，也支持转换为spark

Spark SQL

Spark生态圈的数仓产品，诞生原因是MapReduce运行太慢了

HBase
Impala
HAWQ
TIDB

架构

基本架构（以阿里为例）：ETL->ODS->CDM->ADS

在这里插入图片描述

ETL
E：extract抽取，T：trasnform转换，L：load加载
抽取原始数据，然后进行转换，比如说清洗去重等，然后加载到目的端的过程
ODS（操作数据层）
这一层不做任何的修改，目的是存储原始数据
CDM（公共维度模型层）
整个层主要是为数据分析提供服务，主要分DWD（数据明细层）和DWS（数据汇总层）。
DWD（数据明细层）：处理ODS的数据，规范化
DWS（数据汇总层）：将各个表汇总成一张表（宽表），满足三范式，在对宽表进行数据建模等，模型设计
ADS（数据应用层）
存储分析结果，为不同业务提供接口，减少数仓压力
如果直接开放前面的CMD层，这层是进行数据分析的，直接开放业务查询接口会增加负担，所以我们专门建了ADS层来存储结果，并且开放接口。

ETL

E：extract抽取，T：trasnform转换，L：load加载
抽取原始数据，然后进行转换，然后加载到目的端的过程

1. 数据抽取（Extraction）

抽取的数据源：结构化、半结构化、非结构化
抽取数据的方式：全量或增量（抽取全部数据，或者抽取变动数据）

Q. 什么是结构化、半结构化、非结构化数据

1、结构化数据

结构化数据，简单来说就是数据库，有一定的结构性，表现为二维形式的数据

2、非结构化数据

非结构化数据是数据结构不规则或不完整，没有预定义的数据模型，不方便用数据库二维逻辑表来表现的数据。包括所有格式的办公文档、文本、图片、XML, HTML、各类报表、图像和音频/视频信息等等。

3、半结构化数据

和普通纯文本相比，半结构化数据具有一定的结构性，可以用一些分隔元素对记录和字段，进行分层。常见的半结构数据有XML和JSON，对于对于两个XML文件，第一个可能有

Q. 结构化、半结构化、非结构化数据如何提取？

结构化数据采用JDBC、数据库日志等方式，JDBC对数据库进行直接连接
半结构化或者非结构化，可以监听文件是否发生了变动，将变动后的数据进行抽取

2. 数据转换（Transformation）

主要是数据清洗和转换两个阶段

数据清洗

对重复、二义性、不完整、违反业务或逻辑规则等问题进行统一处理

数据转换

数据标准化，字段数据类型等转换

3. 数据加载（Loading）

将处理完的数据导入到对应的目标源

常见的ETL工具

结构化ETL工具：

SGoop
Kettle
Datasatge
Informatica
Kafka

非结构化
Flume
Logstash

ODS（操作数据层）

这一层不做任何的修改，目的是存储原始数据

如果一定要修改，就新增数据，然后给他更新的日期，并且将状态变为update，删除旧数据

ETL导入ODS的方法
全量和增量
增量导入：使用外连接&全覆盖的方法，把增量数据与原有的数据进行join全外连接（两表中一个有就返回），如果有新增的数据，就直接在内存中修改，然后把ODS层覆盖

CMD（公共维度模型层）

整个层主要是为数据分析提供服务，主要分DWD（数据明细层）和DWS（数据汇总层）。

DWD（数据明细层）

主要功能：数据格式规范化&维度降维

DWD（数据明细层）：主要接受ODS层的数据，由于ODS的数据是不进行修改的，所以ODS层的数据可能来源于各个系统，并且格式不统一，所以我们DWD（数据明细层）要做的就是统一格式，如清洗、标准化、异常数据清洗，对数据做统一字段编码等。

还有可能就是维度降维，比如说公司有多个分布，在北京上海等地返回用户表，这些用户表字段都一样，但是一张张独立的表，我们可以把这些表增加一个字段叫做位置，然后把这些表就可以合成同一张表

满足三范式

DWS（数据汇总层）

DWS（数据汇总层）：将各个表汇总成主题表，例如都是交易相关的就汇总成交易表，不满足三范式

ADS（数据应用层）

存储分析结果，为不同业务提供接口，减少数仓压力

如果直接开放前面的CMD层，这层是进行数据分析的，直接开放业务查询接口会增加负担，所以我们专门建了ADS层来存储结果，并且开放接口。

最佳实践

维度建模

三范式

1．第一范式(确保每列保持原子性)

如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。

第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。

2．第二范式(确保表中的每列都和主键相关)
第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

比如要设计一个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所示。

3．第三范式(确保每列都和主键列直接相关,而不是间接相关)

三范式建模和维度建模

在这里插入图片描述

维度建模：根据不同维度建模，一般包含分类、时间、地域等
维度模型一般分为星型、雪花、星座模型

星型模型是一张事实表＋一张以上的维度表组成，最高效的星型是没有维度表，维度表包含在事实表中。

雪花模型是最低效的数仓模型，以为其维度表上还有维度表，多层维度。所以在聚合过程中会产生更多的关联计算，效率很低。

星座是多个星型模型放在一起，并且这些星形模型之间的维度有重叠部分，最主要的特征是有多张事实表，并且这些事实表之间有些维度表是重叠的。

范式建模是维度建模的一种，特点是数据冗余减少，但效率变低。雪花模型就是维度建模的简单版本。

数仓中的表

维度建模中的表类型

事实表
一般指的是一个现实中存在的业务对象，比如说电商系统的用户信息表等
维度表
业务状态、代码等的解释表，例如订单状态1表示未支付，2表示已支付…
事务事实表
一旦产生表结构就不会变化，只会追加新的数据，例如交易流水，操作日志、出库入库记录等
周期快照事实表
一个周期内的度量统计，例如年、季度累计，例如表结构是
业务id，卖家id，年累计下的金额，年累计买家数，年累计支付金额…
累计快照事实表
记录不确定周期的度量统计，比如说你下单但是没支付，这就是一条记录，然后支付了但没收货，这条记录就更新掉之前的，直到完成这个过程。
拉链表
记录每条信息的生命周期，保留数据的所有历史状态。
累计快照事实表的实现方式？
实现方式一
使用日期分区，全量数据记录。即每天的数据分别存储，然后每天存储的是昨天的全量数据和今天新增的数据。缺点就是冷数据太多
实现方式二
在前面的基础上改进，设定一个数据最长生命周期，如一个月，就是默认假设这一个月内数据是会更新的，删除一个月之前的。
实现方式三
使用日期分区，但是是以业务实体的结束时间分区。也就是说两张表，一张表存储的是已经结束的数据，另一张是存储未结束的，更新未结束的数据表

ETL策略

全量同步和增量同步

任务调度

sql优化

一、基础优化
少使用select *，尽量使用具体的字段
少使用order by排序，对于需要多个字段排序的可以使用组合索引
少使用like，对于需要使用的，尽量写like “abc%”，把%尽量放在字段后面
对group by语句，要先过滤后分组
查询时减少使用null，对于字段有null的可以添加默认值
固定字段长度
使用limit 1 (明确只有1行的时候)，这样查到1行就返回了
在where后面少使用函数或者算数运算
不要超过5个以上的表连接
二、建立使用合适的索引
对于高频筛选字段可以建立适当的索引
不要建立会发生变动的索引，比如date()，会使得索引失效
一个表的索引最好不要超过5个，多了影响插入修改
不要对值是有重复的字段建立索引，如性别等
使用组合索引的时候要遵守最左原则
三、进阶优化
使用explain检测sql查询（explain select …）
使用缓存优化查询（进行多次相同的查询，结果就会被放入缓存中，后续再进行同样的查询，就直接从缓存中提取，不会到表中提取）redis
注意：当查询语句中有些不确定时，例如now()，current_date()等会出现缓存失效

Redis

什么情况下使用redis

针对热点数据进行缓存
对于特定限时数据的存放
针对带热点权值数据的排序list
分布式锁

数据结构

基本数据类型：

字符串
链表
哈希表
集合
有序集合

字符串

为什么不使用C++已有的字符串类型？
因为C++的字符串获得长度，时间复杂度为O(n)，且难以处理特殊字符，并存在扩容问题

总结：Redis字符串本质上是C语言的字符数组，加上了一点别的标识属性的结构体，优点在于：1.字符串获取长度从O(n)->O(1)，减少因为字符串扩容引起的数据搬运次数

链表

Redis链表的底层实现是双向链表，结构有两个节点，前置和位置节点
节点定义如下：

typedef struct listNode{
	struct listNode*prev; //前置节点
	struct listNode*next; //位置节点
	void *value; //节点数值
}listNode;

链表常见的API函数

lpush：向链表左边增加元素
rpush：向链表右边增加元素
lpop：弹出左侧第一个元素
rpop：弹出右侧第一个元素
llen：获得链表长度
lrange：按索引范围获得值

哈希表

键和值一一对应，一个key对应一个value，可以通过键key在O(1)时间复杂度内获得对应的value值。由于C语言没有内置哈希表，所以resdis自己实现了这一结构。

redis采用拉链法作为哈希表的实现。

持久化

什么叫持久化？就是将内存的数据搬运到硬盘上，保证在电脑断电等突发情况下数据能从硬盘中恢复。

因为Redis是内存数据库，它将自己的数据库状态储存在内存里面，所以如果不想办法将储存在内存中的数据库状态保存到磁盘里面，那么一旦服务器进程退出，服务器中的数据库状态也会消失不见

redis是内存型数据库，数据均存储在内存中，这个优点就是读取速度快，但是数据有易失性。有两种解决方法：RDB（redis data base）和AOF（append only file），前者相当于把整个redis内存数据存储到硬盘中，AOF是把数据修改的命令存储到硬盘。

RDB

把目前Redis内存中的数据，生成一个.rdb形式的文件，保存到硬盘中。

如果发生事故，Redis可以通过RDB文件，进行读取，将数据重新载入到内存中取

全量备份，有手动和自动触发两种，手动有save和bgsave，前者是主线程后者是子线程生成rdb文件，自动c触发一般是bgsave，即有个子线程去生成rdb文件

RDB文件结构

数据部分，有过期时间标量常识，过期时间，类型，键，值

eg.字符串：压缩标识，字符串被压缩后长度，原始长度，字符串
列表：列表长度，第1项长度，第1项，…
集合：集合长度，第1项长度，第1项，…
有序集合：集合长度，第1项长度，第1项，第1项score长度，第1项score…
哈希表：哈希表长度，第1项key长度，第1项key，第1项value长度，第1项value，…

触发条件

手动触发：

save：执行该指令后，主线程执行rdbsave，SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求
bgsave：和SAVE命令直接阻塞服务器进程的做法不同，BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程（父进程）继续处理命令请求

自动触发：
在配置文件中写入 save m n，即当m秒内发生n次变化的时候，自动执行bgsave

AOF

记录之后所有对Redis数据进行修改的操作

如果发生事故，redis可以通过AOF文件，将文件中的数据修改命令全部执行一遍，从而恢复数据。

AOF的重写与恢复

由于AOF会以追加的方式记录每一条redis的写命令，因此随着Redis处理的写命令增多，AOF文件也会变得越来越大，命令回放的时间也会增多，为了解决这个问题，Redis引入了AOF rewrite机制（下文称之为AOFRW）。

AOFRW会移除AOF中冗余的写命令，以等效的方式重写、生成一个新的AOF文件，来达到减少AOF文件大小的目的。

也就是说，到了一定程度，根据redis数据状态重新生成一个新的AOF文件，来代替原有的AOF文件。

AOF触发条件

手动触发：bgrewrite
自动触发：配置文件中设置appendonly yes开启
当然自动触发的时候，仅仅只是设置appendonly yes开启是不够的，还需要明确下写入策略

Always：每个命令执行完后，就将这个命令加载到磁盘文件中
Everysec：每秒写入，也就是说每个命令执行完后，过1s将缓存区命令写到磁盘的AOF文件中
No：这个No不是说不执行AOF，而是将操作命令什么时候存储到磁盘中，交由操作系统决定

Redis默认策略是Everysec

缓存相关

缓存淘汰

怎么淘汰缓存数据？

先进先出–FIFO算法
最近最少使用–LRU算法

把数据按照最近被访问的时间排序，把排序中末端节点删除，新增新数据。

实现思路：双向链表+哈希

最不经常使用–LFU算法
增加一个数据属性，为被访问次数，然后按照访问次数进行筛选，淘汰被访问次数最少的节点

redis中使用的是LRU算法，即淘汰最近最少被使用的

过期删除

怎么保证几分钟后自己删除？有两种方法，主动删除和惰性删除和定期删除

redis采用的是定期删除策略

主动删除
设置删除间隔，到了时间点自己运行程序删除工作
优点：易于理解，设置合理间隔后不会使内存占用超标
缺点：当redis比较忙时，设置删除时间碰巧到期了要删除的话，主动删除会增加redis负担
惰性删除
程序取值时查看该数据是否已经过期，如果过期了就删除，没过期就返回
缺点：容易造成某些数据长期霸占在内存中
定期删除
定期删除=主动删除+惰性删除
即每隔一段时间，跑主动删除，不跑主动删除的时候，就执行惰性删除策略

缓存一致

指的是数据库和redis数据库要同步，可能出现数据库中数据被修改，但是还没更新到redis中，如何保持缓存一致？

删除缓存有两种方式：

1.先删除缓存，再更新数据库。解决方案是使用**延迟双删**。

2.先更新数据库，再删除缓存。解决方案是**消息队列或者其他binlog同步**，引入消息队列会带来更多的问题，并不推荐直接使用。

延时双删–先删除缓存，再更新数据库

为了避免更新数据库的时候，其他线程从缓存中读取不到数据，就在更新完数据库之后，再sleep一段时间，然后再次删除缓存。

具体操作：先删除redis中的数据，然后更新数据库，更新完后再删除redis缓存，再同步

为什么要这么做？

时间点1，要更新数据库，所以我们把redis缓存删掉，然后更新数据库，但是更新数据库过程很长，有可能还没更新完就有人向redis读取数据。
比如说这时候是时间点2，但此时redis中没数据，所以就得向数据库访问，数据库因为还没更新完数据，所以返回的是旧的值，然后把旧值写入缓存。
这时候redis多了旧的值，所以需要更新完后，再把redis缓存值删掉，重新加载更新后的数据

消息队列–先更新数据库，再删除缓存

先更新数据库，成功后往消息队列发消息，收到消息后再删除缓存，借助消息队列的重试机制来实现，达到最终一致性的效果。

消息队列是大型网站必用中间件，如ActiveMQ、RabbitMQ、Kafka等流行的消息队列中间件，

为什么是删除，而不是更新缓存？

我们以先更新数据库，再删除缓存来举例。

如果是更新的话，那就是先更新数据库，再更新缓存。

举个例子：如果数据库1小时内更新了1000次，那么缓存也要更新1000次，但是这个缓存可能在1小时内只被读取了1次，那么这1000次的更新有必要吗？

反过来，如果是删除的话，就算数据库更新了1000次，那么也只是做了1次缓存删除，只有当缓存真正被读取的时候才去数据库加载。

缓存穿透

查询某个数据，缓存中没有，数据库中也没有，所以叫“穿透”，两层都没有

解决方法：

  1.拦截非法请求。即在数据库操作访问前进行校验，对不合法请求直接返回。
  2.缓存空对象。即对于经常被访问的，并且数据库没有的键，缓存层记录键=null。
  3.布隆过滤器。

布隆过滤器

主要用于判断一个元素是否在一个集合中。通过将元素转化成哈希函数再经过一系列的计算，最终得出多个下标，然后在长度为n的数组中该下标的值修改为1。

当一个元素被加入集合时，通过 K 个散列函数将这个元素映射成一个位数组（Bit array）中的 K 个点，把它们置为 1

布隆过滤器的原理介绍

当一个元素加入布隆过滤器中的时候，会进行如下操作：

使用布隆过滤器中的哈希函数对元素值进行计算，得到哈希值（有几个哈希函数得到几个哈希值）。根据得到的哈希值，得到的哈希值就是在数组的位置，把这个位置中的0改写成1。
当我们需要判断一个元素是否存在于布隆过滤器的时候，会进行如下操作：

对给定元素再次进行相同的哈希计算；得到值之后判断位数组中的每个元素是否都为 1，如果值都为 1，那么说明这个值在布隆过滤器中，如果存在一个值不为 1，说明该元素不在布隆过滤器中。

主要用来比较给定的元素，是不是原始元素集合中已经存在
在这里插入图片描述

布隆过滤器使用场景

判断给定数据是否存在：比如判断一个数字是否存在于包含大量数字的数字集中（数字集很大，5 亿以上！）、防止缓存穿透（判断请求的数据是否有效避免直接绕过缓存请求数据库）等等、邮箱的垃圾邮件过滤、黑名单功能等等。
去重：比如爬给定网址的时候对已经爬取过的 URL 去重。

缓存击穿

查询某个数据的值，该值在缓存中无，在数据库中有，所以叫“击穿”，一层有一层没有，还没有被完全穿透

解决方法

  1.设置热点数据永远不过期。
  2.对并发读数据设置并发锁，降低并发性

利用分布式锁，只允许一个请求线程去访问database数据库，其他请求阻塞，这样就避免了很多请求打到数据库上。

热点发现

人为预测

就是人工标记，预测这个商品会成为热点，打个标记。web应用根据这个标记把此商品保存到本地缓存中

这个方案，是根据运营人员的经验进行预测，太不靠谱了。

系统推算

这个方案是根据实实在在的数据访问量进行推算形成，网上也介绍了用访问日志的什么算法，推算哪些是热点数据。这里分享一个比较简单的方式，就是利用redis4.x自身特性，LFU机制发现热点数据。实现很简单，只要把redis内存淘汰机制设置为allkeys-lfu或者volatile-lfu方式，再执行

./redis-cli --hotkeys

会返回访问频率高的key，并从高到底的排序

也就是说，把淘汰机制设为LFU，最不经常使用–LFU算法，然后返回最经常使用的key，从高到低排序就是我们要选择的热点

缓存雪崩

缓存雪崩指缓存中一大批数据到过期时间，而从缓存中删除。但该批数据查询数据量巨大，查询全部走数据库，造成数据库压力过大。

与缓存击穿不同的是，缓存击穿是查询一条数据，缓存中没有所以得到数据库查找，缓存雪崩是多条数据，同时删除，查询走到数据库这边了

缓存雪崩的解决方法

1.缓存数据设置随机过期时间，防止同一时间大量数据过期。
2.设置热点数据永远不过期。
3.对于集群部署的情况，将热点数据均与分布在不同缓存中。
4.缓存预热，即在上线前，根据当天的情况分析，将热点数据直接加载到缓存系统中

主从、哨兵、集群

主从复制

有一个主库，有一堆从库，主库用来写入修改数据，而从库用来被别人读取数据，主库对应的数据修改命令也会告诉从库，从库跟着执行从而保证主从库之间数据的一致性。读取的需求由从库执行，不干扰主库，减少数据库的负担。

哨兵

从库断网问题不大，主库断网问题很大。所以设置了很多哨兵监督主库，如果有哨兵发现主库连不上了，就会喊其他哨兵去连，诶要是好多都连不上，可能主库真的出现了问题，那么就会让哨兵头头在从库中挑选一个当主库。选从库的话，选尽可能网络好，最接近库的。

集群–Cluster

Cluster：redis提供的分布式数据库解决方案，自动将数据切片分给多个节点储存，即使这些节点中有一部分宕机，也可以继续执行数据操作。

大小表关联

MapJoin通常用于一个很小的表和一个大表进行join的场景

1.大小表join(MapJoin)
说明 : 当大表小表关联时,可以将小表读取到内存,在Map端进行数据关联
小表在左在右都会触发 Mapjoin

MapJoin简单说就是在Map阶段将小表数据从 HDFS 上读取到内存中的哈希表中，读完后将内存中的哈希表序列化为哈希表文件，在下一阶段，当 MapReduce 任务启动时，会将这个哈希表文件上传到 Hadoop 分布式缓存中，该缓存会将这些文件发送到每个 Mapper 的本地磁盘上。因此，所有 Mapper 都可以将此持久化的哈希表文件加载回内存，并像之前一样进行 Join。顺序扫描大表完成Join。减少昂贵的shuffle操作及reduce操作