这篇书评可能有关键情节透露
如何看理论书？不是上来就从头到尾看
要先看到大体脉络然后自己think会讲什么然后看和自己想的哪不一样尤其记录下问题
自己先有主动性思考，而不是被动的跟着书走
还要抓住主次，一本书最重要的2，其他8都是用来解释的如果2知道了，解释性的不用看
第一部分 数据系统认识第一章 可靠、可扩展、可维护性的系统think:
- 什么系统是好系统
- ？可扩展--随着时间，会有规模不够用情况发生
- 可维护性重要吗？
- 很多因素造就了可靠
------------------- 分成数据密集型和计算密集型-cpu ?内存密集型--是否也是由于数据量大造成的
- 可靠性 更多的是有意外故障，仍能正常提供服务
- 硬件故障 网络，磁盘等
- 人为故障？
- 程序故障--不可知的bug
- 可扩展性 随着规模增加，能很灵活的扩容
- 增加成集群模式
- 负载 是不断增加的，系统资源不变--就会效率降低
- Twitter的消息如何发送，一个人发出了Twitter，他的关注列表需要展示出来
- ？直接多个mysql关联查询
- ？缓存每个人的发送的消息
- 性能 用响应时间的中位数来描述
- p95--95%的请求能达到多少
- p99 99%的请求时间能达到多少
- 扩展
- 垂直扩展---把机器性能增加
- 水平扩展--添加几个相同的服务器
- 可维护性
- 简单性
- 可进化性
- ？关系型数据库是什么
- 各个表，或者字段存在什么关系？
- 基于sql的结构化的 sql是一种语言
- 抽象底层，使用人员更方便
- 表对于表示一个页面内的所有数据，有时候麻烦--拆表，关联表，合并查询等
- 文档型数据库？--底层存的就是文件
- 但关系型也是存的文件
- document 文档型 MongoDB
- nosql
- 不止sql,还有什么？
- 解决了sql中的哪些问题
- 所有提供sql服务的都是关系型数据库？
- java开发时候 对象和数据库数据不匹配
- 需要转换一层，才能读写数据库 格式不一样
- ORM object relation map java对象--关系型数据库映射
- 关系：一对一，多对一，一对多
- 关系型数据库适合多对一，如很多人在一个地区，很多人在一个国家
- 有一个地区表，能避免数据重复保存
- 适合高度关联的 图数据库更好---关系复杂
- 关系数据库的查询优化器--优化你的烂sql
- 文档适合一对多？
- 除了sql，还有jdbc连接器，直接硬代码增删改查
- 声明式语言？--我想要什么 命令式语言--具体每一步做什么
- MapReduce查询模型
- map操作每一条，reduce再把每一条相同的key聚合起来
- 多对多关系 用图
- 一对多的树，或者记录之间没有关系的用文档
- 顶点和边
- ？都代表一个库
- 不是边是库，顶点是join的某个key?
- 不同的图库
- 用sql来实现图数据？还是图数据库中实现sql？
- 三元存储与sparql
- ？三元存储--元数据，真实数据，计算可分离？
- sparql也不是sparksql
- datalog 不同的元数据
第3章 数据存储与检索think：
- 从最简单的实现一个数据库来说
- 写--echo就能写入
- 读--grep |sed就能找到
- 是不断追加的库
- log--日志，比喻不断追加的
- 日志类型数据库
- 查找的复杂度 O(n） 数据量翻倍--查询时间也会翻倍
- 如何查的更快？加索引--有了路标
- 但加索引会降低写入速度
- 既要更新索引，又要更新数据
- 索引类型
- hash索引 ？将数据随机分配一个路标打散？-hashmap挺重要
- key -value 是最简单的存储形式？
- 直接更新文件 vs 先追加文件，再合并相同key的数据
- hash表，要把所有key缓存到内存中，一一对应磁盘中的一个偏移量？
- SSTables
- 先把key进行排序，这样查找时候可以稀疏
- ？树状结构能实现按乱序插入，却能按同一顺序读出来？
- 读取时候先从内存，再从最新落盘的数据，再逐渐到更老的
- LSM-Tree日志结构合并树log-structured merge tree hbase用的这个？
- MergeTree 合并树 是说这个数据如何写入，是合并方式
- 写入是顺序写入的--吞吐量高
- 读取某个时间范围内有顺序
- B-trees
- ？B是 相比日志结构合并树的优点
- B-tree和LSM-tree最大的区别
- LSM-tree更新是追加数据，最后直接删除旧数据
- B-tree是直接覆盖数据，针对该数据的索引不变
- 直接覆盖数据，当量大时候危险
- 所以加了个WALwrite-ahead log 预写日志，先把变更写到日志中，再覆盖数据
- 当覆盖失败时候能从最新操作中恢复
- 直接覆盖，还有同时有查的，会查出数据不一致问题
- 设计中会加锁
- 设计
- 首先是按照顺序排序的
- 但是稀疏的，某个范围内有个子分支，同样有顺序的向下一级扩展
- ？按页保存在磁盘，页是磁盘的最小结构？
- ？纯磁盘，不是内存中
- ？什么时候不可靠
- 更新数据时候，tree慢了，查不到最新
- 查找数据时候太多慢了？
- 对比LSM-tree 和B-tree
- LSM写入更快？B-读取更快？
- LSM写入吞吐量更高 因为顺序写比随机写更快--磁盘上
- ?LSM为什么是顺序写的
- LSM能更好的压缩，？会定期合并压缩
- 存储空间小
- LSM的缺点
- 压缩会影响读写效率 ？是不断的后台合并压缩
- ？影响带宽 压缩不是本地的吗--需要传输吗
- 由于LSM会有一份数据的多个状态，B-tree只有一个数据的一份状态。B-tree更适合事务？
- 避免指向错误
- 其他索引
- ？LSM和B只是key-value索引 一个键能指向一个数据？
- ？二级索引，是再加一层索引，一级索引指向的是第二层索引
- 聚集索引 --？索引中保持数据位置
- 多列索引
- 级联索引 一次能查询多列？ 将多个字段组合成key
- 全文检索和模糊索引
- 查找的不是你搜索的词，可以是同义词，或者多一两个词组
- 内存数据库 内存中保存所有数据
- kv存储，Memcached 重启断电后数据没了
- ？如何恢复，定期保存到磁盘中快照--能恢复
- 内存数据库为什么快？是否因为从内存中读，而不访问磁盘？
- 数据结构更丰富
- 事务-不一定要提供事务处理--交易领域必须原子操作，有可能是点查询
- 不一定ACID原子，一致，隔离，持久
- 要低延迟读写，是对比批处理--周期性处理的概念
- 区别
- 读：TP返回存在的记录；AP返回表中不存在的数据，汇总的结果
- 写：TP要低延迟，随机写。AP批量定期写，一次写入很多
- 存的量：TP一般存少量最新，AP一般存全量历史
- 数据仓库 ？存大量的分门别类的所有数据 主要是不直接在业务系统上分析
- 星型，雪花型分析模型
- 星型 事实表--各个维度
- 事实表，其实就是大宽表把常用的维度表拆解出来
- 何为维度表？
- 常用的维度
- 多行数据中的重复数据拆解出来--成为某个维度
- 然后事实表中只保存维度表的key,通过key和其他维度表关联
- 雪花更复杂多级维度？
- 列存储
- 列压缩 比行压缩更紧凑？--同一列格式相同，能用不同的压缩格式--针对存储类型
- bitmap位图 ？是存储格式，还是压缩格式，还是索引？
- 内存带宽和矢量化处理
- 内存带宽？内存占用的带宽--同一个机器传输会有内存带宽吗
- 列存中的排序 ？每列数据中是否是排序好的
- 列存中的写
- 大多数LSM-tree B-tree为什么不合适？
- 聚合：数据立方体cube，物化视图view？
- cube是否是多维度，加上聚合？
- 是一种特殊的物化视图，只在某一维度，或者某几个维度上聚合
- 视图的意义？只提取一部分字段出来使用
- view只是虚拟视图，表的快捷键
- 物化视图，是把常用的聚合指标提前计算保存起来--真正保存好的
- Tp -磁盘寻道时间是瓶颈 Ap--网络带宽是瓶颈
- Tp中两大索引流派
- 日志结构 LSM-tree HBase,lucene 追加，删除旧数据
- 原地更新 B-tree
- ？指json,protobuf,xml等格式
- ？指编解码的格式，json,avro
- ?指保存在磁盘上的文件格式，txt, parquet,orc
数据编码格式：
- 序列化和反序列化 不是指从一个地方传过来后解码，或者在传输源编码 而是指在内存中和其他文件传输时候两个状态
- 数据的两种存在载体
- 从内存--》字节序列编码-序列化； 从字节序列-->内存 解码-反序列化
- 不同语言内置的序列化方法
- java的serializable，kryo
- ?序列化和反序列化背后做了很多事，不是直接传输过去就行
- json,xml,csv
- 二进制数据格式
- ApacheThrift --Facebook Protocol Buffers --protobuf --google
- 如何对字段进行压缩的？
- Avro
- 字段标签和模式演化 添加了字段，代码都得修改啊 protobuf不用修改可以兼容？
- 数据类型变了
- 流中也是json,在kafka中
- 对数据库的读写 也涉及到了编解码？
- REST或者RPC服务来传递数据
- Rest 用于http请求返回数据
- 问题都是由于网络调用，超时、无返回等问题
- REST公共api,RPC同一服务内子模块之间调用
- thrift，avro都提供rpc，protobuf -gRPC
- 消息队列
- Actor模型 ？akka通信
第5章 数据复制think：
- 一些算法，panxs,raft
- 都怎么实现的？
- 比如一个block如何复制三份
- 先写一个成功，然后其他的从这成功的复制不行？
- 还是至少两个成功才算写入成功？
- zk起的什么作用？还是保存更新各个状态？
- 高可用
- 把数据放到本地，离用户更近
- 数据分散保存，提高访问吞吐量
复制的方法：有的总有一个leader
主节点与从节点
- leader做什么？
- 写入先写入？复制从这复制？读也从这读？--主从都能读--那压力是否很大
- 切换状态是zk可维护
- mysql MongoDB kafka都是主从复制
- 同步复制与异步复制
- ？一般不都异步提高效率吗
- 是说是否等从节点复制完，返回确认后，主节点才返回给客户端--更新完成
- 同步 等从节点复制完成返回确认后再确认更新完成
- 异步不等，不管
- 半同步
- 只有一个从节点要同步确认，避免从节点没有复制完--主节点挂了
- 异步效率高吞吐量高，同步可用性高
- 配置新的从节点
- 增加新的副本？或者有旧的不能用了
- ？直接复制为什么不行--因为随着时间还有不断写入的
- 某个时间点前的数据快照--先复制过去
- 节点失效后怎么办
- 从节点，旧的节点删除，新的增加
- 主节点坏了？
- zk保存状态，主备状态切换 --服务也真正主备切换
- 一般流程
- 发现主节点故障 一般是设置leader服务超时时间，就认定为故障
- 谁去检查，检查人网络不行怎么办？--会发现都有问题
- 选举出一个最好的从节点作为主节点
- 使用方客户端要知道
- 切换后问题
- 原来的主节点和现在的主节点数据差异过大
- 脑裂，两个主节点都提供服务--比如原来的主节点网络抖动又好了
- 复制的具体实现
- 基于操作记录的复制 mysql根据所有操作记录来复制？--rand函数产生的不一样每次
- 预写日志WAL 先把更改日志记录上，再慢慢写真实数据
- 基于行的逻辑日志复制 ？对每个record都进行复制
- 基于触发器的复制
- 复制滞后的问题 一旦出现有什么影响？--决定了要强一致性还是弱一致性
- ？复制肯定需要时间，同时被访问时候--访问到的不是最新数据？
- 最终一致性，从节点可能比主节点晚更新，但最终会相同
- 读写一致性
- 用户更新了，就马上要看到自己的内容
- 此时不能滞后--异步有可能滞后
- 解决 某用户更新的自己的内容，可以只从主节点读
- 用户只是读，每次读的只能更新、不能回滚的更旧数据
- 解决 每个用户只从某一个副本读---对用户做hash分组，而不是随机分-随机会每次读的副本不同
- 有因果关系的读，两条数据有顺序，读的人不能先看到果，再看到因
- 多主节点复制
- ？首先保证两个主节点一致
- 多个数据中心
- 每个中心设置一个主节点 复制数据时候，减少几倍的数据传输
- 离线设备
- 没有网络时候先存在本地，有网络再更新到远端
- 这样本地算一个主节点
- 多人同时编辑一个文档
- 处理写的冲突
- 多个主节点同时写相同文件 会有冲突 类似git
- 检测冲突 ？
- 或者避免冲突 相同的文件更改，只会在一个主节点操作执行 有可能造成数据热点
- 记录一个时间标记 哪个晚按哪个更新
- 12306抢票，其他购物 都是冲突
- 如果超过2个主节点，十几个，如何保证多个主节点数据相同
- 肯定要互相同步，保证所有相同
- 环形拓扑 1-2-3-4-1
- 星型拓扑 中间一个1 ，其他都和一交互
- 全部-全部 全链路拓扑 1和其他3个进行交互，其他节点也一样
- 无主节点复制 cassandra
- ？没有主节点，那从节点都是主节点 ？类似于多个主节点
- 写入时候有节点失效
- 等节点恢复 读取数据不是最新？--读的时候向多个副本请求？--得到最新的版本号？
- 写入时候至少多少个成功？然后读取时候至少读取多少个就能保证能得到最新值？
- 比如5副本，写入--3个成功了，2个失败--则至少读2+1个副本才能得到新值
- n副本 写入m成功 n-m失败了， 则至少读n-m+1个副本
- 监控旧值
- 冲突解决
- 多个主节点中的数据不一致？
- 写入顺序如何判断？不同的顺序怎么确定先后，尤其多个主节点
- 类似索引，为了读取更快，能筛选更快
- 如何实现？
- hive里是不同分区不同目录，读哪个分区只读取那部分数据
- kafka分区
- spark分区
- 增大并发，并行计算能力，将数据拆分更小，将计算增加更多
- ch,kudu,es分片，shards
kv类型数据分区
- ？hbase region es的shards
- 如何设计分区
- 分区中数据均匀分布，则处理时间快
- 否则数据倾斜--存的数据不均匀，导致并行计算有的慢
- 最简单的数据随机均匀分配--但读取时候又得遍历所有分区
- 区间分区--即range分区，基于某些字段如时间范围
- 按范围且排序存储
- 这样读取时候只会读某一个分区
- 带来问题，数据热点--某个分区被很多请求访问
- 哈希分区--基于某个字段
- 数据分布均匀
- 问题：不连续，随机打散
- 当读取所有的数据，对所有数据进行相同计算时候--这个更好
- 当只读取某个范围内数据时候--区间分区更好
- ？二级索引，可以理解为分区后的数据再进行一次拆分--建立索引？
- 分区是真实的数据拆分，索引没有将数据拆分，而是增加了索引--来对应原始数据
- 基于文档分区的二级索引 ？文档分区--es Cassandra
- 在每个分区下，对字段建立一层索引
- 所以每次读要并行读取所有分区
- 全局索引--及对整体数据的索引，而不是每个分区建立一个索引 基于词条的二级索引
- 以前每个分区都维护自己的索引，所以每次查都要并行读取所有分区
- 现在只需读取一个全局索引
- 这样全局索引压力大，全局索引也可以做成分区--range区间分区
- 当数据倾斜？--新增分区或者降低分区，造成数据不均匀?
- 要求：数据移动过程中不影响正常服务，数据移动越少越好
- 自动平衡的策略 动态平衡？--随着数据增长--如何让分区中数据均衡？
- 不用取模，是因为节点增加或减少，取出的模会变化--增加数据迁移
- 固定分区数量，在建立时候就建立更多富裕的分区，当节点增减时候，只把分区分配到不同节点
- 动态分区
- 按数据量大小进行拆分或合并
- 如hbase，一个region分区会随着数据增长都某值，分裂成两个分区
- 会讲多个分区数量少的分区动态合并
- 按照节点数量
- 每个节点上分区数量相同，增加一个节点，则以前的数据内数据存的量就减少
- 重新调整分区，需要手动操作还是全自动系统执行
请求路由
- ？前面加一层lb?--loadbalance
- 如何确定某个分区数据在哪个节点？
- zookeeper能保存分区和ip的动态对应关系？
- 两种查询方式
- 以前说的点查询和查询数据中没有的--聚合计算
- 其实也是读写某个关键字内容，或者并行读取所有内容
深入理解事务
- 新兴的大数据类型数据库放弃或弱支持事务
- ACID和BASE
- atomicity 原子性
- consistency 一致性 写入后能保证写入准确？
- isolation 隔离性 写的时候能否读？
- durability 持久性 更新后永久保留最新值
- BASE
- basicallyavailable 基本可用
- softstate 弱状态 什么状态？
- eventualconsistency 最终一致性
- 原子性
- 原子--最小不可分割
- 执行一系列的操作，中间没执行完，则回滚，把中间更改的操作回滚
- 其实一项流程，数据写入也要有原子性
- 一致性
- 隔离性
- 持久性
- 多对象写入，与单一对象写入 ？是指同一时刻某数据是否有多个client操作吗
- 不是，是指某个事务会操作多个对象，比如更新某个字段，但这个字段还是另一表的外键；或者图数据库中的关联
- 脏读，读的是脏数据，脏数据哪来的？另一个事务写入一半，只写了个中间结果
- 事务失败时候终止，还是重试？
- 严格按照串行执行 对两个事务串行执行？
- 要单线程执行？ Redis是这么做的？
- ？存储过程是什么
- 数据必须完全在内存中？
- 分区，能提高串行化的并发 没有分区，那只能单核执行
- 两阶段加锁 最常用
- ？哪两阶段 wal和真实数据？two-phaselocking 2PL
- 并发写加锁；修改后--另一个事务读取，也要等修改提交成功后再读取
- 实现：用共享锁和独占锁来控制多个事务的读和写
- 问题：死锁--两个事务都在等待对方释放；并发性差--一旦有竞争，就会等待
- 谓词锁：解决幻读
- 会检查其他读的命令是否和我现在读的相同，避免我的写影响对方的读
- 索引区间锁
- 可串行化的快照隔离 乐观锁？ ？快照能可串行化
- 乐观锁 在提交时候才检查是否有冲突，有就终止提交；
- 悲观锁 先检查是否有并发事务，有就等待，
- 检查并发事务，是否会引起幻读
- 检查这次读，是否有写入没有提交
- 写时候，检查是否会影响其他读
- 多个副本的数据复制后一致性
- 主从节点故障切换
- 读写延迟
- 各个服务的rpc通信实现
所有可能出错的地方一定会出错 只有把可能出现的问题想到，并提前做好防御，才能在出现时候平稳度过
故障与部分失效
- ？整体不能用，还是部分节点、服务不能用？
- 单节点服务，要么能用，要么不能用
- 分布式集群，要具体详细的看多个节点的问题
- 有可能只有一些不能用，但不能影响整体服务，服务不能停
- 发出去不知道是否发送成功，所以要让接收方回复才行？
- 网络故障
- 检测故障
- 延迟--应该有个超时时间，过了这个超时时间，不管正常与否--都认为服务失败
- 超时时间设置太小，容易误判 其实服务还正常--比如gc中
- 太长,受影响时间长
- 网络拥塞--还真有带宽打满情况
- tcp与udp
- tcp可以发送失败后重传，保证可靠性。但延迟就高了
- udp无法重传，但是延迟低。可以用在视频会议或电话中。--重传没有意义
- 网络交换机
- ？是机器的统一出口
- ？还是某个目标机器的统一入口--对于该机器的某个端口消息顺序处理
- 一个端口接收很多机器发来的消息，是顺序传递这些消息的
- 一旦顺序传递消息，那传来的消息多时候，就会拥堵排队
- 目标主机的cpu--来处理接收的消息？--处理不过来也会排队等处理
- 带宽，CPU资源是动态被分配的，各个传递方会有竞争，总是为了更快的传递和处理完
不可靠的时钟 ？不同机器的本地时间
- 使用上有某一时刻时间点，或者某个时间段
- NTP networktimeprotocol
- 绝对时间与相对时间
- 绝对时间--1970年以后
- 相对时间--为了测算一个时间范围
- 多路cpu--每一路CPU时间不同？--时间不是机器统一的？
- 机器上的时间也是靠硬件--石英钟同步的？--每个电脑都有个石英钟？--不是直接网络同步的吗
- 时间戳引起的消息顺序不同
- LWW last write win最后写入获胜 当多个写入修改某个值时候，最后写入会覆盖之前的
- 如果是分布式，每个机器消息的时间戳有差异，有可能旧值的消息时间戳更早--不是最晚的--就不会是最后结果
- 时间用置信区间表示--用一个范围表示，而不是某个值
- 分布式的快照数据会受时钟影响
- 不同机器需要统一的时间id，spanner用的置信区间--而不是误差范围更大的单个时间戳
- 进程暂停
- 例子：java gc，磁盘i/o时候--程序也会暂停等待？
- 如果进程中有定时操作，其他进程和此进程有定时上的约定，暂停后其他进程会认为此进程挂了
- 如何保证实时
- 减少GC的影响
- gc之前发送信号，不往此节点提交请求
- gc时候，把服务托管给其他节点正常处理请求
- 选举，多数投票决定一个决策
- 不能依赖某一个节点，因为这个节点看到的信息不一定是准确的--他是从他身上看的
- 要多数都认为该节点有效、失效，才做决策
- 主节点与锁
- 某些服务只能一个主节点，或者每次要加锁--只能一个人操作
- fencing令牌
- 加锁的时候，给个令牌--递增？避免暂停进程后续又操作
- zookeeper就能实现唯一的锁？
- 拜占庭故障
- 有恶意攻击，造成分布式中的一个节点故意发布错误信息
- 防御编程 对会遇到的错误：用户输入，防火墙等做好错误处理
- 理论系统模型与现实
- 计时
- 节点失效的分类
- 崩溃--终止服务
- 崩溃--一段时间后又自动恢复
- 拜占庭故障--会伪装欺骗
- 算法的正确性
- 安全性和活性
- 安全性--必须达到的目标
- 灵活性--需要在某些条件下才能达到的目标
- 一致性？多个副本最后数据要一样
- 共识？--常见的规则？cap base?
- 分布式服务中的各个节点如何达成共识？--有相同的规则遵守，出了问题能找到统一的解决方法
- 常用算法协议zk和hadoop的 kudu的raft
- 级别
- 最弱的是--最终一致性 可能很长时间才会一致
- 强一致性--就会牺牲一些性能：吞吐量，延迟
- ？类似于串行化，先保证一致再返回写入成功
- 虽然底层是多个副本，但读取的看起来是一个副本--要保证所有读取的结果一致
- ？读取只读取某个特定leader
- ?读取只读取某个快照
- 如何实现可线性化 ？还是哪些场景需要
- 在写改变值时候，所有的读取，一旦有一个读到了新值，那以后所有的读取都要是新值
- 加锁与主节点选举
- 主从复制，只能有一个主节点？》
- zk实现了分布式锁？ ch的复制用zk--更新分区状态
- 唯一性约束
- 同一信息经过不同系统存储或者传播，有可能结果会不同
- 实现线性化
- 主从复制--如果真的只有这一个主节点提供服务，那就行
- 共识算法--能实现只有一个
- 多主复制、无主复制不太行，有可能多个节点同时写入
- CAP理论 一致性，可用性，分区容错性
- 一致性--即可用性，
- 网络正常时候，一致性和可用能共存
- 网络失败，要么等网络好了要一致，但这是不可用；要么可用，但是不保证数据一致
- 数据传递的顺序？有些数据进来，是有依赖关系的，后边的依赖前面的--乱序混乱
- 线性化一定是有因果关系，但有因果关系不一定是线性的？
- 用时间戳，或者递增的id来标识顺序
- 全序广播
- 多个分区的所有数据有顺序
- zk的zxid就是单调递增的全序广播？
- panxsix与raft协议？
- 共识应用场景：leader选举，原子事务--要么成功，要么回滚
- 原子提交与两阶段提交
- 2PCtwo-phasecommit 两阶段提交。
- 是都写入成功后。第一阶段先检查一遍？第二阶段再提交？
- 增加了一个协调者来处理验证是否同意提交
- 协调者挂了？
- 被写入节点会超时回滚？
- 协调者需要先把信息WAL记录下来？
- 类似于http请求，需要返回确认信息
- 分布式的事务，比单节点的事务更复杂
- extractly-once 消息仅消费一次
- XA api是一种两阶段提交事务的标准，各个语言都有具体实现
- 共识算法
- 常用：VSR，Paxos,Raft,Zab
- Epoch和Quorum
- zk也是存数据和数据库的区别？
- 存的很少，在内存中
- 当存的数据变化了，使用方能订阅自动被更新到
- 但更新频率很低，小时，天级别更新
- 一秒更新很多次的用 bookeeper?
- 分布式锁？选举主节点是zk做的？
- 保存不断变化的信息
- 场景：、
- 多个节点中选举出主节点；
- 分区数据和节点的对应关系---hadoop中是保存在zk的？--不是journal吗
- 服务发现，服务起来后注册到zk。调用方--直接查询zk 分布式sparkthrift可以用这个
- 成员服务：如DataNode中哪些节点正常和不正常 ？是用zk保存的吗
- mapreduce
- 对数据分批并行处理，算子越来越丰富
- 操作的不是一条数据，是大量的
- ？但是算子内，每个分区内也不是一条条处理的？分组处理？
- awk,sed,sort,uniq,xargs
- 这个不用在内存？直接cat磁盘读取后就能排序？
- 管道 一部分程序只执行特定的功能，串联起来
- 使用其他语言程序，要循环计数，要在内存中保存数据
MapReduce与分布式文件系统
- 计算靠近数据---？spark程序一直报错，提交不了exe，一直往特定的ip提交，是因为数据就在那两台机器上？
- MR类似是在多台机器上并行执行Unix工具，而开发者不用考虑每个机器上的并行、协同处理、数据传递
超越MapReduce
- 增加了算子？执行过程DAG？
- DAG图，原来是把算子--运算符用图连起来，表示数据计算过程--尤其哪些算子能有连续性，哪些要打散
- 检查点，是保存的图中的不同计算节点的状态数据--一旦有错误，可以从上次计算重新执行
- sql化
- 中间过程数据不落地，直接内存计算，执行很多连续的步骤
- 不落地，中间有错误怎么办？
- 有些算子需要所有数据进来后，有些不用
- 比如全局排序--就要所有进来
- 比如一段时间的排序--就一段时间进来后再排序？
- 存储层 kafka
- 处理 stormsparkstreaming flink
复杂的可用系统总是从简单的可用系统发展而来，反过来：一开始就想造一个复杂系统--永远也不可用 ？先从简单开始做起，一步步面对问题和改进--不断复杂，而不是一开始就要搞一个复杂的却从不开始做
批处理--处理有界的数据--界限是针对时间的，只处理某个时刻之前的数据，不变数据流处理--数据无界限，每个时刻都源源不断进来---但是处理真是来一条处理一条？
发送事件流
- 持续的发送就行
- 如果用数据库，来了新数据不好直接就收到订阅--然后处理
- 消息队列
- 一个生产者，要有多个不同消费者处理
- 问题：
- 生产者发送的快，消费者处理不过来怎么办
- 消息队列有节点挂了怎么办
- 生产者和消费者直接通信--更快，但更容易丢失
- 消费时候，如果队列有多个分区--整体不是有序的
- 存多久，按说消息系统是进来消费完就消失，数据库是永久保存
- 基于日志的消息系统 kafka
- 分区内有序，offset是分区的范畴--不是整个消息队列
- 不断追加新消息
- 吞吐量高 ？磁盘中顺序io
- offset偏移量 是消息的先后顺序标记
- 消费者也会记录上最后的一条记录offset，这样比他小的就是消费完的，大的就是没有消费的
- 变更数据捕获CDC--changedata capture
- 首先得有初始快照，然后此后的变更才能连接上
- kafkaconnect能记录所有数据库的变更？然后写到kafka?
- 事件溯源
- 数据的最终状态
流处理
- 场景
- 监控实时
- 复杂事件处理 complexeventprocessing CEP
- 流分析--统计窗口--聚合操作的一段时间间隔
- 流的时间
- 窗口--一段时间间隔
- 事件发生的时间，处理事件的时间
- 事件发送过来延迟，如何计算窗口再？是丢弃？是更新原来的处理？
- 使用什么时间？用户操作的时间？--客户端记录；请求服务器的时间；服务器收到数据的时间
- 窗口类型
- 滑动 会有重合事件
- 滚动 不重合事件
- 会话窗口 某一个session的时间段，或者某个用户id活动的时间段
- 流join
- 流和流join
- 搜索流和点击流的join，计算点击率
- 点击流在后，需要设置一个时间范围--比如搜索发生后的1小时内到达点击就join上
- 流join对两个流有时间依赖性，需要一个在前一个后
- 但没有相互依赖关系怎么？还是类似于快照-设置某个时间的版本
- 容错
- checkpoint，微批处理--ss也是cp把
- exactly-once 不只是处理，还包括写入，整个流程恰好一次才是
- 幂等性？
- 流批一体？但是现在各有优势
- 更能整合--从接收到处理到落地到使用，统一大平台
- 智能检测故障--应对
数据集成
- 现在是没有统一的一个技术能解决某个问题，有不同的技术---都有优缺点
- lambda架构
- 流处理和批处理并行，流处理快--不稳定，批处理慢--能精确
- 数据进来后，只追加不删除和更新？
- 不同类型的数据库对比？数据量大后根据功能拆分不同的分库？-或者不同类型的库存储？
- 联合查询：统一读 presto
- 分离式：统一写，一次写入--到多种不同的库
- 更简洁的类似Unix shell的工具？ mysql | ES -->就能把mysql数据同步到es
- 数据处理程序管理--如yarn；和数据存储-库，仓库 分离
- 查的慢了--》建索引，不用扫描所有数据--》还慢，那就把常用的查询预计算出来，不用去算
端到端的正确性
- exactly-once不是一个系统的事，需要整个流程中的子模块都能一致才行。flink-kafka-flink--mysql
