数据仓库的建设演进方案介绍

现如今对于互联网公司来说，数据的积累越来越多，同时我们也需要最大化的挖掘数据的价值，因此在各个公司都会有数据仓库的建设。这篇文章浅谈下各业务公司在各个阶段对于数仓建设的演进和适配方案。

本文仅谈谈相关的数据仓库的建设方案，及每个方案的优缺点，同时介绍下适配场景。具体情况可以根据各公司实际情况进行建设。

一、团队规模小、数据量较小阶段，建设数据仓库1.0方案

在这个阶段，一般公司的数据量较小，业务量也较少，所以一般的场景需要主要是报表的统计展示阶段，因此基于这个阶段的话，我们可以建设一个小型的数据仓库，这个方案可以简化为下图所示：

这个方案就比较简单，因为业务比较单出，主要是相关的一些查询和BI报表的统计分析等，此时我们由于数据量小，在业务端，可能各个数据结构都是按照传统的RDBMS的方式进行设计的，那么在业务查询和BI统计的时候，我们主要是把数据进行冗余，利用nosql的优势（即mongodb或者elasticsearch）进行相关的统计查询，这时候在IT建设上主要的目标有两个，分别是：

1、把业务数据冗余起来，同时精简各条业务的数据量
2、利用nosql的列存储优势，尽可能快的查询统计出相关的数据

备注：

1、这个方案比较适合业务量比较少的场景

2、这个方案比较适合研发团队人员少的场景

二、数据量逐步增长，需要查询统计的维度增多，维度变化等较大，建设数据仓库2.0方案

一般如果公司要采取这种方案的话，那么相对来说数据的增长率是非常快的，同时各条业务线也较多，对于BI分析和业务查询相关的需求越来越多。所以这个阶段一般对于研发团队来说都会有一个专门的大数据研发团队，这个大数据研发团队的人数至少在3个人以上，也就是这个大数据研发团队的人主要是做数据仓库的建设。此时的建设方案2.0如下图：

这种模式的话，其实主要是利用阿里云的数仓平台来进行建设，能同时满足在线和离线数据仓库的建设，能实现从各个数据源采集数据，实现对多数据源的数据维度清洗。最后满足业务查询、即系查询和明细导出、BI展示等，在这个阶段，整体来说离线数仓的部分是大于实时数仓的部分的。

备注：

1、上面估计的至少3个人以上，在大部分同学看来人数非常的少，这里解释一下，主要是基于以下几点考虑：

1）利用成熟的数据仓库产品来进行数据的整合

2）现在很多小的公司比较节省成本

3）这里的时间周期会略长很多

所以这至少3个人以上的团队规模主要是个人的一些看法（确实有很多公司是这样来操作的）,因为利用成熟的数据仓库平台可以解决很多运维的问题，并且在整个数仓使用上，被屏蔽了很多的细节，只需要整合好业务，根据数据仓库平台提供的API进行调用即可。

关于上诉方案的缺点说明一下：

1、响应速度慢

这个方案里面几乎我们所有的数据维度等都需要过一遍清洗、聚合和关联，同时数据也会整合到数据仓库平台里面，但是这块会形成离线数仓部门的头大和Hologres的身小的地步，所以在查询的时候涉及到的延迟比较高。在业务上响应的速度就慢起来了。

2、数据仓库的维度变化较大

我们知道启用离线数仓计算的话，很多维度都是定时去计算一遍，而且这些维度是紧贴业务的维度的，随着业务的发展多样性，维度会越来越多，那么对于维度的更新和维护就会变得非常复杂。在数据更新和删除场景中，需要定期通过过滤和去重来保持数据的一致性，而事实上，大多时候需要报表数据实时关联维度表，这让我们直接放弃了在离线数仓中维系维度表的方案。

3、不支持高并发查询的场景

上诉的方案主要是基于在线+离线的方案，这里的实时数仓在使用上虽然能满足一些性能上的要求，但是总体来说还是会有延迟。那么在大规模的高并发场景里面，这个框架就不是很适合。

三、现在流行的方案，建设数据仓库3.0方案

现在在数仓建设方面，apache的doris越来越收到大家的欢迎，因此基于doris的方案如下图：

doris的使用方面，它完全兼容mysql相关的协议，对于我们来说操作非常简单，并且在使用上，他的查询速度比mysql更快，在非常多复杂的场景里面几乎可以做到秒级返回。此时的话，我们整个数仓的变化就由之前的离线数仓部分的头大和实时数仓部分的身小转换成现在的实时数仓部分的头大和离线数仓部分的身小。也就是更能契合实际的业务场景。

使用doris构建整个数仓的话，我们只需要关注如下几点即可：

1、数据建模

在实际使用上主要使用Unique模型完成业务原始表和维度表的数据接入。使用aggregate模型完成统计类数据的预接入。

2、数据接入

使用 Flink-Doris-Connector 进行实时导入：主要用于业务数据的导入，基于MySQL 的 Binlog 日志写入到 Kafka 后，通过 Flink 解析加工后准实时写入 Doris。

使用 DataX 进行离线导入：主要用于对接离线数仓已计算后的报表数据。

3、数据开发

Doris 主要以提供终端查询为主，复杂的 SQL 开发任务运行比较少，为尽可能减少 Doris 在数据加工方面的资源消耗，当前仅有报表集群在凌晨执行少量的 SQL 任务，主要以 Doris SQL 通过insert into的方式来导入。

4、数据管理

Doris 支持将当前数据以文件的形式通过 Broker 备份到远端存储系统中，后可以通过恢复命令从远端存储系统中将数据恢复到任意 Doris 集群。通过该功能，Doris 可支持定期对数据进行快照备份，也可以通过该功能在不同集群间进行数据迁移。

5、监控报警

使用官网推荐的 Prometheus 和 Grafana 进行监控项的采集和展示，Doris 本身提供了丰富的监控指标和标准监控模版，可以非常便捷地对 Doris 集群使用情况进行监控和报警。

最后的过如下：

1、Doris 完美覆盖了原本需要多个技术栈才能实现的业务场景，极大地简化了大数据的架构体系。

2、Doris 对 Join 支持较好，因此我们选择了将维度表放到 Doris 中进行维护，相较于之前在离线数仓中进行维护，明显地提高了开发的效率，并降低了数据出错的可能性，满足了业务上对维度表近实时更新的需求。

3、Doris 支持 MySQL 协议和标准 SQL，开发人员学习成本低，上手简单，可以快速将原先的业务迁移至 Doris 上来。

4、Doris 社区活跃，版本迭代速度快。在遇到任何问题时，都可以向社区求助，SelectDB 为 Apache Doris 组建了一支全职专业的技术支持团队，24H 内即可得到社区的响应回复。