接下来我们来回顾一下微博上实时数据仓库的构建过程。实时数据仓库需要端到端数据的低延迟、标准的SQL支持和对数据变化的快速响应。要做好一个高可用的实时数据仓库，必须做到以下几点：通用实时数据计算平台、实时交互数据分析查询平台。只有当它们相互合作时，它们才能易于开发和维护，并提供高效的数据分析和查询能力。

00-101010

一 实时数据仓库需求场景概要

热门微博推荐和实时热搜榜要求实时了解用户兴趣爱好，实时向用户推荐相关内容，增加用户在微博的粘性。

1.1 微博APP端用户

实时微博生成系统必须健壮，保证系统长期稳定运行，能够实时检测系统的健康状况。

00-1010可以实时掌握用户动态，提升商业营销效果，根据各个维度实时分析营收情况和用户投诉行为。

1.2 实时生产系统

微博是一个拥有约2.5亿DAU的社交平台，必须能够实时识别风险、反欺诈和异常交易。

00-1010

1.3 运营层面

目前成熟的实时计算技术无非是SparkStreaming和Flink，要根据不同公司的不同业务场景进行选择。SparkStreaming定位为微批量，在数据处理上有一定的延迟。Flink是一个实时处理框架，近年来越来越成熟。就像Spark取代MapReduce一样，Flink未来可能会取代SparkStreaming。但是根据微博业务的特殊场景，从SparkStreaming迁移到Flink需要一定的时间，一些老的业务场景还是由SparkStreaming来处理。因此，我们选择Flink SparkStreaming作为实时计算技术。

1.4 风控

二 实时技术选型和架构设计

最早是由《风暴》的作者内森马克斯提出的。这种架构比较复杂：采用双向架构，相互独立。

Lambda架构

由于实时需求场景不多，目前离线计算任务仍是主要任务，Lambda架构仍是经典架构。Lambda架构相当于在离线数据计算的基础上增加了一套实时计算框架，并且双向生产。

Lambda架构的双向计算模式必然会导致两边写代码的逻辑集合相同(离线实时)，同时也会增加后期维护的成本。两个进程的运行时间不一致，但运行数据完全相同。重新运行离线分析数据，数据的更新成本很高，更严重的是两个数据的数据可能不一致(比如离线数据比数据生成延迟的实时数据更准确)。

为了解决Lambda架构的痛点，创造了Kappa架构。相信大家对这个架构都非常熟悉。

2.1 实时计算技术选型

卡帕建筑

Kappa架构设计相对简单，一套逻辑处理离线和实时数据计算。然而，在生产环境中有很大的局限性。例如，Kappa架构严重依赖消息队列。我们知道，消息队列本身的准确性严格取决于其上游数据的顺序。然而，消息队列越多，无序的可能性就越大。通常ODS层的数据是绝对准确的。经过计算，当ODS层的数据写入DWD层时，就会出问题，DWD到DWS更容易出问题，这是一个非常大的数据不一致的问题。

因此，卡帕建筑正在实际生产中

环境中落地的并不多，因此，权衡了各种利弊，还是选择了Lambda架构来处理问题，毕竟实时的场景并不多见。

2.3 数据特点和应用场景介绍

数据特点和业务场景介绍

数据源

日志类：数据量比较大，可能是json等半结构化数据。日志流的数据量通常比较大，数据结构一旦确定以后格式一般不会改变，可以通过埋点的方式收集日志。这种日志类型的数据一般用于生产数据监控和用户行为分析，时效性要求都比较高，通常会按照5-10分钟的间隔统计数据，主要用来做实时数据推荐和实时看板大屏等。业务类：主要是交易类和广告消耗类的数据，以Binlog日志的形式向下下发，业务系统都是事务型的，主要都是结构化数据，但是业务相对复杂，需要关联的表比较多。

业务类和日志类的场景一般是同时存在，会结合在一起做数据分析。

三 实时数仓架构设计

3.1 实时架构

如上图所示，统一采集日志和binlog数据到消息队列（Kafka）中，对于日志类的数据可以通过Flink进行计算然后写入DorisDB，而对于Binlog日志可以直接借助DorisDB来做OLAP分析，以及在DorisDB里面做ETL工作。

那么实时的OLAP分析怎么做呢，我们选择了自带存储和计算功能DorisDB引擎，当然目前有很多可以选择MPP架构提供OLAP分析的数据库，比如TiDB、Druid、ClickHouse等，基于微博的业务特点，我们最后选择了DorisDB。

3.2 实时数据仓库架构设计

实时数据仓库设计方案

从数据仓库建设的方法论来看，实时和离线数据仓库的建设步骤比较相似，在做实时数据仓库时我们首先考虑的也是做数据分层：

3.2.1 数据源

在数据源这个层面，离线和实时数据仓库都是一样的，都分成日志类和业务类，日志主要是微博的行为日志、点击日志和服务器日志。

3.2.2 多维分析事实表

这一层主要进行统一建设，避免重复性建设问题，建立统一的基础明细数据层，可以按照主题进行划分，因此需要对底层ODS表进行过滤、规范化、清洗、扩维等操作。以供下游数据直接使用。

3.2.3 汇总层

汇总层数据主要是通过Flink或者SparkStreaming进行统一计算，所有的指标都集中在汇总层实现，形成完全可以复用的结果表数据。

四 实时数据平台建设

实时数据平台建设

首先需要对功能进行抽象，尽量把功能做成组件化，以实现标准化生产。对于基础层加工的清洗、过滤、合流、扩维、转换、加密等都可以做成功能性组件来实现。通过基础加工之后，可以将全部规范化后的数据写入Kafka中，同时也可以写入到经过实时数据分析的OLAP引擎（DorisDB）中，再往上就是实时汇总计算，基于SparkStreaming、Flink和DorisDB，生成多维汇总指标，形成统一的汇总层数据。除了这些功能之外，还要建设实时数据仓库的辅助系统，例如：元数据管理，指标管理，数据血缘管理和数据质量管理等。

五 未来规划

实时数据仓库建设还有很多痛点，后续我们将逐步采用数据湖技术进行逐步替换。

痛点