关于olap需求的一些思考

ER建模和关系建模

三种基于ER建模/关系建模/维度建模的数据仓库总体建模体系：规范化数据仓库，维度建模数据仓库，以及独立数据集市

本文将详细介绍数据仓库维度建模技术，并重点讨论三种基于ER建模/关系建模/维度建模的数据仓库总体建模体系：规范化数据仓库，维度建模数据仓库，以及独立数据集市。

数据分析概述：

• Impala、Presto、Spark SQL、Drill
• Druid、Pinot
• Kylin
• Trafodion
• Vertica
• hive

数据量、性能、和灵活性

Presto的性能比Hive要好上10倍多

Impala、Presto、Spark SQL、Drill、Druid、Kylin

其中presto和spark sql都是解决分布式查询问题，提供SQL查询能力，但数据加载不一定能保证实时

Druid是保证数据实时写入，但查询上不支持SQL，或者说目前只支持部分SQL，我个人觉得适合用于工业大数据，比如一堆传感器实时写数据的场景

Kylin是MOLAP，就是将数据先进行预聚合，然后把多维查询变成了key-value查询

从成熟度来讲：kylin>spark sql>Druid>presto

从超大数据的查询效率来看：Druid>kylin>presto>spark sql

从支持的数据源种类来讲：presto>spark sql>kylin>Druid

大数据查询目前来讲可以大体分为三类：

1.基于hbase预聚合的，比如Opentsdb,Kylin,Druid等,需要指定预聚合的指标，在数据接入的时候根据指定的指标进行聚合运算，适合相对固定的业务报表类需求，只需要统计少量维度即可满足业务报表需求

2.基于Parquet列式存储的，比如Presto, Drill，Impala等，基本是完全基于内存的并行计算，Parquet系能降低存储空间，提高IO效率，以离线处理为主，很难提高数据写的实时性，超大表的join支持可能不够好。spark sql也算类似，但它在内存不足时可以spill disk来支持超大数据查询和join

3.基于lucene外部索引的，比如ElasticSearch和Solr,能够满足的的查询场景远多于传统的数据库存储，但对于日志、行为类时序数据，所有的搜索请求都也必须搜索所有的分片，另外，对于聚合分析场景的支持也是软肋

OLAP需求大体分为两类：

即席查询：指用户通过手写SQL来完成一些临时的数据分析需求。这类需求的SQL形式多变、逻辑复杂，对响应时间没有严格的要求

固化查询：指对一些固化下来的取数、看数的需求，通过数据产品的形式提供给用户，从而提高数据分析和运营的效率。这类需求的SQL有固定的模式，对响应时间有比较高的要求 。

没有一个系统能同时在数据量、性能、和灵活性三个方面做到完美，每个系统在设计时都需要在这三者间做出取舍

MPP架构的系统（Presto/Impala/SparkSQL/Drill等）有很好的数据量和灵活性支持，但是对响应时间是没有保证的。当数据量和计算复杂度增加后，响应时间会变慢，从秒级到分钟级，甚至小时级都有可能

搜索引擎架构的系统（Elasticsearch等）相对比MPP系统，在入库时将数据转换为倒排索引，采用Scatter-Gather计算模型，牺牲了灵活性换取很好的性能，在搜索类查询上能做到亚秒级响应。但是对于扫描聚合为主的查询，随着处理数据量的增加，响应时间也会退化到分钟级。

预计算系统（Druid/Kylin等）则在入库时对数据进行预聚合，进一步牺牲灵活性换取性能，以实现对超大数据集的秒级响应

目前采用MPP架构的实时查询系统有EMC Greenplum、HP Vertica和Google Dremel，这些都是实时数据处理领域非常有特点的系统，尤其是Dremel可以轻松扩展到上千台服务器，并在数秒内完成TB级数据的分析

NUMA是一种体系结构，MPP是一种实时海量数据分析架构，而Hadoop是一个关于数据存储处理的项目群，其中的MapReduce是一种离线海量数据分析架构