数据仓库理论与实践

数据仓库理论与实践（用户画像）

---

---

Java、大数据开发学习要点（持续更新中…）

---

一、数仓理论

1.1 数据库和数据仓库的区别

• 数据库和数据库软件：
    数据库软件是一种物理概念，用于实现数据库。数据库是一种逻辑概念，用于存放数据，数据库由各种表组成，表则能表达数据的二维关系，而数据库的表能用二维表现多维关系。
• 数据仓库：
    数据仓库从逻辑上讲与数据库没有什么差别，功能都是用于存放数据。但从数据用途和数据量上来讲，数据仓库区别于数据库是面向数据分析和数据挖掘的，即用于BI(商业智能)的。数仓面向主题、集成数据、数据时间相对稳定、反映数据历史变化。
• 两者的具体差别：

• 数据库是面向事务，存储数据是日常业务相关的，用于联机事务处理(OLTP)。数据主要针对业务的联机数据操作，主要涉及增删改查。主要关注操作的响应时间、数据并发安全和数据完整性等问题。主要用于操作型处理。(建模一般符合三范式，利于数据增删改查)
• 数据仓库是面向主题，存储数据来源于日志与数据库，用于联机分析处理(OLAP)，主要用于各个业务主题历史与实时的数据分析。主要用于决策管理。(建模一般通过维度建模，利于数据查询)

1.2 数据建模理论

• 三范式建模(业务系统数据库建模)：

  1. 第一范式：表中的每一列都不可分割。
  2. 第二范式：在第一范式基础上，非主键必须依赖主键。（消除非主属性对主码的部分函数依赖）
  3. 第三范式：在第二范式基础上，任何的非主属性不依赖于其他非主属性。（消除非主属性间传递函数依赖）

  实际就是将业务表尽可能拆分使得对表格增删的操作对其他表格不会造成影响

• 维度建模（数仓建模）：根据表的类型分为事实表和维度表。

  1. 事实表就是记录事实、度量、维表主键的表(什么人做了什么事情的的记录，如下单、退款、评价等)；
  2. 维度表就是对事物观察的角度(比如购买是在什么时间点在哪买了什么商品)，即对同一个指标的统计可以从不同的维度统计，维度表就记录了不同的维度信息。

  维度组合中的维度越多，统计出来的事实指标粒度越细。
  维表能为事实表(一般很大)的存储节省很多空间。

• 数据仓库使用的数据模型主要为星型模型、雪花模型和星座模型。

  1. 星型模型：以事实表为中心，为事实表的维度建立维表。这样做的好处在于主要数据都存在事实表中，可读性好；核心数据都在事实表中，扫描事实表就能完成大多数查询。其次，维表一般都较小，在join的时候能缓存提升效率。但维表冗余度大。
  2. 雪花模型：以数据库三范式的规则，将维表进一步规范化，使维表进一步分解到附加表中。这样的模型好处在于符合数据库范式建模数据冗余小，但存在问题是查询时可能需要多次的join，效率较低，且规范化的表维护较为复杂。
  3. 星座模型：多个事实表共享多个维表。整个数仓宏观上就是一个星座模型。

1.3 维度建模的步骤

1. 确认主题：主题要突出某一方面的维度和度量间的关系。
2. 确定度量：主题确定后，需要确定需要统计的指标。
3. 确定粒度：确定度量后，需要确定度量在不同维度下的聚合状态。
4. 确定维度：确定用于分析的各个维度和维度的层次与级别。
5. 确定事实：事实表通过业务或者行为日志建立，关联上各个维表即形成了事实表。

二、数据采集

2.1 通用数据采集框架

1. 流量域
     为了不增加业务负担，用户行为日志的采集都是通过日志采集服务器完成的。日志采集服务器主要是通过Nginx(轻量web服务器/反向代理服务器)实现日志采集的。

• 第一种方式可以通过Nginx收到HTTP请求后直接发送到kafka指定topic中(需要添加额外的moudel整合Nginx和Kafka，优点是速度快，但如果Kafka宕机数据缓存靠Nginx实现，然而实际上Kafka本身就是高可用的，出现故障的概率不大)。
• 第二种方式可以在nginx日志服务器上将日志落盘(由于原生nginx静态服务器且是c语言编写的，所以采用OpenResty编写Lua脚本实现动态的功能)，其中实现的功能是Nginx服务器收到的HTTP请求所带的参数会被解析成json格式存储在指定的日志文件下，再用Flume进行采集(taildir Source,可以记录指定文件夹下所有文件的读取偏移量)，如果要采集到Kafka则直接使用Kafka Channel不用Sink，而如果采集到HDFS等文件系统则需要使用对应的Sink。
  

2. 业务域
     业务数据一般都是存储在MySQL集群中的。为了减少对业务系统的侵入性，需要将业务数据采集到数仓中进行分析。在离线数据处理中，需要使用Sqoop、DataX等工具将数据导入到Hive中；在实时数据处理中，需要使用Canal等工具将数据导入到Kafka中。

2.2 日志服务器日志采集工具(Flume)

  用于离线处理的数据可以在日志服务器上落盘用Flume采集到HDFS中。也可以同实时数据一样都先发送到Kafka的对应的topic中，甚至可以先通过Flink进行ETL后再写入HDFS。

• Flume简介：
    首先，需要了解Flume是什么。主要要知道Flume的三大组件Source、Channel、Sink。这里的设计是用Channel对Source和Sink进行解耦合，同时可以通过Channel余量调节Source数据获取速率来达到削峰的作用。Flume的数据在Source中会封装成Event进行传输(Event由Header和Body组成，Header中可用kv存储控制或自定义信息,但Event是将数据包装成对象可能存在数据缺失)。
  Flume是支持事务机制的，事务按照设定的Event batch大小按批次进行数据传输控制，过程如下图所示：
  
  事务机制下，选择某些例如Source(taildir)和Channel(filechannel)的组合能实现Flume的消息投递是At-Least-Once策略。

三、Hive离线数仓实践

  数据采集部分日志数据使用Flume从日志服务器采集至HDFS，业务数据通过Sqoop按数据特征增量或全量抽取到数仓后，在数仓中根据需求分层计算存储成表。

3.1 数仓分层与意义

  数仓中的表一般都是分层管理、分层计算的。具体来数，是根据大量数据表按照一定的规则和定义在逻辑上的划分。这样做的好处在于使得数据管理更加明晰，运算复用度高，解耦底层数据变化等。常见的数仓分层为ODS、DWD、DWS和ADS：

• ODS：贴源层，将原始日志数据进行简单处理以数据表形式直接进行存储。
• DWD：数仓明细层，主要进行ETL并进行维度关联形成一些不同主题的宽表，为计算提供便利。
• DWS：数仓服务层，根据后续报表的需求进行一些维度的轻度聚合。
• ADS：数仓应用层，存储最终的一些结果报表。

3.2 ODS层

• 流量域
    ODS层主要对原始数据(一般日志文件都是以JSON形式存储)通过JSON解析，导入Hive外部表中(因为可能这个原始数据是被多个部门使用分析的，所以对原始数据应当是外部表形式存储，中间的计算结果以内部表的形式存储)按天进行分区，同时外部包解析JSON数据。日志主要收集的数据对于整个数仓来说是一天的增量信息。

• 业务域
    由DataX等工具将业务库当日的数据拉取到ODS层，其中事实表、实体表数据由于一般较大使用增量导入，而一些小的维表则全量导入。

3.3 DWD层

• 流量域
    DWD层主要完成ODS层数据ETL和维度集成工作(Spark作为工具)。主要工作为无效数据过滤、数据格式规范化、必要维度集成等。该层存储的是维度退化的事实表(宽表，事实表并非严格按照维度建模理论存储维度主键)，比如像时间地域维度基本不会发生变化直接在事实表中存储，而缓慢变化的维度通过存储维度主键在主题分析计算时临时关联维表。

• 业务域
    将增量数据与昨日的全量数据合并(union all并根据开窗对id分组取修改日期的最大那条数据)，生成当日的全量数据。从ODS层的增量合并昨日的全量表得到的次日全量表虽然可以保存每天的全量信息，而有些数据实际上长时间都保持相同的状态，存储量大冗余度高。优化方案为形成拉链表来整合一些缓慢变化维。

3.3 DWS层

• 流量域
    在数仓服务层中，可以根据不同主题和最终需求来提供支持服务，比如轻度聚合，所以建模较为灵活。比如会话聚合表(支撑ADS中的各维度PV、UV统计)、用户活跃区间表(可支撑用户画像最近7天登陆、30天登陆、连续登陆等标签)。

• 业务域
    根据维度建模的思想，按照各种主题将核心事实表关联需要的维表得到对应的主题宽表。在此基础上聚合得到例如用户消费统计画像表、用户拒退画像表、用户购物偏好画像表等用户画像支撑表。

3.4 ADS层

  即为业务需求的最终报表或者支撑其他系统的表。

四、用户画像系统

  用户画像实际是为所有用户根据其行为日志和业务数据库中的数据，进行统计计算、模型计算或决策得到的标签的表集合。用户画像会为每个用户根据不同的主题来计算存储用户的各个主题标签，画像的标签主要在数仓的DWS层完成。
  比如，用户画像的统计标签如用户基本属性标签(通过业务系统中用户信息表直接获取)、用户连续登陆标签、一周(月)内登陆标签(通过流量域DWS层中的用户活跃区间表聚合得到)、用户消费(拒退、偏好)标签(通过业务域DWS层中的用户消费统计、拒退、偏好表直接或聚合得到)；画像的模型标签则可通过算法模型来进行分类或回归；决策模型则由决策层根据数据的范围和阈值制定，并为每个用户打上对应标签(肉食爱好者、运动狂魔等)。由此根据不同主题，每个主题都存有所用用户的对应画像标签，这样的标签表的集合就构成了用户画像。
  然而，计算完成标签仅仅是用户画像系统的一部分，用户画像完成的统计需要对外部系统提供查询服务。所以计算完成的表不能仅仅存放在HDFS上，需要导入对应的业务数据库中对外提供查询的入口。常见的用户画像表可以存放在HBase、Hive，用户画像的查询有这样的特点，根据用户id精准匹配其中某些列的等值查询，或者根据某些列的等值匹配查询符合的用户id(比较符合列式存储数据库的查询)；放在Hive则通过OLAP引擎进行聚合分析(通过ClickHouse分析则需要先将数据导入CK)。
  以HBase存储画像标签表为例，Hive中的表可以通过HBase的BluckLoader进行导入，MapReduce直接将Hive表转换成对应HFile文件用离线数据导入的方式将数据放入HBase存储目录下，有效减少大量数据写入对HBase性能的影响。Hbase的每个主题的用户画像表建立HBase的一个列簇。

五、Hive优化相关

    见Hive原理与优化