OLAP在大数据时代的挑战

转行作数据相关的工做有近两年时间，除了具体技术，还有许多其它思考。

数据的价值

在涉及具体的技术前，先想想为何须要OLAP这样的系统，它有什么价值或者说在公司或部门这是不可取代的么？ 能够带来哪些价值，是直接变现仍是间接变现。 若是不能回答或回答不了，那么就是一个很大的问题，这其实意味着数据的质量存在问题。没有质量的数据，体量再大也毫无价值。

数据存储

假设已经有很好的oltp系统，那么oltp系统在数据量不大的状况下，继续扮演olap角色也还能够。一旦业务红火，那么oltp中的analyze部分势必会分离出来，也就是olap和oltp相互单独存在。

olap中存储大量历史数据，数据存储成了olap中要解决的第一个也是首要问题，这个需求的解决方案有多种，能够是HDFS，也能够是NoSQL数据库，也能够是Distributed RDBMS，当中的取舍要视具体状况而定。后面会涉及具体的考虑维度。

数据同步和ETL

如何将数据从oltp迁移到olap，这个同步机制须要考虑数据一致性，zero data-loss, 实时性要求等等。

数据查询

在大量甚至是海量的历史数据中如何快速定位到所要符合条件的记录？ 数据量若是在TB级以上，就须要考虑使用solr或是elasticsearch

数据分析

花了好多代价保存下来的海量数据，只是用了作简单明细查询，任何老板都不能容忍，必定要在历史的数据进行复杂的分析才行。这时候有一个好的分布式计算引擎就颇有必要了。如spark/presto/impala

数据挖掘

数据挖掘是一种比数据分析更为复杂的数据分析，呵呵，我的理解，有些绕。这个时候什么算法啦，什么机器学习啦，能够上场了。

big data or fast data

数据分析中还须要考虑到另外一个重要约束就是时间，若是但愿分析结果愈快愈好，那么就须要采用如druid这样的系统。

结果

若是数据规模在10TB如下，数据包含结构化和半结构化数据，明细查询中条件比较固定，不存在全文搜索。须要在比较短的时间内如秒级获得复杂分析结果，能够考虑使用distributed rdbms.

若是数据规模远远超过10TB，那么就须要将数据存储/数据查询/数据分析交由不一样的系统来处理，这个时候就须要组成一个技术栈来解决总量。如HDFS/solr or elasticsearch/Spark or Presto or Impala. 为了提高分析的效率，除了从distributed computing engine侧进行优化以外，还须要从存储侧进行优化，采用先进的存储格式如parquet/orc/carbondata将会极大的提高分析性能。