存储工具（四）数据仓湖

系列文章

• 存储工具（一）序
• 存储工具（二）数据库的表与字段
• 存储工具（三）非关系数据库解决了什么问题，又产生了什么问题？
• 存储工具（四）数据仓湖

背景

在关系数据库发展到后来，我们引入了非关系型数据库，来解决开发人员在其高并发、灵活结构、特殊查询能力的一系列不足。
而从数据/产品经理而言，数据不仅是在线上操作，更需要通过历史数据分析/指导今后的企业决策（同时操作和分析的拆解，也缓解了关系型数据库的压力）。
这时候，上一章存储工具（三）非关系数据库解决了什么问题，又产生了什么问题？结尾的三个典型场景应运而生。

1. 需要秒级展示，多维度聚合的千万乃至上亿的数据。
2. 需要对外展示的t+1海量离线数据，且需要支持任意天数的历史数据查询。
3. 若业务里不仅有TABLE（结构化数据），JSON（半结构化数据），还有日志、图片、视频、音频等各种格式的非结构化数据，如何低成本存储，且支持数据分析。

问题一

数据量大、查询维度多、要求秒级出结果‌，推荐将数据从关系型数据库迁移至实时数仓。

其他类型数据库的问题

由于数据量大，无论如何优化关系数据库无法做到秒级响应。同时，关系数据库水平拓展若需要进行复杂的分库分表。

方案

实时数仓按列存储、天然支持分布式和水平扩展。

问题二

若需要对外展示全量数据，T+1的时效可以通过每天从关系数据库或者实时数仓同步到离线数仓，通过离线数仓进行聚合、清洗，分析t+1数据。

其他类型数据库的问题

由于需要展示全量数据，关系数据库在亿级数据下的查询效率过低，而实时数仓成本过大。

方案

离线数仓支持PB级历史数据T+1统计，且成本低廉。

问题三

若不同结构和类型的数据需要低成本存储。且需支持进行数据分析，推荐将数据低成本存储存入数据湖，在用的时候进行全量分析。

其他类型数据库的问题

由于数据仓库都是属于结构化的，不同结构和不同类型的数据无法存储。且成本较高。

方案

数据湖支持不创建Schema‌，天然支持复杂的数据结构和类型。且成本更低。

数据存储的展望

在写这篇文章的时候，所有的存储介质都在尽力补齐自身的短板。
关系型数据库正一步步拓展自己的边界，MySql支持JSON格式,又支持FULLTEXT全文索引；PostgreSQL加了丰富的非结构化能力。关系型数据库开始了非关系化。
而非关系数据库也同理，Redis也开始支持JSON，支持索引查询；MongoDB 支持了多表关联查询。非关系型数据库也逐渐补齐关系。
同时数据仓库和数据湖也不是对立关系，近些年，研究人员提出了湖仓一体的概念。让用户在存储数据时，利用数据湖的低成本存储；分析查询时，采用数据仓库的构建和语法，使用方便。

对我而言，关系型数据库的优点就在于关系，它的缺点也在于关系。由于关系有了很多查询上的便利，但由于关系又丢掉了非关系上的效率。关系是一体两面的。
同时对于开发而言也一样，没有银弹，不存在最好的存储工具，只有适合的存储工具。