Background
对于任何企业服务(SaaS)或者面向大众(To C)的系统,报表是内部运营中最重要的部分。报表内业务通常存在以下几个难题:
- 变更频繁。尤其是SaaS类企业,报表需求是非常的频繁变更单,因此很难将报表需求进行固化,进行针对化的优化。
- SQL复杂。报表通常是直接从源数据库通过SQL的方式加载出来,计算与查询都非常复杂,没办法简单的完全优化。
- 实时性。实时性是报表业务最具有价值的点。实时性表现在数据更新的实时性以及加载报表的实时性。如果加载一个报表需要半小时那自然是极大的消耗耐心的事情。
那么,我们对于报表业务的架构需求就很清晰了:
- 满足数据增长的需求。AWS Redshift与Google Cloud Big Query 都是现代的海量存储分析引擎,我们优先选择它们。
- 尽可能的实时性。 这要求我们在ETL阶段,最好可以使用MySQL Slave的方式进行数据提取。
- 尽可能的灵活机动性。 这要求不能进行任何的预计算。
业务架构
big_query.jpg
实施步骤
- 挑选合适的ETL工具进行从生产环境的transactional database中提取数据。
- ETL将数据写入到数据仓库中(全量数据库仓库,半年热数据仓库集)。
- BI 应用程序或者自己开发的API连接到数据库仓库进行数据读写。
为什么需要热数据仓库?
- 因为从redshift/big query等系统查询数据是秒级响应,做不到毫秒级响应。当我们需要最快速的出面向C端的报表业务的时候,延迟是很重要的。而通常,C端报表的数据时长比较短。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。