海量实时OLAP分析平台方案.docx

海量实时OLAP分析平台方案分享大纲：海量数据实时OLAP场景的困境唯品会大数据实时OLAP升级过程唯品会在开源计算引擎上所做的改进OLAP方案升级方向海量数据实时OLAP场景的困境大数据首先来看一下我们在最初几年遇到的问题。第一就是大数据，听起来好像蛮无聊的，但大数据到底是指什么呢？最主要的问题就是数据大，唯品会在这几年快速发展，用户流量数据从刚开始的几百万、几千万发展到现在的几个亿，呈现了100倍以上的增长。对我们而言，所谓的大数据就是数据量的快速膨胀，带来的问题最主要的就是传统RDBMS无法满足存储的需求，继而是计算的需求，我们的挑战便是如何克服这个问题。慢查询第二个问题是慢查询，有两个方面：一是OLAP查询的速度变慢；二是ETL数据处理效率降低。分析下这两个问题：首先，用户使用OLAP分析系统时会有这样的预期，当我点击查询按钮时希望所有的数据能够秒出，而不是我抽身去泡个茶，回来一看数据才跑了10%，这是无法接受的。由于数据量大，我们也可以选择预先计算好，当用户查询时直接从计算结果中找到对应的值返回，那么查询就是秒出的。数据量大对预计算而言也有同样的问题，就是ETL的性能也下降了，本来准备这个数据可能只需40分钟或一个小时，现在数据量翻了一百倍，需要三个小时，这时候数据分析师上班时就会抱怨数据没有准备好，得等到中午分析之类的，会听到来自同事不断的抱怨。长迭代数据量变大带来的第三个毛病，就是开发周期变长。两个角度：第一，新业务上线，用户会说我能不能在这个新的角度上线前，看看历史数据，要看一年的，这时就要刷数据了。刷数据这件事情大家知道，每次刷头都很大，花的时间很长。旧业务也一样，加新的指标，没有历史趋势也不行，也要刷数据，开发就不断地刷数据。因为数据量大，刷数据的时间非常长，数据验证也需要花很多的时间，慢慢的，开发周期变慢，业务很急躁，觉得不就是加个字段吗，怎么这么慢。这样一来，数据的迭代长，周期变慢，都让业务部门对大数据业务提出很多的质疑，我们需要改进来解决这些问题。业务部门的想法是，不管你是什么业务，不管现在用的是什么方法，他们只关心三点：第一，提的需求要很快满足；第二，数据要很快准备好；第三，数据准备好之后，当我来做分析时数据能够很快地返回。业务要的是快快快，但现在的能力是慢慢慢，为此，我们急需解决业务部门的需求和现状之间的冲突。唯品会大数据实时OLAP升级过程第0阶段这是我们的初始状态，架构比较简单。底层的计算、存储和OLAP分析用MDB的数据仓库解决的，上层用Tableau的BI工具，开发速度比较快，同时有数据可视化效果，业务部分非常认可。GreenPlum是MPP的方案，它的高并发查询非常适合我们这种OLAP的查询，性能非常好。所以我们在这个阶段，把GreenPlum作为数据仓库和OLAP混用的实现。这样一个架构其实是一个通用的架构，像Tableau可以轻易被替换， GreenPlum也可以替换成Oracle之类的，这样一个常用的工具、一个架构，其实满足了部分的需求，但也有个问题，就是像GreenPlum这样的RDBMS数据库，在面对海量的数据写入时存储和计算的资源快速地枯竭了， GreenPlum的水平扩展有限，所以同样碰到了大数据的问题。第1阶段所以很快我们就进入了第一阶段。这个阶段，我们引入了Hadoop/Hive，所有的计算结果做预计算之后，会同步到GreenPlum里面，接下去一样，用GreenPlum去做分析。OLAP讲聚合讲的Ad-hoc，继续由GreenPlum承载，数据仓库讲明细数据讲Batch，就交给专为批量而生的Hive来做，这样就能把OLAP和数据仓库这两个场景用两个不一样技术栈分开。这样一个技术方案解决了数据量大的问题，ETL批量就不会说跑不动或者数据没法存储。但问题是增加了新的同步机制，需要在两个不同的DB之间同步数据。同步数据最显而易见的问题就是除了数据冗余外，如果数据不同步怎么办？比如ETL开发在Hadoop上更新，但没有同步到GreenPlum上，用户会发现数据还是错误的。第二，对用户来说，当他去做OLAP分析时，Tabluea是更适合做报表的工具，随着我们业务的扩展和数据驱动不断的深入，业务不管分析师还是商务、运营、市场，他们会越来越多地想组合不同的指标和维度去观察自己的数据，找自己运营的分析点。传统的Tabluea报表已经不能满足他们。我们需要一个新的BI解决方案对我们来说数据不同步还可以解决，毕竟是偶然发生的，处理一下就可以了。但是BI工具有很大的问题，不能满足业务已经进化的需求。所以我们需要一个新的BI解决方案：首先它要足够灵活，不能发布之后用户什么都不能做，只能看，我们希望它的维度和指标可以快速整合。第二，门槛要低，我们不可能希望业务像BI工程师学习它的开发是怎么做的