2.2 项目架构概述
2.2.1 架构设计
项目的总体架构如图2-2所示。
在整个大数据系统中，业务数据和用户行为日志数据（图上简称为日志数据）是我们需要分析的主要数据源。业务数据存放在关系型数据库中，如MySQL，用户的业务操作会导致其中的数据修改变动，这些变动数据被采集发送至消息队列的一个主题 topic 中。一部分业务数据还会被每日全量同步至分布式存储系统（如Hadoop的HDFS）中去。至于哪部分数据需要被增量同步，哪部分数据需要被全量同步，则涉及数据同步策略的制定，这部分内容将在第5章中讲解。
图2-2 项目总体架构图
用户行为日志数据通常首先会落盘在日志服务器中，然后由日志采集工具将数据实时采集发送至消息队列的一个主题topic中。
被发送至消息队列的业务数据和用户行为数据，一方面由日志消费工具（如Flume）将其消费存储至分布式存储系统中去，另一方面则由实时计算引擎消费计算。被存储至分布式存储系统中的数据，将会通过离线计算工具（如Hive、Spark等）进行分层建设，搭建分层的离线数据仓库。最终结果数据会被导出至关系型数据库中，使用可视化工具进行大屏展示。这一部分就是大数据系统的离线部分。
在实时部分中，Kafka 中存储的用户行为数据和业务数据就是需要分析计算的原始数据。原始数据经过实时计算引擎（如Flink）的清洗、转换、分流，明细数据继续发送至消息队列中，维度数据存储至HBase中，方便关联使用。明细数据和维度数据经过实时计算引擎的汇总计算，形成服务数据最终存储至OLAP分析引擎中。
存储至OLAP分析引擎的服务数据，可以对外提供多种实时分析服务，如实时查询分析、实时可视化大屏展示、实时数据产品等。在本项目中，通过编写实时数据接口，对接可视化工具，对外提供实时可视化大屏展示。
从以上的分析中我们可以知道，实时计算和离线计算是不能完全划分开的。
2.2.2 分层设计
本项目要参考离线数据仓库的构建思想，对实时计算也采用分层设计。那么为什么要设计数据分层？这是在设计数据分层之前首先应该回答的问题。
我们作为数据的管理者和使用者，肯定是希望数据的计算能够有秩序地运转，能够清楚地了解数据的生命周期。要想达到以上目标，就必须设计一套合理高效的数据组织方案，也就是数据分层。数据的分层可以给开发者带来以下好处：
（1）使数据结构更加清晰。分层之后数据作用职责更加明晰，方便数据定位和理解。
（2）减少重复开发。合理分层后，提高中间层数据复用性，减少数据重复计算。
（3）统一数据口径。通过数据分层，对外提供统一的数据出口。
（4）简化需求开发。将复杂需求通过分层分解成多个步骤来完成，需求实现更加简洁清晰，有章可循。通过对常用实时需求的分析，将数据分为如图2-3所示的五层，详细描述如下。
图2-3 数据分层示意图
● ODS层：原始数据层，存放的是原始数据，主要存储在Kafka中，包括用户行为日志数据和业务数据。用户行为日志数据保持原样采集，在采集过程中清洗其中的脏数据，业务数据的采集主要对数据进行规范化清洗。
● DWD层：明细数据层，以数据对象为单位进行分流，如订单、页面访问等。ODS层的用户行为日志数据主要分为3类：页面日志、启动日志和曝光日志。这三类数据虽然都是用户行为数据，但是有着完全不一样的数据结构，所以要拆分处理。将拆分后的不同日志写回Kafka的不同主题中，作为日志的DWD层。业务数据的变化通过变动数据监控数据采集到之后，统一写到ODS层的一个Kafka主题中，这些数据包含事实数据和维度数据。多种数据共存不利于后续数据处理，本层主要将数据进行鉴别分流，将事实数据写入Kafka的DWD层。
● DIM层：维度数据层，用于存储维度数据，如用户维度、地区维度等。
● DWS层：服务数据层，根据某个维度主题将多个实时数据轻度聚合，形成主题宽表，减少维度查询的次数。
● ADS层：数据应用层，把DWS层中的数据根据可视化需求进行筛选聚合。