1

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
clipboard.png

实施步骤

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

为什么需要热数据仓库?

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

imiskolee
495 声望55 粉丝