Doit数据运营系统（2）数仓开发

数仓涉及

整体选型：

技术选型

数据采集：FLUME
存储平台：HDFS
基础设施：HIVE
运算引擎：SPARK SQL
资源调度：YARN
任务调度：AZKABAN
元数据管理：ATLAS

数仓分层

参考：https://www.cnblogs.com/itboys/p/10592871.html

数据仓库各层说明：

一、数据加载层：ETL（Extract-Transform-Load）
二、数据运营层：ODS（Operational Data Store）
三、数据仓库层：DW（Data Warehouse）

1. 数据明细层：DWD（Data Warehouse Detail）
2. 数据中间层：DWM（Data WareHouse Middle）
3. 数据服务层：DWS（Data WareHouse Service）
   四、数据应用层：APP（Application）
   五、维表层：DIM（Dimension）

分层好处：
清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解

减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算

统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径

复杂问题简单化：将复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。当数据出现问题之后，不用修复所有的数据，只需要从有问题的步骤开始修复。

屏蔽原始数据的异常：不必改一次业务就需要重新接入数据。

我们将数据模型分为三层：

数据运营层（ ODS ）：

存放的是接入的原始数据，数据源中的数据经过ETL之后装入本层。

数据仓库层（DW）：存放我们要重点设计的数据仓库中间层数据

dw层又细分为 DWD（Data Warehouse Detail）层、DWM（Data WareHouse Middle）层和DWS（Data WareHouse Servce）层。

数据应用层（APP）：面向业务定制的应用数据

主要是提供给数据产品和数据分析使用的数据

维表层（Dimension）了解

DIM层：存储维表

各层示例应用说明：

不同的层次中会用到什么计算引擎和存储系统

数据层的存储一般如下：

Data Source：数据源一般是业务库和埋点，当然也会有第三方购买数据等多种数据来源方式。业务库的存储一般是Mysql 和 PostgreSql。

ODS 层：ODS 的数据量一般非常大，所以大多数公司会选择存在HDFS上，即Hive或者Hbase，Hive居多。

DW 层：一般和 ODS 的存储一致，但是为了满足更多的需求，也会有存放在 PG 和 ES 中的情况。

APP 层：应用层的数据，一般都要求比较快的响应速度，因此一般是放在 Mysql、PG、Redis中。

计算引擎的话，可以简单参考图中所列就行。目前大数据相关的技术更新迭代比较快，本节所列仅为简单参考。

参考:https://blog.csdn.net/hello_java_lcl/article/details/107025192

模型设计

ODS层：与原始数据完全保持一致

操作数据层，相对来说，存储周期较短；视数据规模，增长速度，以及业务的需求而定；对于埋点日志数据ODS层存储，通常可以选择3个月或者半年；存1年确有需求。

数据规模
假如：公司用户规模1000万
平均日活400万
平均每个用户访问1.2次
每个用户平均每次访问时长10分钟
按经验，每个用户平均每 5~10 秒产生一条事件

则每次访问，将产生10分钟60秒/10 = 60条事件日志
则，每天产生的日志总条数： 400万1.2*60条 = 28800 *万=2.88亿条日志

每条日志大小平均为0.5k，则每日增量日志大小为：
28800万0.5k = 288005M= 144G
每月累积增量为：144G*30 = 4.3T
假如要存储1年的数据量，则1年的累计存储量为：51.6T
考虑，增长趋势： 预估每月增长20%
则1年的累计存储量为：接近100T
注：在这里也可以估算实时流式计算中的数据量，假如最高峰值时，每秒同时在线人数有10万，则在此峰值期间，每秒将有50万条日志产生

数据采集
采集源：KAFKA
TOPIC：app_log, wx_log,web_log
采集工具：FLUME

元数据的存储：

创建外部表
由于原始数据是普通文本文件，而文件内容是json格式的一条一条记录，在创建hive表结构进行映射时，2.将数据按json格式进行映射（这需要外部工具包JsonSerde 的支持）

数据导入

DWD层：

不完全星型模型
事实表+维度表

DWD层详细设计

DWD层的数据来自ods层的表，ods.app_event_log----------------------------------->dwd.app_event_detail

技术选型：
由于本层数据ETL的需求较为复杂，用hive sql实现非常困难，因而此环节将开发spark程序来实现

数据处理需求分析：
清洗过滤 去除废弃字段、格式不正确的、空记录、缺少关键字段、过滤爬虫请求数据等

数据解析 将json打平，解析成扁平格式

SESSION分割

数据规范处理

维度集成 将日志中的GPS经纬度坐标解析成省、市、县（区）信息；将日志中的IP地址解析
成省、市、县（区）信息；将日志中的时间戳，解析出年、季度、月、日、年第几
周、月第几周、年第几天

ID_MAPPING 为每一个用户生成一个全局唯一标识

新老访客标记 新访客，标记为1 老访客，标记为0

保存结果 将数据输出为parquet格式，压缩编码用snappy，parquet相比于orc兼容性更好

关键设计

gps坐标数据形如： (130.89892350983459, 38.239879283598)
怎样才能解析为地理位置： 河北省，石家庄市，裕华区

GEOHASH编码介绍
Geohash编码是一种地理位置编码技术，它可以将一个gps坐标（含经纬度）点，转化为一个字符串；
wx3y569
wx3y434
通过编码后得到的字符串，表达的是：包含被编码gps坐标点的一个矩形范围；

GEOHASH编码原理
在地球经纬度范围内，不断通过二分来划分矩形范围，通过观察gps坐标点所落的范围，来反复生成0/1二进制码。

在满足精度要求后，将所得的二进制编码通过base32编码技术转成字符串码，如下所示：

GEOHASH码的精度
字符串长度越长，表达的精度越高，矩形范围越小，越逼近原gps坐标点；
相反，长度越短，表达的精度越低，矩形范围越大；
geohash码的精确度对应表格：

还可以用高德地图开放API

IP地址地理位置解析
IP地理位置处理工具包，开源工具包ip2region（含ip数据库）

难点 ID_Mapping

timestamp解析

DWS层：

主题建模和维度建模