Background

对于任何企业服务（SaaS）或者面向大众（To C）的系统，报表是内部运营中最重要的部分。报表内业务通常存在以下几个难题：

1. 变更频繁。尤其是 SaaS 类企业，报表需求是非常的频繁变更单，因此很难将报表需求进行固化，进行针对化的优化。
2. SQL 复杂。报表通常是直接从源数据库通过 SQL 的方式加载出来，计算与查询都非常复杂，没办法简单的完全优化。
3. 实时性。实时性是报表业务最具有价值的点。实时性表现在数据更新的实时性以及加载报表的实时性。如果加载一个报表需要半小时那自然是极大的消耗耐心的事情。

那么，我们对于报表业务的架构需求就很清晰了：

1. 满足数据增长的需求。AWS Redshift 与 Google Cloud Big Query 都是现代的海量存储分析引擎，我们优先选择它们。
2. 尽可能的实时性。这要求我们在 ETL 阶段，最好可以使用 MySQL Slave 的方式进行数据提取。
3. 尽可能的灵活机动性。这要求不能进行任何的预计算。

业务架构

big_query.jpg

实施步骤

1. 挑选合适的 ETL 工具进行从生产环境的 transactional database 中提取数据。
2. ETL 将数据写入到数据仓库中 (全量数据库仓库，半年热数据仓库集)。
3. BI 应用程序或者自己开发的 API 连接到数据库仓库进行数据读写。

为什么需要热数据仓库?

1. 因为从 redshift/big query 等系统查询数据是秒级响应，做不到毫秒级响应。当我们需要最快速的出面向 C 端的报表业务的时候，延迟是很重要的。而通常，C 端报表的数据时长比较短。