标签：需求数据业务背景用户事件 cal dt id string

欢迎加我微信：16730230181，获取更多大数据学习资料

公众号：从零学习Flink

第01章项目背景

1.1学习要求

每日总结当天内容

l 需求是什么

l 解决需求的方案是什么

l 具体实现逻辑是什么

l 开发过程中有遇到哪些问题

1.2项目背景

某APP上线后，由于业务模式新颖，市场需求量大，经过一段时间的精心运营后，逐渐积累起了上千万用户，以及三四百万的日活量，app的业务功能和产品种类、数量也急速膨胀；

随着规模的增长，逐渐凸显出大量的问题：

l营销分析断层：市场营销成本居高不下，投放拉新的效果追踪出现断层，无法追踪各渠道实际转化率，难以准确分析ROI。

l产品迭代无法量化：缺少实时的用户行为分析能力，使得产品功能改版的效果无法量化衡量，核心流程优化点更多靠拍脑袋，bug问题的定位后知后觉造成长时间的损失。

l用户运营不精准：“千人一面”的全量用户营销，投入产出难以把控，不精准的粗犷方式难以真正提升存量用户的长期活跃度。

l全局运营指标监控不实时：有运营的BI 系统，但运营指标监控不及时，未形成核心的指标预警机制，决策滞后。

公司急需告别这种粗放的、严重依赖人力的运营状况，急需建设一套强大的数据运营平台，用于驱动营销渠道效果评估、用户精细化运营改进、产品功能及用户体验优化、老板看板辅助管理决策、产品个性化推荐改造、用户标签体系构建等应用场景

从各方面为公司的进一步发展提供强有力的数据支撑

以上内容，请自己补充阅读；

总之就是强调数据以及数据驱动的重要性

1.3开发总目标

开发一个综合性的数据仓库系统、用户画像系统及OLAP在线数据分析平台

从技术内核来看：

l 以HDFS作为最底层存储

l 以HIVE作为数仓基础设施

l 以SPARK作为核心运算引擎

l 以flume、sqoop、azkaban（任务调度）、atlas（元数据管理）、griffin（数据质量监测系统）等作为外围粘合辅助系统

l 以kylin（麒麟，多维分析型数据库），clickhouse作为olap（联机数据分析）分析引擎

从前端展现来看：

l 报表与数据可视化平台

l 模型分析平台

l 自由灵活分析平台

l 用户画像分析平台

第02章需求概况

2.1 行为域基础（流量）分析

2.1.1 分析主题概览

l整体概况：从产品整体的使用情况出发，对产品整体的使用情况有基础了解。

l用户获取：从获客渠道和版本的方向出发，根据不同渠道、不同的版本生成一些可以了解渠道优劣的指标，可以清晰的观察每个渠道的流量、转化等情况。

l活跃与留存：从用户的访问和粘性出发，可以观察出产品在用户访问、回访等方面的趋势变化，清楚地了解用户对产品的粘性和沉浸程度。

l事件转化：根据选择的事件和属性，生成该事件hj的发生次数、人数、分布等数据指标，可以了解整体的用户转化以及收益相关的数据情况。

l用户特征：根据地址位置、性别、操作系统等一些基础属性，将用户进行分组，方便了解用户的分布占比情况。

2.1.2 整体流量概况

产品整体的使用情况，包括用户量、访问情况、留存等

帮助对产品整体指标有一个大致的了解

l 累计用户量：产品上线至今的累计用户量

l 每日新增用户量

l 每日的全部访问人数、次数

l 每日的全部访问的人均次数/时长/深度

l 新老用户访问占比

l 每日新老用户的分布情况

l 新用户/全部用户的7日留存：起始和后续事件都为用户进行页面访问

l 各页面的访问次数分布：基于pageview事件中的页面标题属性进行分组

l 访问终端（app /pc web /微信小程序 /H5）分布：按照访问的操作系统分组

2.1.3 访问渠道分析

每个渠道的用户的使用情况，包括渠道中新用户的占比、留存等，了解产品在获客层面上的优势与不足；其中App的渠道数据，会根据iOS，Android进行细分

l 新增用户量：全部新用户数量，包括自然流量和渠道流量

l 渠道新增用户量：仅计算渠道流量新增用户数

l 各渠道新用户人均访问时长

l 异常流量：App 异常流量，定义为打开5秒内即进行关闭操作的访问行为

2.1.4 用户分布分析

l 访问省份分布

l 访问城市分布

l 访问性别分布

l 访问操作系统分布

l 新老用户占比

2.1.5 APP版本分析

App 每个版本的使用情况，帮助了解在产品升级的过程中，是否在活跃和留存方面有所改善

l 版本访问流量

l 人均访问时长

l 各版本留存：各版本的用户7日留存

2.1.6 活跃度分析

产品的每日访问数据，指标集中在新老用户的访问行为上，提供访问次数、时长、次数分布、访问时段高峰等指标，帮助了解新老用户在使用产品时的一些行为特征

l 访问用户数

l 新老用户访问占比

l 新老用户人均使用时长

l 新老用户启动/访问次数

l 每日/每周启动时段

l 用户每日访问产品的时段分布

l 用户每周访问产品的星期分布

2.1.7 用户留存分析

提供用户7日，次日，次周，次月留存的数据，帮助了解新老用户的使用粘性

l 7日留存/流失

l 次日留存/流失

l 次周留存/流失

l 次月留存/流失

2.1.8 事件转化分析

各类关键事件（如收藏，分享，转发，加购等），发生次数、人数以及分布情况

l 新老用户事件发生次数/人数/人均次数

l 事件次数的分布

用户自定义收益类事件，神策会自动生成该事件的发生次数、人数以及分布情况，会根据您选择的数值类型属性，计算该数值的总值、人均值以及次均值

l 新老用户收益事件发生次数/人数/人均次数

l 新老用户收益事件

2.2 行为域进阶分析

2.2.1 转化漏斗分析

漏斗模型主要用于分析一个多步骤过程中每一步的转化与流失情况。

举例来说，用户购买商品的完整流程可能包含以下步骤：

1. 浏览商品

2. 将商品添加进购物车

3. 结算购物车中的商品

4. 选择送货地址、支付方式

5. 点击付款

6. 完成付款

可以将如上流程设置为一个漏斗，分析整体的转化情况，以及每一步具体的转化率和转化中位时间。

同时也希望能有强大的筛选和分组功能进行深度分析。

2.2.2 事件留存分析

留存分析是一种用来分析用户参与情况/活跃程度的分析模型，考查进行初始行为后的用户中，有多少人会进行后续行为。

这是衡量产品对用户价值高低的重要指标。

留存分析可以帮助回答以下问题：

l 一个新客户在未来的一段时间内是否完成了期许的行为？如支付订单

l 改进了新注册用户的引导流程后，期待改善用户注册后的参与程度，如何验证？

l 想判断某项产品改动是否奏效，如新增了一个邀请好友的功能，观察是否有人因新增功能而多使用产品几个月？

2.2.3 行为分布分析

分布分析不但可以告诉你用户有多依赖你的产品，还可以告诉你某个事件指标的用户分布情况。比如，查看订单金额在 100 元以下、100 元至 200 元、200 元以上三个区间的用户分布情况。

指定一个用户行为事件，然后选择事件的指标。分布分析可以帮助揭示以下问题：

l 策略调整前后，用户每天使用产品次数是否增加？

l 用户首次购买后是否会重复购买？

l 假设每天使用 3 次以上某关键功能的用户算作核心用户，那么核心用户的成分变化趋势如何？

2.2.4 行为归因分析

业务上需要分析某个广告位、推广位对目标事件的转化贡献时，可以使用归因分析模型进行分析。在归因分析模型中，广告位的点击、推广位的点击被称为「待归因事件」，支付订单等目标类事件被称为「目标转化事件」

l 目标转化事件：

选择产品的目标事件，一般为与收益相关的事件，如：提交订单详情、支付...

支持选择全部的元事件

l 目标转化事件的高级设置：

前向关键事件

选择目标转化事件的前向事件，主要是为了提升归因模型的计算精度。一般选择与目标事件有强关联的事件，类似商品曝光，如：查看商品详情、加入购物车...

关联属性：将目标转化事件和前向关键事件进行关联的属性

l 待归因事件

选择待归因事件，一般为与广告曝光、推荐曝光等运营相关事件，如：点击广告位、点击推荐位...

l 归因模型

n 首次触点模型：多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为第一个「待归因事件」功劳为 100%

n 末次触点归因：多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为最后一个「待归因事件」功劳为 100%

n 线性归因：多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为每个「待归因事件」平均分配此次功劳

n 位置归因：多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为第一个和最后一个「待归因事件」各占 40% 功劳，其余「待归因事件」平分剩余的 20% 功劳

n 时间衰减归因：多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为越靠近「目标转化事件」做出的贡献越大

2.2.5 行为路径分析

用户路径分析主要用于分析用户在使用产品时的路径分布情况。

例如，在访问了某个电商产品首页的用户后，有多大比例的用户进行了搜索，有多大比例的用户访问了分类页，有多大比例的用户直接访问的商品详情页。

2.2.6 行为间隔分析

产品，运营，市场等人员的日常工作都需要观察某某业务的转化情况。如何衡量转化，除了用漏斗看转化率，还需要看转化时长的分布情况，间隔分析即是解决这类问题和需求的。通过计算用户行为序列中两个事件的时间间隔，得到业务转化环节的转化时长分布。

间隔分析可以帮助回答以下问题：

l 包含了实名认证等复杂操作的注册流程，想知道用户从开始注册到注册结束，整个过程花费的时长分布。

l 电商类产品分析用户首次打开 app 或完成注册，到完成首次下单所花费的时长分布。

l 投资理财类产品分析新用户完成绑卡到完成首次投资的时间间隔分布。

间隔分析的分析结果以箱线图的形式展示。箱形图提供了一种只用 5 个点对数据集做简单总结的方式。它能显示出一组数据的最大值、最小值、中位数、及上下四分位数。

可以看到整个时间段 A 事件 → B 事件的总体情况的最大、最小、中位、平均间隔时间；

2.2.7 其他高阶分析

对于使用现有的UI 功能暂时无法满足的高级数据需求，我们提供了更加自由的自定义查询功能。该功能支持使用标准 SQL 来对所有数据进行自由查询，同时也包含对查询结果的简单可视化。

2.3 业务域分析

2.3.1 概述

交易域

营销域

运营活动域

2.3.2 购物车分析

当日/本周/本月日加购总数

当日/本周/本月提交总数

当日/本周/本月取消总数

需要结合时间以外的其他维度进行分析，如品类、人群、时段、地域等

2.3.3 交易金额分析

当日/本周/本月 GMV总额

当日/本周/本月订单支付总额

当日/本周/本月下单人数

当日/本周/本月客单价分析

当日/本周/本月取消订单数

当日/本周/本月取消订单用户数

当日/本周/本月退货次数

当日/本周/本月退货用户数

GMV近30日变化趋势

GMV各端贡献情况（平台类型，GMV，订单量，下单人数，客单价，笔单价）

下单金额分布（1000以下，1000-2000,2000-3000,3000-4000,4000+）

当日/本周/本月商品销售情况（商品名称，品类，店铺，购买次数、人数，销售额）

当日/本周/本月各品类商品销量趋势（品类，日期，购买次数、人数，销售额）

当日/本周/本月各店铺商品销量占比（店铺，购买、购买人数，销售额）

需要结合时间以外的其他维度进行分析，如品类、人群、时段、地域等

2.3.4 复购率分析

当日/本周/本月各端复购率

当日/本周/本月购买频次分析（1次，2-3次，3-4次，4-5次）

订单实时分析

订单量分钟级

订单量小时级

订单用户趋势分析

需要结合时间以外的其他维度进行分析，如品类、人群、时段、地域等

2.3.5 优惠券分析

优惠券抵扣力度（优惠券，日期，抵扣金额）

优惠券使用情况（优惠券，日期，使用次数）

2.3.6 团购分析

团购订单趋势

参团用户趋势

各品类开团数

各品类成团数

2.3.7 秒杀限时购分析

秒杀订阅人数

秒杀成交订单趋势

秒杀支付类型趋势

2.3.8 其他营销活动

国庆大豪礼

金秋大放送

活动地域趋势分析

活动订单趋势分析

2.3.9 广告运营位分析

当日/本周/本月曝光度

当日/本周/本月点击率

当日/本周/本月转化率

2.3.10 拉新注册分析

当日/本周/本月渠道分布

当日/本周/本月转化率

2.3.11 会员分析（用户画像）

当日/本周/本月消费情况

当日/本周/本月充值情况

当日/本周/本月会员等级分布

当日/本周/本月活跃分布

当日/本周/本月退换货分布

当日/本周/本月商品评价分析统计

……

2.4 用户画像分析

1.7.1 基本属性画像

性别

地域

注册时间

手机号

手机类型

收入级别

年龄阶段

1.7.2 行为习惯画像

月登陆次数

月下单次数

月收藏次数

月点赞次数

月分享次数

分享最多品类

浏览最多品类

……

1.7.3 消费习惯画像

月消费金额

周消费金额

月优惠券使用金额

月积分抵扣金额

月消费最多品类

月消费最多品牌

……

1.7.4 其他

流失风险

用户价值

……

2.5 OLAP数据分析平台

主要是搭建一个平台，让使用者自己去分析自己的需求

第03章整体方案设计

3.1 日志埋点（生成）

主要数据类别：

l 用户行为日志数据[需要在业务系统的前端（或后端）中做埋点]

l 业务数据[已经在业务系统的数据库中]

l 历史数据

l 其他第三方数据

3.2 数据采集汇聚

l行为域数据

1，日志前端埋点，生成日志数据

2，日志服务器存储为日志文件

3，Flume采集日志文件，写入hdfs

5，日志预处理

6，落hive数仓ODS层

l业务域数据

1，业务系统增删改数据库，形成业务数据

2，Sqoop/DataX/ Kettle数据抽取

注：Kettle是一些传统企业比较熟悉的ETL（extract-transfer-load）工具

3，落hive数仓ODS层

4，增量合并处理

3.3 数据仓库&用户画像

核心技术选型：hive（数据仓库基础设施）

计算引擎：mapreduce + sparksql

存储系统：底层存储HDFS，产出存储（hbase,elastic search,click house,kylin,mysql）

模型设计

数仓分层运算

各类数据的产出

3.4 数据服务& OLAP分析平台

l 需要查询的明细数据，入库hbase（或者elastic search）

（用户画像标签明细，用户行为序列明细）

然后开发数据访问接口服务（restful服务）给上层应用

l 固定报表查询

需要查询的固定报表数据，入库mysql/HBASE

（日新、日活、pv、留存、核心业务转化、关键路径转化、关键事件报表，gmv日报周报月报等）

l 规范模型自助多维分析

利用kylin来提供多维分析服务

l 用户行为自助分析服务

要分析的数据，就放在HDFS上

由presto提供查询支撑（或clickhouse）（或impala）

3.5 其他辅助系统

l Azkaban/Oozie任务调度系统

l Atlas元数据和血缘追溯管理（数据治理）

l 其他自研系统

第04章数据说明

4.1 日志埋点技术介绍

日志埋点，是业务系统开发端的工作

作为数据开发人员的我们，仅需提出数据埋点需求，对具体实现技术仅作基本了解

4.1.1 埋点技术介绍

所谓埋点，就是在业务系统的程序中，植入一些收集事件数据的SDK（工具代码），进行各种事件的收集；

l 埋点代码可以植入到业务系统的后端程序中（比如java、php等）

l 也可以植入到业务系统的前端程序（原生app、页面js、微信小程序）中

4.1.2 后端埋点代码示例（JAVA）

譬如，在后端Java系统中植入如下代码来收集用户行为事件

1，用户的商品浏览事件

// 使用 ConcurrentLoggingConsumer 初始化收集器 DoitEventCollector

final DoitEventCollector sa = new DoitEventCollector(new DoitEventCollector.ConcurrentLoggingConsumer("日志路径"));

// 用户的 Distinct ID

String distinctId = "ABCDEF123456789";

// 用户浏览商品

{

Map<String, Object> properties = new HashMap<String, Object>();

// '$time' 属性是系统预置属性，表示事件发生的时间，如果不填入该属性，则默认使用系统当前时间

properties.put("$time", new Date());

// '$ip' 属性是系统预置属性，如果服务端中能获取用户 IP 地址，并填入该属性

properties.put("$ip", "123.123.123.123");

// 商品 ID

properties.put("ProductId", "123456");

// 商品类别

properties.put("ProductCatalog", "Laptop Computer");

// 是否加入收藏夹，Boolean 类型的属性

properties.put("isAddedToFav", true);

// 记录用户浏览商品事件

sa.track(distinctId, true, "ViewProduct", properties);

}

2，支付订单事件

// 用户订单付款

{

// 订单中的商品 ID 列表

List<String> productIdList = new ArrayList<String>();

productIdList.add("123456");

productIdList.add("234567");

productIdList.add("345678");

Map<String, Object> properties = new HashMap<String, Object>();

// 用户IP

properties.put("$ip", "123.123.123.123");

// 订单 ID

properties.put("OrderId", "abcdefg");

// 商品 ID 列表，List<String> 类型的属性

properties.put("ProductIdList", productIdList);

// 订单金额

properties.put("OrderPaid", 12.10);

// 记录用户订单付款事件

sa.track(distinctId, true, "PaidOrder", properties);

}

4.1.3 前端埋点代码示例（WEB JS）

埋点代码植入前端的js文件或者html中

1，初始化收集器，设置公共属性

// 注册公共属性

collector.registerPage({

current_url: location.href,

referrer: document.referrer});

</script>

2，采集用户登录事件

// 业务代码执行登录动作

var user = userLogin();

//判断登录成功后，发送登录成功事件

if ......

collector.login(user.account)

3，采集用户添加购物车事件

collector.track('AddCart',

{

ProductName: "MacBook Pro",

ProductPrice: 15600.45,

IsAddedToFav: false,

}

);

4.2 行为日志事件类型

l 前端埋点，本质上就是为页面各种元素（按钮，链接，输入框……）绑定js事件；

l 而后端埋点，则主要是交易类行为（提交订单，支付，取消订单等）的采集；

4.2.1 全埋点

泛绑定（所谓全埋点，也有叫无埋点的）

此类埋点的方案是，无区别地对所有页面元素埋点，并取得元素操作行为相关的各种通用属性（如被操作的元素名称，元素id，元素所在页面，元素类型，……）

4.2.2 常规埋点

此类埋点的方案是，对特定元素进行特定意义数据的采集，如只对业务所关心的某些按钮，某些输入框，某些图片等进行事件绑定，并在绑定事件中，生成更为具象的事件信息，如：添加购物车事件（什么时间，哪个用户，哪个商品，哪个页面，什么事件……），注册事件，搜索事件，点赞事件……

4.2.3 后端埋点

4.2.4 小程序埋点

4.3 行为日志数据结构

埋点生成的日志数据，统一设计为JSON格式；

各个终端渠道的埋点日志，都由公共属性字段，和事件属性字段组成；

1) 不同终端渠道，公共属性字段略有不同；

2) 事件属性则根据事件类型，灵活多样；

4.3.1 APP端埋点日志示例

{

"account": "Vz54E9Ya",

"appId": "cn.doitedu.app1",

"appVersion": "3.4",

"carrier": "中国移动",

"deviceId": "lzhDJKAEKEPE",

"deviceType": "MI-6",

"ip": "24.93.136.175",

"latitude": 42.09287620431088,

"longitude": 79.42106825764643,

"netType": "WIFI",

"osName": "android",

"osVersion": "6.5",

"releaseChannel": "豌豆荚",

"resolution": "1024*768",

"sessionId": "EUbuoZXoxwL",

"timeStamp": 1594534406220

"eventId": "productView",

"properties": {

"pageId": "646",

"productId": "157",

"refType": "4",

"refUrl": "805",

"title": "IBR FhG XxX",

"url": "znc/Ciw",

"utm_campain": "4",

"utm_loctype": "1",

"utm_source": "10"

}

4.3.2 WX小程序日志示例

{

"account": "OojqS36Vk",

"carrier": "中国电信",

"deviceType": "MEIZU-ML7",

"ip": "208.67.109.145",

"latitude": 39.83538766367311,

"longitude": 109.96112871255549,

"netType": "WIFI",

"openid": "TCEwZZNJ",

"osName": "android",

"osVersion": "8.5",

"resolution": "2048*1024",

"sessionId": "7qSqmopgg0q",

"timeStamp": 1595752563993

"eventId": "adClick",

"properties": {

"adCampain": "15",

"adId": "5",

"adLocation": "2",

"pageId": "475"

}

4.3.3 Web端埋点日志示例

{

"account": "OojqS36Vk",

"carrier": "中国电信",

"cookieid": "QIGfKLZOy3mz",

"ip": "208.67.109.145",

"netType": "WIFI",

"osName": "android",

"osVersion": "8.5",

"resolution": "2048*1024",

"sessionId": "7qSqmopgg0q",

"timeStamp": 1595752563993,

“userAgent” :”Chrome 80.47.4.400 webkit”

"eventId": "adClick",

"properties": {

"adCampain": "15",

"adId": "5",

"adLocation": "2",

"pageId": "475"

}

4.4 业务数据说明

业务数据：是由业务系统（程序）根据用户的业务操作，在业务系统数据库（比如mysql）中记录下来的重要事务性数据

（比如，订单信息，用户注册信息，积分信息，物流信息，商品信息等；

通常至少几十张表，业务越丰富，表越多，上百是常事）

4.4.1 订单交易信息表

oms_order

oms_order_item

oms_order_operate_history

oms_order_return_apply

oms_order_return_reason

4.4.2 产品信息表

pms_album

pms_album_pic

pms_brand

pms_comment

pms_comment_replay

pms_feight_template

pms_member_price

pms_product

pms_product_attribute

pms_product_attribute_category

pms_product_attribute_value

pms_product_category

pms_product_category_attribute_relation

pms_product_full_reduction

pms_product_ladder

pms_product_operate_log

pms_product_vertify_record

pms_sku_stock

4.4.3 优惠券信息表

sms_coupon

sms_coupon_history

sms_coupon_product_category_relation

sms_coupon_product_relation

4.4.4 限时购秒杀信息表

sms_flash_promotion

sms_flash_promotion_log

sms_flash_promotion_product_relation

sms_flash_promotion_session

4.4.5 营销广告位信息表

sms_home_advertise

sms_home_brand

sms_home_new_product

sms_home_recommend_product

sms_home_recommend_subject

4.4.6 会员信息表

ums_member

ums_member_level

ums_member_login_log

ums_member_member_tag_relation

ums_member_product_category_relation

ums_member_receive_address

ums_member_rule_setting

ums_member_statistics_info

ums_member_tag

ums_member_task

4.4.7 购物车信息表

oms_cart_item

CREATE TABLE `oms_cart_item` (

`id` bigint(20) NOT NULL AUTO_INCREMENT,

`product_id` bigint(20) DEFAULT NULL,

`product_sku_id` bigint(20) DEFAULT NULL,

`member_id` bigint(20) DEFAULT NULL,

`quantity` int(11) DEFAULT NULL COMMENT '购买数量',

`price` decimal(10,2) DEFAULT NULL COMMENT '添加到购物车的价格',

`sp1` varchar(200) DEFAULT NULL COMMENT '销售属性1',

`sp2` varchar(200) DEFAULT NULL COMMENT '销售属性2',

`sp3` varchar(200) DEFAULT NULL COMMENT '销售属性3',

`product_pic` varchar(1000) DEFAULT NULL COMMENT '商品主图',

`product_name` varchar(500) DEFAULT NULL COMMENT '商品名称',

`product_sub_title` varchar(500) DEFAULT NULL COMMENT '商品副标题（卖点）',

`product_sku_code` varchar(200) DEFAULT NULL COMMENT '商品sku条码',

`member_nickname` varchar(500) DEFAULT NULL COMMENT '会员昵称',

`create_date` datetime DEFAULT NULL COMMENT '创建时间',

`modify_date` datetime DEFAULT NULL COMMENT '修改时间',

`delete_status` int(1) DEFAULT '0' COMMENT '是否删除',

`product_category_id` bigint(20) DEFAULT NULL COMMENT '商品分类',

`product_brand` varchar(200) DEFAULT NULL,

`product_sn` varchar(200) DEFAULT NULL,

`product_attr` varchar(500) DEFAULT NULL COMMENT '商品销售属性:[{"key":"颜色","value":"颜色"},{"key":"容量","value":"4G"}]',

PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=17 DEFAULT CHARSET=utf8 COMMENT='购物车表';

第05章数仓技术选型及分层设计

什么数仓：一个面向分析的，反映历史变化的数据仓库；

数仓的技术手段：

1) 传统数仓一般都是采用关系型数据库软件；

2) 大数据领域中则尚无一站式解决方案，通常需要用到很多技术组件来实现不同环节：

l使用HDFS做存储

l使用spark、mapreduce 作为底层计算引擎

l使用hive或者sparksql，作为sql引擎

l另外，还有impala/presto纯内存运算引擎，kylin，clickhouse 等各类组件

5.1 技术选型

数据采集：flume

存储平台：hdfs

基础设施：hive

运算引擎：mapreduce/spark

资源调度：yarn

任务调度：azkaban/oozie

元数据管理：atlas（或自研系统）

OLAP引擎：kylin/presto （或clickhouse）

前端界面：superset（或自研javaweb系统）

5.2 分层设计

5.2.1 分层原因

数据仓库中的数据表，往往是分层管理、分层计算的；

所谓分层，具体来说，就是将大量的数据表按照一定规则和定义来进行逻辑划分；

l ADS层：应用服务层

l DWS层：数仓服务（service/summary）层（轻度聚合）

l DWD层：数仓明细层

l ODS层：操作数据（最原始的数据）层-- 贴源层

l DIM层：存储维表

ODS层：对应着外部数据源ETL到数仓体系之后的表！

DWD层：数仓明细层；一般是对ODS层的表按主题进行加工和划分；本层中表记录的还是明细数据；

DWS层：数仓服务层；

ADS层：应用层，主要是一些结果报表！

分层的意义：数据管理更明晰！运算复用度更高！需求开发更快捷！便于解耦底层业务（数据）变化！

5.2.2 分层详解

1）ODS层

数据内容：存放flume采集过来的原始日志

存储格式：以json格式文本文件存储

存储周期：3个月

2） DWD层

数据内容：对ODS层数据做ETL处理后的扁平化明细数据

存储格式：以orc / parquet文件格式存储

存储周期：6个月

3） DWS层

数据内容：根据主题分析需求，从DWD中轻度聚合后的数据

存储格式：以ORC/PARQUET文件格式存储

存储周期：1年

4） ADS层

数据内容：根据业务人员需求，从DWS计算出来的报表

存储格式：以ORC/PARQUET文件格式存储

存储周期：3年

5） DIM层

存储各种维表

5.3 数据模型概要设计

5.3.1 ODS层

与原始日志数据保持完全一致

我们有APP端日志，PC端日志，微信小程序端日志，分别对应ODS的三个表

ODS.ACTION_APP_LOG

ODS.ACTION_WEB_LOG

ODS.ACTION_WXAPP_LOG

建表时，一般采用外部表；

表的数据文件格式：跟原始日志文件一致

分区：按天分区（视数据量和计算频度而定，如数据量大且需每小时计算一次，则可按小时粒度分区）

5.3.2 DWD层

1）建模思想

通常是对ODS层数据进行精细化加工处理

不完全星型模型

事实表中，不是所有维度都按维度主键信息存储（维度退化）

l 地域维度信息：年月日周等时间维度信息，这些维度信息，基本不会发生任何改变，并且在大部分主题分析场景中，都需要使用，直接在事实表中存储维度值

l 页面信息：页面类别信息，频道信息，业务活动信息，会员等级信息等，可能发生缓慢变化的维度信息，事实表中遵循经典理论存储维度主键，具体维度值则在主题分析计算时临时关联

2）事实表

app_event_detail： APP-Event事件明细表

web_event_detail： WEB-Event事件明细表

wxapp_event_detail：小程序-Event事件明细表

3）维度表

coupon_info

ad_info

campain_info

lanmu_info

page_info

page_type

pindao_info

promotion_location

huodong_info

miaosha_info

product

product_detail

product_type

shop_info

tuangou_info

user_info

5.3.3 DWS层

1）建模思想

l主题建模

l维度建模

最主要思路：按照分析主题，"汇总"各类数据成大宽表

也有一些做法是，将DWS层的表设计成“轻度聚合表”

2）主要表模型

流量会话聚合天/月表

日新日活维度聚合表

事件会话聚合天/月表

访客连续活跃区间表

新用户留存维度聚合表

运营位维度聚合表

渠道拉新维度聚合表

访客分布维度聚合表

用户事件链聚合表（支撑转化分析，高级留存分析等）

……更多

第06章关于数据建模理论

6.1 经典建模方法论：3范式建模（业务系统数据库建模）

第一范式（1NF）：每一列都是不可分割的原子数据项

（像下面的表格就能分割，所以它连第一范式都算不上）

分割后的样子（本表就符合了第一范式）

第二范式：在1NF基础上，非主键属性必须完全依赖主键

（在1NF基础上消除非主属性对主码的部分函数依赖）

在上面那张表中主码为：学号+课程名称，但是姓名、系名、系主任都部分依赖于主码，这不符合第二范式，所以进行拆分如下

第一张表主码为：学号、课程名称

第二张表主码为：学号

它们都是完全依赖的，因此符合第二范式。

第三范式（3NF）：在2NF的基础上，任何的非主属性不依赖于其他非主属性

（在第二范式基础上消除传递依赖）

注意看第二范式的学生表：存在系主任依赖于系名（系名---> 系主任），所以不符合第三范式

继续进行拆分

6.2 经典建模流程

6.2.1 概念模型

6.2.2 逻辑模型

6.2.3 物理模型

6.2 经典建模工具

Power Designer

6.3经典建模方法论：维度建模

《数仓工具箱-维度建模》

6.3.1 基本概念

事实：现实发生的某件事

维度：衡量事实的一个角度

事实表：记录事实的表；比如，订单表，注册表，购物车，退货表，浏览日志表

维度表：对维度的详细描述信息；比如，地域维表，产品维表，品类维表，栏目维表，时间维表；

6.3.2 事实表举例

访客浏览记录表

uid	session	page	lanmu	pinlei	pid	datetime	areacode
u1	s1	/abc/dd	lm1	cat1	p01	2019-10-21 16:18:21	11010
u1	s1	/bbb/cd	lm2	cat3	p08	2019-10-21 16:18:30	11010
u2	s2	/aty/rt	lm3	cat5	p05	2019-10-21 16:17:21	01010
u2	s2	/bbb/cd	lm2	cat3	p08	2019-10-21 16:19:30	01010

上面的表就是一个 事实表

对事实表，假如要计算pv数（指标 | 度量）

我们可以按如下口径来统计：

l 总pv数

l 每个栏目的pv数

l 每个省份的pv数

l 每个商品品类的pv数

l 每个省份下每个栏目的pv数

从这些需求中可以看出，同一个指标，可以通过多种角度（口径）去统计！

这些角度，或口径，就叫“维度！”

维度组合中的维度越多，统计出来的事实指标粒度越细

6.3.3 维表举例

栏目维度表：

栏目id，栏目名称
lm1	生鲜水产
lm2	冲调饮品
lm3	智能设备

地域码维表：

地域码	省	市
11010	湖北省	武汉市
01010	山西省	临汾市

时间维表：

日期	季度	周数	周几	销售季	活动期间
2019-10-21	4	38	monday
2019-10-21	4	38	monday

维表的作用：可以对统计维度进行人性化的诠释！可以丰富维度内容！

附录，一个实用级时间维表

REATE TABLE `kylin_cal_dt`(
`cal_dt` date COMMENT 'Date, PK', 
`year_beg_dt` date COMMENT 'YEAR Begin Date', 
`qtr_beg_dt` date COMMENT 'Quarter Begin Date', 
`month_beg_dt` date COMMENT 'Month Begin Date', 
`week_beg_dt` date COMMENT 'Week Begin Date', 
`age_for_year_id` smallint, 
`age_for_qtr_id` smallint, 
`age_for_month_id` smallint, 
`age_for_week_id` smallint, 
`age_for_dt_id` smallint, 
`age_for_rtl_year_id` smallint, 
`age_for_rtl_qtr_id` smallint, 
`age_for_rtl_month_id` smallint, 
`age_for_rtl_week_id` smallint, 
`age_for_cs_week_id` smallint, 
`day_of_cal_id` int, 
`day_of_year_id` smallint, 
`day_of_qtr_id` smallint, 
`day_of_month_id` smallint, 
`day_of_week_id` int, 
`week_of_year_id` tinyint, 
`week_of_cal_id` int, 
`month_of_qtr_id` tinyint, 
`month_of_year_id` tinyint, 
`month_of_cal_id` smallint, 
`qtr_of_year_id` tinyint, 
`qtr_of_cal_id` smallint, 
`year_of_cal_id` smallint, 
`year_end_dt` string, 
`qtr_end_dt` string, 
`month_end_dt` string, 
`week_end_dt` string, 
`cal_dt_name` string, 
`cal_dt_desc` string, 
`cal_dt_short_name` string, 
`ytd_yn_id` tinyint, 
`qtd_yn_id` tinyint, 
`mtd_yn_id` tinyint, 
`wtd_yn_id` tinyint, 
`season_beg_dt` string, 
`day_in_year_count` smallint, 
`day_in_qtr_count` tinyint, 
`day_in_month_count` tinyint, 
`day_in_week_count` tinyint, 
`rtl_year_beg_dt` string, 
`rtl_qtr_beg_dt` string, 
`rtl_month_beg_dt` string, 
`rtl_week_beg_dt` string, 
`cs_week_beg_dt` string, 
`cal_date` string, 
`day_of_week` string, 
`month_id` string, 
`prd_desc` string, 
`prd_flag` string, 
`prd_id` string, 
`prd_ind` string, 
`qtr_desc` string, 
`qtr_id` string, 
`qtr_ind` string, 
`retail_week` string, 
`retail_year` string, 
`retail_start_date` string, 
`retail_wk_end_date` string, 
`week_ind` string, 
`week_num_desc` string, 
`week_beg_date` string, 
`week_end_date` string, 
`week_in_year_id` string, 
`week_id` string, 
`week_beg_end_desc_mdy` string, 
`week_beg_end_desc_md` string, 
`year_id` string, 
`year_ind` string, 
`cal_dt_mns_1year_dt` string, 
`cal_dt_mns_2year_dt` string, 
`cal_dt_mns_1qtr_dt` string, 
`cal_dt_mns_2qtr_dt` string, 
`cal_dt_mns_1month_dt` string, 
`cal_dt_mns_2month_dt` string, 
`cal_dt_mns_1week_dt` string, 
`cal_dt_mns_2week_dt` string, 
`curr_cal_dt_mns_1year_yn_id` tinyint, 
`curr_cal_dt_mns_2year_yn_id` tinyint, 
`curr_cal_dt_mns_1qtr_yn_id` tinyint, 
`curr_cal_dt_mns_2qtr_yn_id` tinyint, 
`curr_cal_dt_mns_1month_yn_id` tinyint, 
`curr_cal_dt_mns_2month_yn_id` tinyint, 
`curr_cal_dt_mns_1week_yn_ind` tinyint, 
`curr_cal_dt_mns_2week_yn_ind` tinyint, 
`rtl_month_of_rtl_year_id` string, 
`rtl_qtr_of_rtl_year_id` tinyint, 
`rtl_week_of_rtl_year_id` tinyint, 
`season_of_year_id` tinyint, 
`ytm_yn_id` tinyint, 
`ytq_yn_id` tinyint, 
`ytw_yn_id` tinyint, 
`kylin_cal_dt_cre_date` string, 
`kylin_cal_dt_cre_user` string, 
`kylin_cal_dt_upd_date` string, 
`kylin_cal_dt_upd_user` string)COMMENT 'Date Dimension Table'ROW FORMAT SERDE 
'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe' WITH SERDEPROPERTIES ( 
'field.delim'=',', 
'serialization.format'=',') 
STORED AS INPUTFORMAT 
'org.apache.hadoop.mapred.TextInputFormat' 
OUTPUTFORMAT 
'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION
'hdfs://bigdata/user/hive/warehouse/kylin_cal_dt'
TBLPROPERTIES (
'transient_lastDdlTime'='1580892438')

这是一个常见的时间维度表，里面充斥这各种用途的时间维度，如每个日期对应的星期，每个日期对应的月份等。这些维度可以被分析师用来灵活地进行各个时间粒度上的聚合分析，而不需要进行额外的上卷操作。

6.3.4 维度建模经典模型

星型模型

雪花模型

星座模型

6.4 项目建模：流量域

以Event事件表为中心事实表

以user，页面频道信息，产品信息，活动信息等为关联维表

l App端事件表

l Wx端事件表

l Web端事件表

6.5 项目建模：业务域

按不同事实主题建设宽表

l 交易域

l 营销域

l 活动域

l 广告域

l 会员域

6.6 项目建模：画像域

l 用户基本属性标签表

l 用户订单属性标签表

l 用户退换货属性标签表

l 用户购物车属性标签表

l 用户活跃属性标签表

l 用户偏好属性标签表

6.6.1 用户基本属性标签表

用户属性指标主要根据业务数据来源（业务系统中的用户信息）

尽可能全面地描述用户基础属性

这些基础属性值是短期内不会有改变的，如年龄、性别、手机号归属地、身份证归属地等

字段	字段类型	字段定义
user_id	bigint	用户编码
login_name	string	登录名称
user_name	string	用户姓名
user_status_id	int	用户状态
gender_id	int	用户性别
birthday	int	用户生日
user_age	int	用户年龄
constellation_name	string	星座名称
zodiac_name	string	生肖名称
cellphone_id	string	手机号
cert_id	string	证件号
source_id	bigint	注册来源
is_real_name_auth	int	是否实名认证标志
is_valid_cellphone	int	是否认证手机标志
is_has_photo	int	是否有头像标志
is_tmp_user_flag	timestamp	注册时间
create_time	string	注册日期
create_date	timestamp	修改时间
modify_time	string	修改时间
modify_date	timestamp	修改日期
date_id	string	数据日期

6.6.2 用户登录活跃标签表

看用户近期登录时间段、登录时长、登录频次、常登陆地等指标

字段	类型	定义	备注
user_id	int	用户id	用户唯一id
login_city_ration	string	常登陆地	用户近一个月常登陆的3个地点及比率
last_online_date	string	最近登陆时间	用户最近一次登录日期
online_frequency	int	登录频次	用户近一个月登录频次
online_time	int	登录时长	用户近一个月登录时长

6.6.3 用户年龄段标签表

在做营销活动或站内推送时，可对不同年龄段做针对性运营

字段	类型	定义	备注
user_id	string	用户编码
contact_id	string	联系人编码
user_sex	string	用户性别
user_age_crowd	string	用户年龄群体	儿童（0-10）少年（11-15）......

6.6.4 用户交互行为标签

记录用户在平台上每一次操作行为，及该次行为所带来的标签。后续可根据用户的行为标签计算用户的偏好标签，做推荐和营销等活动

字段	类型	定义	备注
user_id	string	用户id	用户唯一id
org_id	string	原始id	标签id
org_name	string	标签中文名称	标签对应标签的中文名称
is_valid	string	是否有效	1有效 0无效
cnt	string	行为次数	用户行为次数
date_id	string	行为日期	产生用户该条标签对应日期
act_type_id	int	用户行为类型	1搜索2浏览3收藏4下单5支付6退货
tag_type_id	int	频道类型	1母婴2家电3美妆4美食5服装6鲜花

6.6.5用户消费能力标签

看用户的消费金额、消费频次、最近消费时间。进一步结合用户登录活跃情况，可以对用户做RFM分层。

字段	类型	定义	备注
user_id	string	用户编码
sum_pay	string	累积付费金额
sum_num	decimal	累积付费次数
paid_level	int	付费分层	1：[0,30) 2：[30,100) 3：[100,300)...

6.6.6 用户订单画像标签

字段	类型	定义
user_id	bigint	用户
first_order_time	string	首单日期
last_order_time	string	末单日期
first_order_ago	bigint	首单距今时间
last_order_ago	bigint	末单距今时间
month1_order_cnt	bigint	近30天购买次数
month1_order_amt	double	近30天购买金额
month2_order_cnt	bigint	近60天购买次数
month2_order_amt	double	近60天购买金额
month3_order_cnt	bigint	近90天购买次数
month3_order_amt	double	近90天购买金额
max_order_amt	double	最大订单金额
min_order_amt	double	最小订单金额
total_order_cnt	bigint	累计消费次数（不含退拒）
total_order_amt	double	累计消费金额（不含退拒）
total_coupon_amt	double	累计使用代金券金额
user_avg_order_amt	double	平均订单金额（含退拒）
month3_user_avg_amt	double	近90天平均订单金额（含退拒）
common_address	string	常用收货地址
common_paytype	string	常用支付方式
month1_cart_cnt_30	bigint	最近30天加购次数
month1_cart_goods_cnt_30	bigint	最近30天加购商品件数
month1_cart_submit_cnt_30	bigint	最近30天提交件数
month1_cart_submit_rate	double	最近30天商品提交占比
month1_cart_cancel_cnt	bigint	最近30天取消商品件数
dw_date	string	计算日期

6.6.7 用户退拒货行为画像标签

字段	类型	定义
user_id	bigint	用户
p_sales_cnt	bigint	不含退拒商品购买数量
p_sales_amt	double	不含退拒商品购买的商品总价
p_sales_cut_amt	double	不含退拒实付金额（扣促销减免）
h_sales_cnt	bigint	含退拒购买数量
h_sales_amt	double	含退拒购买金额
h_sales_cut_amt	double	含退拒购买金额（扣促销减免）
return_cnt	bigint	退货商品数量
return_amt	double	退货商品金额
reject_cnt	bigint	拒收商品数量
reject_amt	double	拒收商品金额
dw_date	bigint	数仓计算日期

6.6.8 用户购物偏好画像标签

字段	类型	定义
user_id	bigint	用户
common_first_cat	bigint	最常购买一级类目名称
common_second_cat	bigint	最常购买二级类目名称
common_third_cat	bigint	最常购买三级类目名称
common_brand_id	bigint	最常购买的品牌
dw_date	bigint	数仓计算日期

标签：需求,数据业务,背景,用户,事件,cal,dt,id,string
From： https://www.cnblogs.com/learnbigdata/p/17512726.html

大数据业务背景与需求分析

1.1学习要求

1.2项目背景

1.3开发总目标

第02章 需求概况

2.1 行为域基础（流量）分析

2.1.1 分析主题概览

2.1.2 整体流量概况

2.1.3 访问渠道分析

2.1.4 用户分布分析

2.1.5 APP版本分析

2.1.6 活跃度分析

2.1.7 用户留存分析

2.1.8 事件转化分析

2.2 行为域进阶分析

2.2.1 转化漏斗分析

2.2.2 事件留存分析

2.2.3 行为分布分析

2.2.4 行为归因分析

2.2.5 行为路径分析

2.2.6 行为间隔分析

2.2.7 其他高阶分析

2.3 业务域分析

2.3.1 概述

2.3.2 购物车分析

2.3.3 交易金额分析

2.3.4 复购率分析

2.3.5 优惠券分析

2.3.6 团购分析

2.3.7 秒杀限时购分析

2.3.8 其他营销活动

2.3.9 广告运营位分析

2.3.10 拉新注册分析

2.3.11 会员分析（用户画像）

2.4 用户画像分析

1.7.1 基本属性画像

1.7.2 行为习惯画像

1.7.3 消费习惯画像

1.7.4 其他

2.5 OLAP数据分析平台

第03章 整体方案设计

3.1 日志埋点（生成）

3.2 数据采集汇聚

3.3 数据仓库&用户画像

3.4 数据服务& OLAP分析平台

3.5 其他辅助系统

第04章 数据说明

4.1 日志埋点技术介绍

4.1.1 埋点技术介绍

4.1.2 后端埋点代码示例（JAVA）

4.1.3 前端埋点代码示例（WEB JS）

4.2 行为日志事件类型

4.2.1 全埋点

4.2.2 常规埋点

4.2.3 后端埋点

4.2.4 小程序埋点

4.3 行为日志数据结构

4.3.1 APP端埋点日志示例

4.3.2 WX小程序日志示例

4.3.3 Web端埋点日志示例

4.4 业务数据说明

4.4.1 订单交易信息表

4.4.2 产品信息表

4.4.3 优惠券信息表

4.4.4 限时购秒杀信息表

4.4.5 营销广告位信息表

4.4.6 会员信息表

4.4.7 购物车信息表

第05章 数仓技术选型及分层设计

5.1 技术选型

5.2 分层设计

5.2.1 分层原因

5.2.2 分层详解

1）ODS层

2） DWD层

3） DWS层

4） ADS层

5） DIM层

5.3 数据模型概要设计

5.3.1 ODS层

第02章需求概况

第03章整体方案设计

第04章数据说明

第05章数仓技术选型及分层设计

1）建模思想

2）事实表

3）维度表

1）建模思想

2）主要表模型

第06章关于数据建模理论