2.1 项目需求分析

从实时数据仓库项目（以下简称“本项目”）的主要需求入手，分析本项目都需要哪些功能模块，再根据模块具体实现过程中的技术痛点，决定选用何种大数据框架，确定系统流程图，为后期项目架构设计做准备。

2.1.1 实时数据仓库项目产品描述

本项目主要参考离线数据仓库项目的建模思想，并结合实时计算的需求目标进行搭建，是一个由实时流数据构成的数据仓库。

离线数据仓库建模的主要目标有以下4点。

（1）快速查询所需数据，减少数据I/O，提高访问性能。

（2）减少不必要的数据冗余，实现中间计算结果数据复用，降低存储成本和计算成本。

（3）提高数据使用效率，降低新需求的开发周期，改善用户的应用体验。

（4）统一数据统计口径，规范数据质量，对外提供高质量的数据访问平台。

与离线数据仓库相似，本项目预计也将达到如上目标。

离线数据仓库中存储的都是离线的数据，以天为单位进行收集，以主题进行区分。离线数据仓库还会遵照一定的规范要求，降低数据冗余性，同时按照一定的建模理论（如维度建模）进行建模。为了提高数据的使用效率，离线数据仓库还合理地采用分层策略，优秀合理的分层策略能让整个数据体系更易理解和使用。

而实时数据仓库中存储的都是流式数据，数据源源不断地采集到数据仓库中，并由流式数据计算引擎进行不间断计算，将计算结果汇总进数据分析处理引擎中，进行实时可视化展示。虽然本项目与离线数据仓库存储分析的是不同类型的数据，但是也将参照离线数据仓库的建模思想和搭建思路。首先对数据的采集系统进行充分合理的规划，提高数据一致性。对流式数据合理分层，提高数据使用效率，建立维度表和事实表的概念，最终对外提供统一的数据查询展示接口。

本项目要达到以下几个目标。

1.确保时效性

时效性对于实时计算来说是至关重要的，若不能及时地得到计算结果，那么得到的结果也将是毫无意义的。因此，此实时数据仓库项目要达到秒级、毫秒级甚至亚秒级的响应速度，能够快速得到需求的实时计算结果。要做到这一点，整个数据处理流程的设计都应精益求精。

流式数据来源主要有两类：一类是日志数据，包括用户行为生成的日志数据和系统产生的日志数据；另一类是业务数据。对于两类数据都应做到快速及时地采集，并且对采集到的数据合理地分类处理。另外需要特别重视的是流式数据的处理速度，流式计算引擎的选用是关键。

2.确保准确性

无论是离线计算还是实时计算，对于大数据计算来说，计算结果的准确性都是必须要考量的。计算结果的准确性与时效性通常不能同时得到保障，为了数据的准确性，确保数据不丢失，计算过程有较高的容错性，往往会牺牲一定的时效性。而当用户过于追求时效性时，对于准确性就不能完全保障。本实时数据仓库项目对准确性有较高的要求，在进行架构设计和编写计算程序时，应该予以较高的优先级考虑。

3.确保安全性

实时计算与离线计算还有一点不同之处，实时计算一旦开始运行，除非遇到需求更改或者任务优化升级，一般都是7×24小时不间断运行的。因此，在进行实时数据仓库搭建时，要着重考虑系统整体的安全性。对数据合理分层，降低程序耦合性，建立实时监控系统，做到实时报警，减少程序宕机重启时间，降低损失。

实时数据仓库项目的提出，根本原因在于传统的直线型实时计算开发不能满足企业日益增长的实时计算需求，在传统的实时计算过程中涌现出越来越多的问题。本项目的开发在实现基本的实时计算需求之余，还要为后续其他的实时需求开发提供最大的便利，对外提供可视化页面，供数据分析人员使用。

2.1.2 项目流程图

实时数据仓库项目的大致流程如图2-1所示。

本项目主要分为三层：数据接入层、数据开发层和实时应用层。

数据接入层主要负责将需要分析的实时数据源采集到本项目中来。本项目主要分析的数据源有实时产生的用户行为日志数据和业务数据的实时变动数据。用户行为日志数据包含用户在页面上操作产生的实时日志，还包含系统产生的一些报错信息和运行日志。用户行为日志数据一般会存储在日志服务器的磁盘中。业务数据则是用户与系统交互产生的数据，如用户在网站注册会产生一条用户数据；用户购买一件商品会产生一条订单数据。业务数据一般存储在关系型数据库中。

数据接入层的主要挑战在于数据源具有多样性、数据吞吐量较高、对数据采集的实时性要求较高、准确性要求较高。为了应对多样性的数据源，我们采取了多种监控策略并行、数据管道统一的策略。对于不同的数据源，采取不同的数据监控策略，并将监控采集到的数据发送至统一的消息队列系统，供后续的数据开发层订阅消费。测试多种数据监控方案，适应更高的吞吐数据量，充分提高流式数据采集的实时性和准确性。

数据开发层是本项目的重要部分。在数据开发层中，要对采集到消息队列中的实时数据分析计算。在传统的实时开发中，在这部分通常采用“烟囱”式的开发，即只编写一个实时计算程序，从初始数据中计算得到最终的需求结果。这样的开发通常代码逻辑复杂，并且调试维护十分困难。随着时间的推移，系统上维护的实时需求越来越多，会造成非常大的资源浪费。

本项目采用类似离线数据仓库的分层设计，将数据的处理过程沉淀在各层中，提高中间计算结果的复用性。对采集到消息队列中的数据源分析汇总、数据清洗、格式转换，参考数据仓库的建模理论，将数据分别存储至维度数据和明细数据中。再根据数据指标体系，将明细数据和维度数据进一步汇总整合，形成服务数据，也称作宽表数据。服务数据通常存储在可以提供OLAP查询的数据库中，供后续的实时应用层使用。

实时应用层是项目最后对实时计算成果的验收部分。对以上部分中分析计算得到的数据结果提炼展示。这部分主要有实时OLAP分析、实时可视化大屏展示、实时数据接口编写等。这一部分的关键点在于OLAP分析引擎的选用、可视化工具的选用。最终计算结果数据的存储引擎应充分满足用户的读写需求，可视化平台则应对外提供清晰明了且灵活多样的可视化展示方案。

2.1.3 指标体系分析

本项目主要实现的实时计算需求有如下几大主题。

1.流量主题

● 当日各渠道独立访客数。

● 当日各渠道会话总数。

● 当日各渠道会话平均浏览页面数。

● 当日各渠道会话平均停留时长。

● 当日各小时独立访客数。

● 当日各小时页面浏览数。

● 当日各小时新访客数。

● 当日新老访客数。

● 当日新老访客浏览页面数。

● 当日新老访客平均访问页面数。

● 当日搜索关键词频率统计。

2.用户主题

● 当日回流用户数。

● 当日新增用户数。

● 当日活跃用户数。

● 用户行为漏斗分析。

● 当日新增下单人数。

● 当日新增支付人数。

3.商品主题

● 当日各品牌订单金额。

● 当日各品牌退单数。

● 当日各品牌退单人数。

● 当日各分类订单金额。

● 当日各分类退单数。

● 当日各分类退单人数。

● 当日各SPU订单金额。

4.交易主题

● 当日订单总额。

● 当日订单人数。

● 当日退单数。

● 当日退单人数。

● 当日各省份订单数。

● 当日各省份订单金额。

5.优惠券主题

● 当日各优惠券补贴率。

6.活动主题

● 当日各活动补贴率。

以上六大主题的需求从业务实现的层面上来讲，并不复杂，若采用直线型开发模式进行开发的话，也可得到计算结果。但是随着企业业务需求持续增长和丰富，实时计算需求也日益增多，若每个新增需求都采用直线型开发模式的话，将会面临以下问题。

（1）没有统一的元数据管理体系。

（2）上下游数据没有统一的管理体系，数据不存在一致性。

（3）任务没有统一的框架约束，平台很难跟踪数据流走向。

（4）对于任务的种类不能明晰划分，监控管理十分复杂。

为了解决以上问题，需要将实时计算需求按主题进行分类，计算过程合理分层。将主要需求分为流量、用户、商品、交易、优惠券和活动六大主题，围绕六大主题组织主题宽表，为后续可视化大屏提供服务。