如何选择合适的数据库

如何选择数据库

一般来讲，数据分析的查询不会直接从生产环境的数据库来读取数据，一方面是影响线上性能，另一方面是OLTP的表结构设计更多的是面向插入，而不是读取。如何来选择合适的数据库做数据分析呢？本文给出了四方面的考量，抛砖引玉。

1. 客户要分析什么样的数据

2. 客户分析的数据量是多少

3. 客户工程师团队技术背景，运维能力

4. 预期的数据分析的响应时间

客户要分析什么样的数据

上文已简单介绍了关系型数据库和非关系型数据库的区别，这里就不再赘述。下图是一个简单的分类。

客户分析的数据量是多少

用户需要分析的数据量越大，就越应该考虑非关系型数据库。

上图给出了选择合适数据库的思路。不同的数据库处理数据的能力不同。如果你打算处理1T以下的数据，那么可以使用Postgres或者MySQL，但如果数据量增大到5T以上，需要在扩展性方面下些功夫。当然，各个数据库厂商也在不断的优化性能，像微策略这样的BI平台也在紧跟各个厂商的步伐，对各个数据库的特性进行深入的研究，把数据库新特性运用到BI产品中，给客户深入分析各个数据库的优势劣势， 确保为客户提供最大的投入产出比。

客户工程师团队技术背景，运维能力

客户需要了解自己技术团队的人员结构、技术偏好。如果有强大的技术团队，关系型和非关系型数据库都可选择。一般来讲，非关系型数据库需要更多管理维护的时间。如果没有足够的运维人员，可以选择像Postgres, Google SQL (a hosted MySQL option) 或者 Segment Warehouses (a hosted Redshift) 这样的数据库，要优于Redshift, Aurora or BigQuery等。如果运维人员充足，可以选择Redshift等，为以后强大的扩展性做好准备。从另一个角度来说，分析半结构化数据是也是比较普遍的需求。这样就对数据科学家的技能提出了更大的挑战。面向对象的编程背景，精通Python/R 等语言也是对客户工程师团队的重要考量。

预期的数据分析的响应时间

比如像欺诈检测、系统监控等实时数据分析需要的数据分析相应时间有严格的要求。其他的数据分析比如像电子商务网站的用户留存分析等，并没有实时响应的严格要求。客户需要结合自己的用户场景，来选择合适的数据仓库。如果绝大部分的分析是基于已有的数据，对数据的实时性没有特别高的要求，建议用户选择像Redshift or BigQuery这样的数据库，对数据的读取和合并做了大量的优化。如果客户对实时性要求非常高，可以考虑非结构化的数据库方向和内存数据库方向。

当然，选择用什么样的数据库做数据仓储，只是第一步。以实时分析为例，需要从数据仓库，数据湖，计算引擎等架构方面做出通盘的考虑。

1、首先你得搞清楚建设数仓的目的是什么

是偏向于整合各系统数据，为数据分析决策服务，还是偏向于快速的完成分析决策需求？

如果是前者，那么在数据仓库建模的时候一般会选择ER建模方法；

如果是后者，一般会选择维度建模方法。

ER建模：即实体关系建模，由数据仓库之父BIll Inmon提出，核心思想是从全企业的高度去设计三范式模型，用实体关系描述企业服务。主张的是自上而下的架构，将不同的OLTP数据集中到面向主题的数据仓库中。

维度建模：由Kimball提出，核心思想是从分析决策的需求出发构建模型。这种模型由事实表和维表组成，即星型模型和雪花模型。Kimball倡导自下而上的架构，可以针对独立部门建立数据集市，再递增的构建，汇总成数据仓库。

2、其次你得进行深入的业务调研和数据调研

业务调研：深入的业务调研能使你更加明确数仓建设的目的；同时也利于后续的建模设计，随着调研的开展，如何将实体业务抽象为数仓模型会更加明朗。

数据调研：各部门或各科室的数据现状了解，包括数据分类、数据存储方式、数据量、具体的数据内容等等。这对后续的主数据串联或者维度一致性处理等等都是必须的基础。

3、然后是数据仓库工具选型

传统型数据仓库：一般会选择第三方厂家的数据库和配套ETL工具。因为有第三方支持，相对有保障；但缺点也很明显，受约束以及成本较高。

NoSQL型数据仓库：一般是基于hadoop生态的数据仓库。hadoop生态已经非常强大，可以找到各种开源组件去支持数据仓库。缺点是需要招聘专门人士去摸索，并且相对会存在一些未知隐患。

4、最后是设计与实施

设计：包括数据架构中的数据层次划分以及具体的模型设计；也包括程序架构中的数据质量管理、元数据管理、调度管理等；

实施：规范化的项目管理实施，但同时也需记住一点，数据仓库不是一个项目，它是一个过程。

---