以下内容根据演讲PPT以及现场分享整理而成。

数据分析业务模型

首先介绍一下数据分析的业务模型，以及遇到的问题。博雅立方作为一家数据分析的公司，数据来源是非常多样的，而且我们未来希望形成一个大型的平台，在这个平台上的数据将会是用户自定义的形式的，而且用户的数据源将会是非常多样化的。

在这样的业务情况之下，要做的第一个步骤就是进行数据采集，也就是让用户定义自身的数据类型并且进行采集。数据采集完成之后就进入了第二个步骤，也就是数据分析。在数据采集完成之后导入到某一个地方去，汇总之后对于数据在各个层面，各个维度或者角度进行分析。第三个步骤就是数据的展示和输出。整体业务看似是一个非常传统的业务，但是其实其中有一些传统情况下很难遇到的问题，其中最主要的问题就是数据量的问题。

数据分析的业务需求

1. 数据有自定义的源和自定义的格式，需要支持数据格式的任意的扩展。
2. 数据密度相对高，每天进入的数据可能达到10T，数据总量是一个累计的过程，每次进行数据分析时可能用到大量的数据。
3. 在对数据进行分析、处理、挖掘和筛选的过程中用到工具、方法与手段众多。
4. 服务对响应时间非常敏感，线上系统需要响应时间在秒的量级上。

为了满足这样的需求面临什么困惑呢？

1. 数据的存储方面，有同学就会有疑问为什么要一定存储在传统的数据库中呢？可不可以使用Hbase，redis，mangodb…?为什么要使用分析数据库呢？
2. 数据的分析方面，是不是使用传统的数据分析工具就足够了呢？比方说Hadoop，spark，R…?这些工具是不是就能达到我们的目标了呢？

其实这些还不够的，因为存在着不可预先处理的需求和实时响应的矛盾，而且数据起始的参数是由用户实时提供的，比如用户需要在某些特定的维度在某些特定的条件下，迅速得到数据的查询和分析的结果，所以使用Hadoop算上几十分钟到几天这样的效率是无法接受的。要求的是在几秒钟之内用户就可以得到结果。而且由于一次查询的数据可能达到几个TB，即使不考虑程序是否具有真正的处理能力，也不考虑数据在程序中占用的内存空间，也至少要考虑网路带宽的问题，几个TB的数据就无法在规定时间内完成向指定节点的传输。

数据存储器和分析器合二为一

所以我们很快意识到需要这样的一个数据存放的地方，而这个数据存放的地方本身就具有处理数据的能力。数据不需要离开本身存放的地方就可以得到最终需要的分析结果，并且在数据处理完成之后能够进行各种各样的输出，甚至主要的分析功能也是在数据存储区进行完成。

此时就对数据的存储部分有了较高的要求，其他的存储方式无论是Hbase，redis，还是mangodb都无法达到要求了。比方说Hbase、redis、mangodb都不具备数据分析和输出能力或者数据分析和输出能力很弱；Hadoop和spark同样也不适合实时计算，即使目前spark号称在性能上有了较大的提升，对数据量有了更好的支持，但是仍然无法满足响应时间的要求，就算是能满足时间要求，也无法在指定时间内将数据从存储区域传输到分析节点上。

在这样情况下，就要求对于数据的存储和处理放在一起，也就是在存储数据的地方本身就能够具备数据转化和处理的能力，即数据存储与演算一体化。此时就要求存储系统必须具备分析计算能力，包括强数据类型，运算操作符，处理数据的逻辑关联（笛卡儿积、集合运算），支持复杂处理过程（函数，批处理，事件响应…）。这时候又回到了关系型数据库，此时的关系型数据库应该充当的是数据的计算器的角色，它成为了数据构建过程中的最重要的组成部分。

初期的选择：POSTGRES

当然对于关系数据库而言，可选择的范围比较广泛。初期我们选择是POSTGRES，因为其一些特性更适用数据分析业务。

POSTGRES的一些优点：POSTGRES具有多样的数据类型及处理能力。它可以支持数据类型的多样性，而且针对不同类型的数据进行处理，支持如地理和空间位置信息，格式化数据信息（网址、邮箱、ip），数组…等多种多样的数据类型，而且还支持自定义数据类型及其处理函数、复合数据类型以及可扩展数据类型的框架。

因为系统要支持用户对于数据类型进行自定义，可能会出现自定义数据格式与强类型的矛盾。首先，由于数据schema的可定制，决定了数据流的不确定性。其次，由于数据在存储器上即可进行业务逻辑处理，决定了数据流必须能转化为强类型。第三，数据采集模块与业务逻辑无关，不宜知悉具体的数据类型。第四，采集存储的数据需长期保持完整的原始信息以备后用，并容易根据不同的业务需要分解和转化成各种格式化数据表（schema）。所以在数据存储的时候使用了JSON格式，因为很多的数据其实就是JSON格式，即使不是JSON格式也会很容易转化为JSON格式，其实还要要求数据库容易将JSON格式转化为其他的数据格式。

POSTGRES还有一些其他的特性，比方在大数据量下处理能力的稳定性很强，而且具有弹性灵活的集群扩展能力和强大、丰富的工具集和可扩展的演算和处理能力。并且拥有开放的环境，易于定制和扩展以及高质量社区支持。

POSTGRES面临的现实困境

但是使用POSTGRES还面临着现实的一些困境。由于POSTGRES对于大数据量的支持还不够，所以无法实现数量和响应时间的双重保证。而且传统数据库由于设计原因存在无法逾越的边界，被CPU的能力所约束。而且因为单处理器的能力难以大幅提升，瓶颈无法突破。对于计算稀疏，但是数据量大的场景，单CPU显然无法满足需求。在过去的十几年里，摩尔定律失效了，需要将计算能力的扩展方向转向多核心。目前来说并行计算成为当前提升计算能力的主要发展方向。

而且因为信息时代来临太快，全社会的数字化发展的速度远远超过CPU发展的速度。众多数据使用者面临的问题已经超越数据库的边界，数据库技术不作革新，将无法使用。就我们面临的问题而言，典型计算达到响应时间要求的，数据量不宜超过million，而现实的问题规模却为billion级别。

新的选择：Greenplum

所以为了应对这些困境，我们选择了Greenplum数据仓库是因为它在原本POSTGRES增加了一些新的特性。

1. 继承POSTGRES的优良特性，容易吸收POSTGRES生态中的有用资源。
2. 克服传统数据库的物理边界，并行计算的透明化(简化开发)。
3. 面向大数据量的体系架构设计(segment、列式存储）。
4. 方便灵活，容易定制和扩展的分布与聚合。

当然Greenplum也是会有一些局限需要开发者、数据库提供商和阿里云这样的云计算厂商共同去应对。比如：

1. 设计、使用、部署和维护具有难度，专业性更强，须对数据敏感，技能要求也高。
2. 依然存在边界，网络、IO等瓶颈因素，决定其无法无限制的扩展。
3. 并非所有的计算问题都能转化为可并行计算的。

所以，数据仓库与hadoop等数据分析系统并非竞争，而是各司其职，相互补足的关系。

为什么要选择Greenplum？

中小企业的计算规模，已经在接近甚至超出传统数据库的能力，要求具备更强大的实时计算能力的数据仓库系统，是未来信息化的共同的呼声。

为何最终选择Greenplum呢？其实是因为Greenplum通过开源在未来将会有更大的发展，而且未来也将会更大的需求量。中小企业将会花费更大的精力进去，所以希望使用的数据库是看得见摸、得着的，企业不能只去依靠厂商去提供各种各样的服务，所以数据库能看得见摸得着，就是一个巨大的优势。由于需要投入大量的人力和物理成本到数据库的学习和研究中，所以对于企业来讲需要考虑数据库长远使用的问题，而开源将为用户提供对于数据库更好的理解和掌控。所以我们最终选用Greenplum，在未来也希望能和Greenplum的厂商、服务提供商以及开源社区进行广泛而深入的合作。