唯品会海量实时唯品会海量实时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阶段