数据系统和分布式(一)数据系统基础

数据 和 分布式

数据系统基础

第一章. 可靠 可拓展 可维护的应用系统

• 可靠性

  • 出现意外情况, 硬软件故障,人为失误, 系统应该正常运转, 虽然性能降低, 但是功能正确

• 可拓展性

  • 随着系统规模的增长 , 系统应该合理的匹配增长

  • 比如Twitter的例子P19

    • 描述性能我们关心中位数, 百分位数
    • 比如P50代表至少一半用户查询等待时间是在这个时间之内的
    • 同样的还有99.99%这种
    • 实际上为了提高性能, 我们常常在垂直拓展和水平拓展之间做取舍

• 可维护性

  • 许多时间的推移, 新加入的运维人员应该比较容易适应
  • 可运维性: 运维更轻松
  • 简单性: 简化系统复杂度
  • 可演化性: 易于改变

• 常见术语

  • 现在的应用很多都有数据系统的很多模块
  • 数据库: 用来存储数据
  • 高速缓存: 缓存那些复杂或操作代价昂贵的 结果 加快下一次访问
  • 索引: 按关键字来检索数据 并支持各种过滤
  • 流式处理: 持续发送数据到另外一个进程 , 采用异步方式
  • 批处理: 定期处理大量的累计数据

第二章 数据模型 和 查询语言

• 计算机常常的分层结构, 在数据系统中也不例外. 在某个具体的层次上 , 我们关注的问题是 如何用下一层来表示当前层

  • 用数据结构对现实建模 -> 用json或者xml或者关系数据库的表进行存储-> 用内存, 磁盘或者网络的字节格式来表示 ->硬件用电流, 磁场来表示数据

• 关系模型和文档模型

  • 关系模型最出名的就是SQL
  • 子主题 2

第三章 数据存储 和 检索

• 从基本的层面: DB = 插入时存储数据, 查询时返回数据

• 哈希索引

• B树索引

• 事务分析和处理

  • 事务不一定有ACID属性

  • OLTP

    • 在线事务处理
    • OnLine Transition Process
    • 使用索引的某些键查找少量积累, 根据用户的输入 插入或更新记录 并且常常是交互式的
    • 比如博客的评论 ,游戏的动作
    • 基本访问模式和处理业务交易类似

  • OLAP

    • 在线分析处理
    • OnLine Analytic Process
    • 分析查询需要扫描大量的记录 ,并汇总一个信息
    • 比如 一个月店铺总收入 促销期间比平时多麦了多少香蕉

  • 数据规模 OLTP GB~TB OLAP TB到PB

  • 命名 常常OLAP单独在数据仓库上 因为不愿意让业务分析人员在OLTP上执行代价很高的操作 数据仓库有OLTP的只读副本

  • 采用数据仓库的目的是可以针对不同的分析访问模式进行优化

• 子主题 5

  • 子主题 1

第四章 数据编码和 演化

• 在内存里 ,数据保存在对象, 结构体, 数组, 哈希表 ,树. 把数据写入文件或者通过网络发送时, 由于指针对其他进程没有意义,所以字节序列和内存的大不一样

• Json

• XML

• 二进制

  • Thrift

    • Facebook开发的 07 - 08开源

      • 有两种编码方式

        • Binary Protocol

          • 对一个3字段的59byte

        • CompactProtocol

          • 只要34字节

  • Protocol Buffers

    • Google开发的 07 - 08开源

      • 类似CompactProtocol

        • 只要33Byte

  • 特征是 编码时不存储具体的字段名, 比如name, 而是用一个Tag来标识字段, 带来了更好的模式演化, 为以后拓展字段等

    • 旧代码读新代码写入的数据

      • 可以通过简单的忽略解决
      • 实现了向前兼容性

    • 新代码读入旧代码的数据

      • 字段必须为optional或者具有默认值
      • 实现了向后兼容性

  • 而且required 和 optional是在运行时检查, 在编码时不编码进去

  • Avro

    • 与前两个比, 优点在于没有标签号

• 数据流模式

  • 基于数据库的流模式

  • 基于服务的数据流

    • REST

    • RPC 远程过程调用 Remote Procedure Call

      • RPC存在一些问题

        • 本地函数可预测(只和参数有关), 网络请求是不可预测的, 网络问题很常见 ,请求或者响应可能因为网络丢失, 那是不是要有重试机制? 幂等性怎么解决
        • 本地要么return一个结果 要么抛出异常 要么死循环. 远程可能因为超时没有结果. 根本不知道发生了什么
        • 如果重试失败的请求, 可能请求已经完成, 只是响应丢失, 可能会导致执行多次, 除非建立( 重复数据)消除(幂等性)机制
        • 由于网络延迟, 函数执行时间很难说
        • 本地可以把引用或者指针传给本地内存的对象 RPC一定要编码成网络字节序列
        • 子主题 6

      • 子主题 2

    • 面向微服务的一个关键的设计目标是, 通过使服务可独立部署和演化, 让应用程序易于更改和维护

  • 基于消息传递的数据流

    • 也就是消息队列

      • Rabbit MQ,Active MQ, Apache Kafka

    • 优点:

      • 1.如果接受方过载, 或者不可用 .它可以作为缓冲区, 提高系统可靠性
      • 2.自动把消息重新发到崩溃的进程 , 防止消息丢失
      • 3. 解耦
      • 4.避免了发送方需要知道接收方的IP地址, 端口号( 在频繁变更的虚拟机中)很有用
      • 5.支持一条消息多个接收方
      • 6.逻辑上的分离, 发送方只管发送消息,不关心谁使用它们
      • 7.异步的

  • 分布式Actor框架

分布式数据系统

子主题 1

子主题 2

子主题 3

派生数据

XMind: ZEN - Trial Version