• 为什么要做大数据平台？：数据量超出单机处理上限，需要把任务拆分给多个机器分布式执行
  • 为什么之前没有大数据平台？：分布式问题带来的成本 大于 完全单机处理的成本 (数据量没到阈值)
  • 大数据有哪些平台？：
    1. 数据管道 — 信息的传输
    2. 数据存储 — 信息的存储
    3. 数据计算 — 信息的计算

数据管道

　　如《数据管道思考》所述，数据管道可以根据消息在管道的 (入口、出口) 的 (推、拉) 模型划分出四个象限：

  1. 入口推/出口推：消息队列，如rabbitmq、mqtt
  2. 入口推/出口拉：数据渠，如kafka
  3. 入口拉/出口推：数据泵，如flume、fluentd、logstash
  4. 入口拉/出口拉：无意义，可被数据泵+数据渠方案代替

数据存储

分布式数据存储的北向交互接口可以分为三类：

  1. 块接口：SCSI是与块设备(如磁盘)交互读写某个扇区的协议，i而SCSI可以通过TCP协议交换SCSI指令。客户端可以使用iSCSI协议挂载远程的块设备到本地的目录，如远程挂载ceph提供的块设备到虚拟机
  2. 文件系统接口：通过NFS、CephFS等驱动可以将远程的文件系统挂载到本地的目录，如NFS
  3. 对象接口：客户端通过API的形式增删改查文件对象，如阿里云OSS

　　但上述三类的的接口底层存储能力本质是可以相同的，如ceph基于同一个底层存储能力，可以同时提供三类接口。底层存储能力将多台机器的多个块设备整合为一个存储池，同时提供存储的多副本容灾等能力。

不可能三角

数据计算

　　分布式数据计算引擎从分布式存储平台读取数据、处理数据，再写回存储平台
　　核心问题是如何将应用在一个数据集上的一个计算任务，拆分到应用在多个子数据集运行在多个节点的计算任务，即计算模型，计算模型有以下属性可以用来评估对比：

任务分解方式(任务可水平扩展为多个任务实例)：

  1. MapReduce1：1. 任务内单M单R；2. 多任务，任务间组DAG
  2. MapReduce2：1. 任务内多M多R，任务内组DAG； 2. 多任务，任务间组DAG
  3. SQL：针对sql任务的类OLTP数据库SQL查询计划生成，参考开源项目calcite

任务、节点间的绑定关系：

  1. MPP架构：本机只处理位于本节点数据
  2. 批处理架构：空闲节点可处理位于任意节点数据

中间数据：

  1. 写入硬盘
  2. 写入内存

用以上三个维度来观察各个计算引擎，也就能够推导出他们各自的优缺点：

  • Hadoop：MR1且中间数据写入硬盘，因此执行时间超长，但最稳定能够处理最大量的数据
  • Tez：MR2且中间数据写入硬盘，执行时间相对Hadoop要少，但内存要求更高
  • Spark：MR2且中间数据写入内存，结合更多的编程优化，处理速度更快，但处理数据大小受限于内存大小
  • Flink：MR2且中间数据流式处理、写入内存，每条数据到来都进行计算，处理延时最小

数据库

数据库怎么融入到上文的模型中？：数据库设计 = 数据存储模型 + 数据计算模型 + 查询接口模型

  • 数据存储模型落实在分布式存储平台，有些存储模型需要专用的存储平台支持
  • 数据计算模型落实在分布式计算平台，一种计算平台基本只实现一种计算模型

  • 查询接口模型是数据库提供服务的方式，如sql、kv等

  • 查询操作，是一种计算，因为查询除了简单的遍历，一定会提供更复杂的数据过滤和处理操作

  • 数据存储 与 数据计算是能够解耦的，如
    • Mysql代表的OLTP，数据存储使用的是本机文件系统，计算引擎是InnoDB等
    • Hive代表的OLAP，数据存储使用的是hdfs，计算引擎使用的是hadoop(除了hdfs的部分)
  • 数据库设计之初会根据面向场景，权衡决定：
    • 数据存储模型的通用程度、优化程度、索引冗余程度
    • 数据计算模型及各类编程优化手段
    • 提供的查询接口形式

OLAP数据库辨析

Impala：

  • 存储平台：通用的HDFS或HBase
  • 存储模型：通用的Hive存储模型
  • 计算引擎：专用的impalad
  • 计算模型：OLTP式的任务分解、MPP架构、中间数据写内存
  • 查询接口：专用的SQL解析引擎
  • 特点：
    • 复用Hive存储相关，基于MPP思路单独实现计算引擎及计算模型
    • 优点：不使用MR + 内存计算所以快
    • 缺点：每台datanode都要承担计算任务(MPP特点)；数据量受内存限制

Druid：

  • 存储平台：专用
  • 存储模型：专用
  • 计算引擎：专用
  • 计算模型：专用
  • 查询接口：阉割的SQL
  • 特点：
    • 数据需要导入druid，导入后即可查询
    • 计算引擎对数据根据时间维进行预聚合计算，提高查询响应速度
  • 优点：适合时序KPI数据
  • 缺点：专用系统的通病，且不支持全部sql查询功能

Drill：

  • 存储平台：通用
  • 存储模型：通用，可以使用HDFS文件、Hive表、mongodb等等
  • 计算平台：专用
  • 计算模型：专用
  • 查询接口：标准SQL
  • 特点：
    • 计算模型同样事针对SQL的任务规划，MPP架构
    • 优缺点类似Impala，但数据源要更加丰富，甚至直接查询json

Presto：

  • 存储平台：通用
  • 存储模型：通用，Hive等
  • 计算平台：专用
  • 计算模型：专用
  • 查询接口：标准SQL
  • 特点：
    • 计算模型同样事针对SQL的任务规划，MPP架构
    • 优缺点类似Impala，但数据源要更加丰富

Hawq：

  • 存储平台：通用
  • 存储模型：通用，Hive等
  • 计算平台：专用
  • 计算模型：专用
  • 查询接口：标准SQL
  • 特点：
    • 计算模型同样事针对SQL的任务规划，MPP架构
    • 优缺点类似Impala，但数据源要更加丰富

Kylin：

  • 存储平台：通用
  • 存储模型：专用
  • 计算平台：专用
  • 计算模型：专用
  • 特点：
    • kylin读取通用的源数据进行预计算生成数据cube存储到hbase，查询时直接查询cude从而加速
    • 优点：查询结果精确，查询性能稳定且快
    • 缺点：查询服务有单点，join查询性能有瓶颈；数据存储模型并不通用

Phoenix：

  • 存储平台：针对Hbase
  • 存储模型：通用kv
  • 计算平台：利用Hbase
  • 计算模型：利用Hbase
  • 查询接口：标准SQL
  • 特点：
    • Phoenix是专门针对Hbase的SQL方案，融入了Hbase从而在KV接口之上提供SQL查询接口
    • Phoenix将SQL查询翻译为多个Hbase的SCAN查询从而得到结果
    • 优缺点都来自于与Hbase的绑定

Hive：

  • 存储平台：HDFS
  • 存储模型：通用，其他数据库会尽量兼容Hive
  • 计算平台：通用
  • 计算模型：通用
  • 查询接口：阉割SQL
  • 特点：
    • 除了SQL引擎以外均的层次可通过插件替换
    • 优点：稳定
    • 缺点：慢，但Hive不受限于Hadoop引擎，同样可以运行在spark上

SparkSQL：

  • 存储平台：通用
  • 存储模型：通用
  • 计算平台：Spark
  • 计算模型：MR2
  • 查询接口：标准SQL

  • 特点：

    • 执行引擎限制为Spark，与Hive on Spark区别为SQL解析层不同，两者均比Hive on MR快很多很多

      思考：

  • 限定最少层次的是Hive，仅有SQL引擎层，其余层次均可通用替换，灵活性最高，性能优化手段就没那么丰富

  • 其次是SQL引擎、计算引擎、计算模型都是专用的数据库，如Impala、Hawk、Drill、Presto、Trafodion、Tajo，大部分都采用了MPP架构思想，本节点处理本节点的数据，总体优劣就是MPP架构的优劣，微观优缺点有很多优化手段、功能丰富度可以对比
  • 然后是仅数据平台通用的数据库，如druid和kylin，都是通过预计算从而提高响应速度，总体优缺点来自于他们均针对特定场景的优化，场景对了很舒服，场景不一致就不舒服，特点鲜明
  • 最后是所有层次都是专用的数据库，比如elasticsearch，称其为搜索引擎更好，全部的专用也就导致一定要有足够的原因让使用者去专门另外搭建一个数据库集群，比如elk的全文检索能力