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

数据 和 分布式

数据系统基础

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

  • 可靠性

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

  • 可拓展性

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

    • 比如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.自动把消息重新发到崩溃的进程 , 防止消息丢失
          1. 解耦
        • 4.避免了发送方需要知道接收方的IP地址, 端口号( 在频繁变更的虚拟机中)很有用
        • 5.支持一条消息多个接收方
        • 6.逻辑上的分离, 发送方只管发送消息,不关心谁使用它们
        • 7.异步的

    • 分布式Actor框架

分布式数据系统

子主题 1

子主题 2

子主题 3

派生数据

XMind: ZEN - Trial Version

posted @ 2020-10-02 10:08  Yan_Hao  阅读(276)  评论(0)  编辑  收藏  举报