转载

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将会极大的提升分析性能。

原文 http://www.cnblogs.com/hseagle/p/5693008.html

正文到此结束