企业选择数据平台的方案,有着不同的原因,要合理的选型,既要充分的考虑搭建数据平台的目的,也要对各种方案有着充分的认识。

一、为何而搭建数据平台

业务跑的好好的,各系统稳定运行,为何还要搭建企业的数据平台?

这样的问题,心里想想就可以了,不要大声问出来。我来直接回答一下,公司一般在什么情况下需要搭建数据平台,对各种数据进行重新架构。

从业务上的视角来看:

1.业务系统过多,彼此的数据没有打通。这种情况下,涉及到数据分析就麻烦了,可能需要分析人员从多个系统中提取数据,再进行数据整合,之后才能分析。一次两次可以忍,天天干这个能忍吗?人为整合出错率高怎么控制?分析不及时效率低要不要处理?

从系统的视角来看:

2.业务系统压力大,而不巧,数据分析又是一项比较费资源的任务。那么自然会想到的,通过将数据抽取出来,独立服务器来处理数据查询、分析任务,来释放业务系统的压力。

3.性能问题,公司可以越做越大,同样的数据也会越来越大。可能是历史数据的积累,也可能是新数据内容的加入,当原始数据平台不能承受更大数据量的处理时,或者是效率已经十分低下时,重新构建一个大数据处理平台就是必须的了。

上面列出了三种情况,但他们并非独立的,往往是其中两种甚至三种情况同时出现。一个数据平台的出现,不仅可以承担数据分析的压力,同样可以对业务数据进行整合,也会不同程度的提高数据处理的性能,基于数据平台实现更丰富的功能需求。

二、数据平台的建设有哪些方案可以选择(下文中的优缺点仅从企业选型的角度,并非方案本身的技术角度)

如果一句话回答的话,那就是:太多了。虽然是一句废话,但确实有非常多的方案可供选择,这里无法一一介绍,所以就分成了下面几类,相信也一定程度上覆盖了大部分企业的需求了。

1.常规数据仓库:概念不说了,既然是做数据这一行的,相信你比我还要清楚,不清楚的可以百度。它的重点在于数据整合,同时也是对业务逻辑的一个梳理。虽然它也可以打包成ssas那种cube一类的东西来提升数据的读取性能,但是数据仓库的作用,更多的是为了解决公司的业务问题,而不仅仅是性能问题。这一点后面会详细介绍。

关于这一方案的优缺点,不写没用的,直接说重点了:

优点:

方案成熟,关于数据仓库的架构,不管是Inmon架构还是Kimball架构,都有着非常广泛的应用,而且相信能将这两种架构落地的人也不少。

实施简单,涉及的技术层面主要是仓库的建模以及etl的处理,很多软件公司具备数据仓库的实施能力,实施难度的大小更多的取决于业务逻辑的复杂程度,而并非技术上的实现。

灵活性强,说这句话要有对应场景的,数据仓库的建设是透明的,如果需要,可以对仓库的模型、etl逻辑进行修改,来满足变更的需求(当然,最好设计之初考虑的周全一点)。同时对于上层的分析而言,通过sql或者mdx对仓库数据的分析处理具备极强的灵活性。

缺点:

“实施周期长”,注意,我加了引号,对应下面的敏捷型数据集市,而且这点是相对的,实施周期的长与短要取决于业务逻辑的复杂性,时间是花在了业务逻辑的梳理,并非技术上的瓶颈。关于这点,后面会详细介绍。

数据的处理能力有限,这个有限,也是相对的,海量数据的处理它肯定不行,非关系型数据的处理它也不行,但是TB以下级别的数据,还是搞得定的(也取决于所采用的数据库系统),这个量级的数据,而相当一部分企业的数据,还是很难超过这个级别的

2.商业敏捷型数据集市:

底层的数据产品与分析层绑定,使得应用层可以直接对底层数据产品中的数据进行拖拽式分析。这一类产品的出现,其初衷是为了对业务数据进行简单的、快速的整合,实现敏捷建模,并且大幅提升数据的处理速度。目前来看,这些产品都达到了以上的目的。但它的优缺点也比较明显。

优点:

部署简单,敏捷开发,这也是这类产品最大的优点,和数据仓库相比,实施周期要短的多。实际上它也没什么严格的实施的概念,因为这类产品只是针对需要分析的数据,进行局部的关联,只考虑眼前要解决的问题就够了,迭代的能力更强些。

与上层的分析工具结合较好,上层的分析工具接入这类数据产品后,可直接实现数据的图形化展示和olap分析。

对数据处理性能的提高,这类产品都对数据的分析性能做了处理,虽然方式不尽相同,有内存映射文件存储的,也有分布式架构、列数据存储的。但无疑都一定程度上提高了数据的处理性能。

缺点:

首先,它是要收费的。

无法处理复杂的业务逻辑,这只是一个工具,它无法解决业务问题。这类工具中自带简单的etl功能,实现简单的数据处理和整合,而如果考虑到历史数据,考虑到整体的数据之间的逻辑和关系,它一定是解决不了的。一个简单的例子,当某个表中,有两个字段,一个要保留历史数据,一个要更新历史数据,要怎样实现自动处理。有一个观念是需要清楚的,不能指望一款工具来解决业务问题。这种数据产品仅仅是对当前的业务数据进行简单的整合,第一,数据是局部的,第二,时间是当前的(其涵带的增量更新或者全量更新,是无法应对复杂的逻辑的,相信熟悉etl的人都知道这个过程有多复杂)。当然,对于一些公司来说,可能需求只是对当前业务数据进行整合分析,那么这类产品就够了。(说实话,很多公司真的是懒得更长远的考虑,有一天没一天的,谁说的准呢)

灵活性低,这个也是没法避免的,越是操作简单的工具,他的灵活性肯定受限,因为封装住了,产品是不透明的,常规的需求用起来非常方便,但是遇到复杂的,发现对他内部不了解,你也没法修改,只有蛋疼的份。

从个人的角度看,它是很难成为公司的数据中心的。