这啥玩意都没讲的课要考了。。。
输入法发疯，如有错字请谅解QAQ
1. 云计算
1.1 云计算特点
1、虚拟化资源池。云计算使用虚拟化技术对硬件资源进行抽象，按用户所需进行资源的分配。
2、用户自配置资源
3、网络访问。
4、弹性使用资源。
5、效用计算。用户仅需要为所用资源付费，可降低用户使用IT服务的成本。
1.2 云计算的3个服务模型
云计算特点：虚拟化资源池、用户自配置资源、网络访问、弹性使用资源、效用计算
IaaS，基础设施即服务
PaaS，平台即服务
SaaS，软件即服务
云计算的3中服务模型之间的关系：IaaS提供虚拟化的硬件资源，支撑PaaS对平台的虚拟化，而PaaS又支撑了SaaS对软件的虚拟化。
1.3 边缘计算
边缘计算将计算任务放在接近数据源的计算资源上运行，将云端计算放到网络边缘，可以有效减少计算系统的延时，减少数据传输带宽，缓解云计算数据中心的压力。
2. 大数据
数据规模庞大、类型复杂、信息全面、维度高，难以基于传统软、硬件工具在有效的时间范围内进行采集、存储、分析、处理和展示的数据集合，对该数据集合进行处理有可能获得高价值处理结果，有助于机构或个人洞察事务真相，预测发展趋势，进行合理的判断和决策。
2.1 DIKW体系
Data（数据）、Information（信息）、Knowledge（知识）、Wisdom（智慧）
数据：对客观事物性质、状态等特点进行记录的可识别抽象物理符号；
信息：数据在传递过程中的形态；
知识：对数据进行挖掘，有价值的事物沉淀下来后形成的部分；
智慧：针对已有知识进行分析，获得的找出解决问题的能力。
转换及递进关系：
1、数据加工形成信息：数据+定义和格式+事件范围和相关性=>信息
2、信息提炼形成知识：信息+假设+关系+模式和趋势=>知识
3、知识运用体现智慧：智慧不是知识，但能运用知识；知识不是智慧，但能彰显智慧
2.2 数据思维
处理全部数据，关注相关性，而非因果性。
十大思维：
- 数据核心原理：从“流程”核心转变为“数据”核心
-
数据价值原理：由功能是价值转变为数据是价值
- 全样本原理：从抽样转变为需要全部数据样本
- 关注效率原理：由关注精度转变为关注效率
- 关注相关性原理：由因果关系转变为关注相关性
-
预测原理：从不能预测转变为可以预测
- 信息找人原理：从人找信息，转变为信息找人
- 例：搜索引擎向推荐引擎转变
- 机器懂人原理：由人懂机器转变为机器更懂人
- 电子商务智能原理：大数据改变了电子商务模式，让电子商务更智能
- 定制产品原理：由企业生产产品转变为由客户定制产品
3. 分布式一致性算法
3.1 分区
垂直分区：按列分割
水平分区：按行分割，假设所有数据以键值对形式存储。
范围分区：根据key将数据分为若干连续范围
哈希分区：根据key的哈希值分区
一致性哈希：将所有哈希值排成一个环，将机器均匀放在上面，新来的哈希值找最近的机器，即将机器与哈希值解耦。
3.2 复制
单主复制：主从复制。
同步复制、异步复制、半同步复制：根据回复时有没有同步全部节点分类。
多主复制：多个节点处理写请求
无主复制：将写请求发给多个不固定的节点。
基于Quorum（法定人数）的数据冗余机制：用于决定究竟向几个节点发送请求。假设有3台机器，每次往里写2台，从2台读，考虑加入时间戳，总能读到最新数据。
在一个由N个节点组成的系统中，我们要求至少W个节点写入成功，并且需要同时从R个节点中读取数据，只要W+R>N且W>N/2，则读取的R个返回值中至少包含一个最新的值。
证明：W+R>N，读写有交集。第一条规则保证了一个数据不会被同时读写。当一个写操作请求过来的时候，它必须要获得Vw个冗余拷贝的许可。而剩下的数量是V-Vw 不够Vr，因此不能再有读请求过来了。同理，当读请求已经获得了Vr个冗余拷贝的许可时，写请求就无法获得许可了。第二条规则保证了数据的串行化修改。一份数据的冗余拷贝不可能同时被两个写请求修改。
W值越大R值越小，系统的读操作性能就越好。反之写操作的性能越好。
3.3 CAP定理
Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性）
CAP不能同时满足。
证明用反证法。
例：
假设存在一个同时满足这三个属性的系统。
首先让系统发生网络分区，服务器Node1和Node2之间的网络发生故障导致断开连接。
客户端向Node1发起写请求，将V的值更新为1，因为系统是可用的，所以Node1必须响应客户端的请求，但是由于网络分区，Node1无法将其数据复制到Node2.
接着，客户端向服务器Node2发起读V的请求，再一次因为系统是可用的，所以Node2必须响应客户端的请求。还是因为网络分区，Node2无法从Node1更新V的值，所以Node2返回给客户端的是旧的值0，和客户端刚才写入的V的值不同。违反了一致性，因此证明不存在这样的系统。
意义：CAP定理帮助软件工程师在设计分布式系统时不必浪费时间去构建一个完美的系统。开发者通常将他们的分布式系统分为2类，即CP或AP，这取决于在保证分区容错性（P）的情况下选择一致性（C）还是可用性（A）。
3.4 一致性
以下一致性由强到弱。
线性一致性：给定一个执行历史（若干读写操作），执行历史根据并发操作可以扩展为多个顺序历史，只要从中找到一个合法的（读写值对的上）顺序历史，那么该执行历史就是线性一致性。
注：执行历史是并行的，并不知道具体前后；顺序历史根据约束将其排成一条线。
约束：在将执行历史转变成顺序历史的过程中，如果两个操作是顺序关系，那么它们的先后关系必须保持相同；如果两个操作是并发关系，则它们可以按任何顺序排列。
顺序一致性：顺序一致性只要求同一个客户端（或进程）的操作在排序后保持先后顺序不变，但不同客户端（或进程）之间的先后顺序是可以任意改变的。即，两条时间线不必有全局时钟。
有时候顺序一致性更有用。例如，在一个社交网络应用中，一个人通常不关心他看到的所有朋友的帖子的顺序，但对于具体的某个朋友，仍然以正确的顺序显示该朋友发的贴子会更符合逻辑。
因果一致性：因果一致性要求，必须以相同的顺序看到因果相关的操作，而没有因果关系的并发操作可以被不同的进程以不同的顺序观察到。
最终一致性：最后能返回一个相同、最新的结果就很厉害了。
3.5 隔离级别
脏读幻读不可重复读略。
更新丢失：x=10; A：x+=1; B：x+=2; res：x=11
读偏斜：假设数据的约束是X+Y=100，并发事务B一开始读到了X的值为50，同时事务A将X和Y的值分别修改为30和70，接着事务B读到Y的值为70。在事务B看来，X+Y=50+70，这显然违反了数据约束，这破坏了事务的一致性。
4. 分布式系统协调管理
4.1 事务ACID
Atomicity（原子性）：事务包含的所有操作要么都做，要么都不做。
Consistency（一致性）：事务开始前后数据库完整性没有被破坏。
Isolation（隔离性）：防止多事务并发执行时由于交叉执行产生数据异常。
Durability（持久性）：对数据的修改是永久的，设备故障也不会导致数据丢失。
4.2 两阶段提交
第一阶段：协调者发布事务，参与者执行事务，但不提交。如果所有操作执行成功，向协调者返回‘是’，否则返回‘否’。
第二阶段：如果都是‘是’，提交事务；如果有一个‘否’，回滚；
问题：
1. 协调者故障 —— 单点故障问题
2. 参与者发完‘是’后故障 —— 数据不一致问题
以上两个情况可以看出，两阶段提交只满足弱中止条件，即其他未故障的参与者无法决定事情走向。
4.3 三阶段提交
第一阶段：预询盘
协调者询问参与者是否能正常执行事务，参与者回复一个预估值。
第二阶段：预提交
根据上一阶段结果有三种情况：
1、所有的参与者都返回确定信息。—— 向参与者发送执行请求，参与者执行但不提交。
2、一个或多个参与者返回否定信息。
3、协调者等待超时。
针对第2和第3种情况，协调者认为事务无法正常执行，于是向各个参与者发出abort通知，请求退出预备状态，参与者收到通知后中断事务。
第三阶段：事务提交
如果第二阶段事务未中断，那么本阶段协调者将会依据事务执行返回的结果来决定提交会回滚事务，分为3种情况：
1、所有的参与者都能正常执行事务；—— 发送commit通知，参与者commit。
2、一个或多个参与者执行事务失败；
3、协调者等待超时。
针对第2和第3种情况，协调者认为事务无法成功执行，发送回滚请求，参与者回滚。
两阶段提交协议种所存在的长时间阻塞状态发生的几率还是非常低的，所以虽然三阶段提交协议相对于两阶段提交协议对于数据一致性更有保障，但是因为效率问题，两阶段提交协议在实际系统种反而更加受宠。
4.4 Paxos提交
直接用以前写的：
有一些机器提出一些提议，这些提议都有编号，我们认为编号大的提议更新，想要尽可能采取新的提议；但提议提出去后呢不知道几百年才能通知到每台机器，有时候新的提议到的还比老提议早；而且我们其实也不是很关心提议够不够新，如果新提议在一百年后才能被大多数机器收到，那这个提议不要也罢。综上，我们想要尽快达成一个共识，且这个共识是大多数人（超过一半）收到的最新版本。
机器开始提议了啊，现在我们看看收到提议的机器怎么处理：如果我之前没有收到过提议，那么这个提议不错，告诉提议者我采纳；如果我收到过提议，但到达的提议更新，那么我也告诉提议者采纳；如果到达的提议比我现在采纳的旧，那我不理它。
5. 分布式文件系统
5.1 GFS
· 建立前提假设：
1. 系统构建在廉价机器上，容易故障
2. 系统存储大型文件
3. 读操作：支持大规模顺序读取和小规模随机读取
4. 写操作：主要是追加写，而非覆盖写
5. 更看重稳定而非低延迟
· 模式：主从模式
· 特点：
控制流和数据流分离
并发访问数据块服务器
· 实现架构
文件被分为固定大小的数据块（chunk），默认在不同机器中复制3份
Master：存储元数据（描述数据的数据）
ChunkServer：数据存储位置
· 关键机制
租约机制
问题描述：多次记录追加都要请求Master，Master成为性能瓶颈
解决方案：将写操作授权给ChunkServer，拥有租约授权的chunkserver称为主chunkserver，其他副本所在的chunkserver称为备chunkserver。在租约有效期内，对该chunk的写操作都由主chunkserver负责，从而减轻Master的负载。一般来说，租约的有效期比较长，比如60s，只要没有出现异常，主chunkserver可以不断向Master请求延长租约的有效期直到整个chunk写满。
即，找一个空的ChunkServer，每次往里面写，写满了换下一个，不要每次都问服务器我写到哪里去。
· 写操作
1. Client请求并获得租约Chunk
2. 传数据到缓存
3. 所有块准备好，发送写请求
4. Primary写
5. Secondary备份，进行同样操作
· 读操作
1. 将要读取的数据范围转化为chunk序号
2. Master返回chunk及其副本位置
3. 找一个最近的副本读
5.2 HDFS
特点和假设跟GFS一样，因此导致不适合低延迟数据访问、无法高效存储大量小文件 、不支持多用户写入及任意修改文件。如果没记错HDFS是根据GFS的论文实现的。所以只追加以下具体实现内容和不同点：
· 结点命名
主节点：NameNode
数据节点：DataNode
· 数据结构
1. FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据
2. 操作日志文件EditLog中记录了所有针对文件的创建、删除、重命名等操作
· 启动过程
1. 加载FsImage
2. 执行Editlog操作，同步数据
3. 运行，每次操作先修改Editlog，而非直接添加到FsImage，相当于加了一层缓存，提高运行速度。
但这会导致Editlog不断变大，因此再添加一个SecondaryNameNode辅助它。SecondaryNameNode定期和NameNode通信，把Editlog的内容加载到FsImage里，这样Editlog就可以重新写了。加载的过程是这样的：从NameNode获取FsImage，修改，然后传回去。
· 数据错误与恢复
1. NameNode出错：找SecondaryNameNode
2. DataNode出错：
每个数据节点会定期向名称节点发送“心跳”信息，向名称节点报告自己的状态。
当数据节点发生故障，或者网络发生断网时，名称节点就无法收到来自一些数据节点的心跳信息，这时，这些数据节点就会被标记为“宕机”，节点上面的所有数据都会被标记为“不可读”，名称节点不会再给它们发送任何I/O请求。
如果某个数据库副本死得差不多了，就再备份一点。这个界限成为冗余因子。
3. 数据出错：
传输后采用md5和sha1校验。
创建文件时进行信息摘录，读取时进行校验。
· GFS与HDFS对比
1. HDFS有安全模式，即DataNode出错到一定程度会复制副本，GFS只有读取失败才发起复制
2. HDFS有空间回收机制，即删除时只删目录，实际数据一段时间后删除。
3. HDFS存在单点故障，GFS损坏可换另外一台
4. HDFS用心跳模式检查NameNode，GFS用轮询。
5. HDFS当数据积攒到一定量才写进磁盘（那个 log），GFS实时写入。
6. 分布式计算模型——MapReduce
不希望处理的问题：不可分拆的计算任务或相互间有依赖关系的数据无法进行并行计算，如斐波那契数列
希望处理的问题：数据间不存在依赖关系，或者用一些trick可以解决依赖关系，如经典的WordCount
下面看一下运行流程：
map：map的理想大小当然是一个数据块啦
shuffle：很复杂。简单来说就是reduce之前排个序，相近的整合整合，已经能reduce的reduce一下，待会reduce阶段单台机器上能数据整齐一点，不要七零八落。
除了map函数和reduce函数，我们还可以写一个partitioner函数。partition阶段在map之后，一个例子是用mapreduce进行sort，我们知道由于shuffle阶段的存在，单台机器上键值对是有序的，但我们还要保证多台机器之间也是有序的，比如说可以一台机器reduce以a开头的，另一台reduce以b-d开头的，这样合起来可以保证整体的有序。也就是说，将分好区的数据传输到reduce端的过程中，由Partitioner来决定每条记录应该送往哪个reducer节点。
计算优化：
如果有一个Map结点算得很慢，会拖整个程序的后腿。因此把一个Map任务给多个结点，取最快的运行结果，听起来有点浪费，但这个方法能将性能提升40%多。
应该不会考WordCount，那就是这个ppt的其他几个算法。
问题举例：
1. 单词同现矩阵算法
问题描述：一个超级大的单词矩阵内两个单词同框次数，框的大小可以视具体情况定义。
问题简化：一段话里有多少相邻两个单词的组合，每个组合出现了几次，进阶版WordCount。
问题拓展：相邻n个单词有几种可能的组合。
问题具体化：零售商通过分析大量的交易记录，识别出关联的商品购买行为。
2. 文档倒排索引算法
问题描述：通常是给出文档题目，可以找到文档；现在想要给出关键词，找到哪些文档里有这个词。
问题简化：每个词对应一个文档，WordCount反转版
问题进阶：带词频属性的文档倒排算法
一个倒排索引由大量的postings list构成
一个postings list由多个posting构成(按doc id排序)
一个postings list与一个term关联
一个posting 包含一个document id和一个payload
结构：<词，<文档，次数>>
3. 聚类算法
问题描述：将给定的多个对象分成若干组，组内的各个对象是相似的，组间的对象是不相似的。进行划分的过程就是聚类过程，划分后的组称为簇（cluster）。
问题具体化：给出n个点，期待把它们划成k堆，相邻的划成一堆。
K-Means算法：
选出K个点作为初始的cluster center
Loop:
对输入中的每一个点p：｛
计算p到各个cluster的距离；
将p归入最近的cluster;
｝
重新计算各个cluster的中心
MapReduce实现：
大概思路：每个结点存储一些点，每台机器需要知道其他center的位置，然后迭代计算。
这里只讨论欧氏空间。
map：<最近的cluster，点>
combine：<cluster id，[点的个数，(横坐标平均值，纵坐标平均值)]>
reduce：根据key合一合
梯度下降和图算法估计不考。
好接下来研究HBase、BigTable和NoSql，阿西吧ppt都不给你到底要考什么
还好加速大模型不考，要不然你把机器学习都考了你让机器学习考什么
7. 分布式数据库
7.1 BigTable
2006年，在一篇名为“BigTable：A Distributed Storage System for Structured Data”的论文中阐述了BigTable的设计原理，其主要特点如下：
是Google设计的分布式数据存储系统，用来处理海量的数据
是一个稀疏的、持久化存储的非关系型数据库；
可以在成千上万的通用服务器上管理PB级的数据；
7.2 NoSql
NoSQL，指的是非关系型的数据库。NoSQL有时也称作Not Only SQL的缩写，是对不同于传统的关系型数据库的数据库管理系统的统称。
NoSQL用于超大规模数据的存储。（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
——菜鸟教程
NoSql的分类
以下分类参照对象均为传统关系型数据库。
1. 列存储，如HBase。
特点：方便存储结构化和半结构化数据，方便进行数据压缩，针对某一列或某几列的查询情景。
2. 文档存储，如MongoDB。用类似json的格式存储。
特点：方便对字段进行索引。
3. key-value存储，如Redis。
特点：根据key快速找到对应value。
4. 图存储，如Neo4j。
特点：便于执行图算法，不咋常用。
NoSql与关系型数据库的对比
1. 存储格式
2. 扩展方式
关系型数据库：纵向扩展（加行）
NoSql：横向扩展（加列），分布式
3. 事务
关系型数据库：ACID
NoSql：更注重大数据的处理效率
4. 存储方式
关系型数据库：磁盘为主
NoSql：内存为主
5. 成本
关系型数据库：成本高
NoSQL：简单易部署，开源，成本低
7.3 HBase
HBase开源实现了BigTable。
1. 数据模型
HBase主要是列存储。
每一列成为Column，若干Column成为Column Family。
每行有行键。
每个值是一个字符串，不分数据类型。
数据只允许增加，不允许修改。
索引有行键、列族、列限定符和时间戳
关于列存储：
前提：对于特定的查询，不必要取出一行的每一个值。
好处：避免磁盘开销；同一列利于压缩；传输降低带宽消耗。
2. 体系结构
主从结构。
基于ZooKeeper，其提供集群监控和元数据维护功能，因此主节点工作负担较小。
· 存储结构
Client
Hmaster：管理增删改操作、负载均衡
Zookeeper
HRegionServer：工作节点进程
-HRegion：封装数据，最开始一张表对应一个Region，后来一个表可以对应多个Region。一个Region只会完整地在一个服务器上。
-Store：每个Region由一个或多个Store组成，每个ColumnFamily建一个Store。
-Memstore：一个。HBase将最近接收到的数据缓存在Memstore，完成排序，然后再快速的顺序持久化到HDFS。期间数据若发生变动，只保留最新版本。
-StoreFile：多个。
-HFile
-HLog：记录写入日志，保证数据安全。
· 索引结构
.META.表：元数据表，存储Region和RegionServer的映射关系。
-ROOT-表：记录.META.表位置。
3. 运行机制
· 写操作
1. 获取RegionServer
2. 写Hlog
3. 写MemStore
· 读操作
1. 读root表
2. 读meta表
3. 找到region
4. 先从MemStore（缓存）上读数据，缓存没有取StoreFile上读。
4. 应用案例举例
车联网监控系统
任务 ：
1. 采集车辆信息并上传
2. 解析信息
3. 存储信息
4. 提供高效的查询服务
数据规模：
- 1e5万台车同时在线
- 正常情况下，每辆车每分钟发送两个报文
- 报警状态下，每辆车每秒钟发送一个报文
- 报文平均大小1KB，解析后7KB
- 平均一辆车每天产生20MB数据
- 系统每天产生2TB数据
- 系统每天有2.9e8行数据要写入数据库
并发量：
- 3300持续并发量
- 1e6个长连接
- 每秒解析3.3MB数据
- 每秒存储23.1MB解析数据
5. Row Key设计
Row Key设计会影响到数据在HBase中的分布，还会影响查询效率。
长度原则： 可以是任意字符串，最大长度64kb。实际应用中一般10-100byte，一般设计为定长，建议不要超过16字节。
散列原则：设计的Row Key应均匀的分布在各个HBase节点上。——避免热点
字段选择：Row Key字段都应该参考最高频的查询场景。——高效查询
避免热点常见方法：
1. Reversing：头部均匀，尾部不均匀，因此将尾部提前，使其随机分布。牺牲有序性，不利于Scan操作。
2. Salting：在前面添加固定长度的随机数，同样牺牲了有序，不利于查找。
3. Hashing：将row key完整或部分hash，同样牺牲了有序，不利于查找。
