企业级大数据项目【1】需求分析及概要设计篇

1学习要求

每日总结当天内容

需求是什么
解决需求的方案是什么
具体实现逻辑是什么
开发过程中有遇到哪些问题

2项目背景

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

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

营销分析断层：市场营销成本居高不下，投放拉新的效果追踪出现断层，无法追踪各渠道实际转化率，难以准确分析 ROI。
产品迭代无法量化：缺少实时的用户行为分析能力，使得产品功能改版的效果无法量化衡量，核心流程优化点更多靠拍脑袋，bug问题的定位后知后觉造成长时间的损失。
用户运营不精准：“千人一面”的全量用户营销，投入产出难以把控，不精准的粗犷方式难以真正提升存量用户的长期活跃度。
全局运营指标监控不实时：有运营的 BI 系统，但运营指标监控不及时，未形成核心的指标预警机制，决策滞后。

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

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

以上内容，请自己补充阅读；
总之就是强调数据以及数据驱动的重要性

3需求总览：行为事件域分析

3.1基础统计分析

整体概况：从产品整体的使用情况出发，对产品整体的使用情况有基础了解。
用户获取：从获客渠道和版本的方向出发，根据不同渠道、不同的版本生成一些可以了解渠道优劣的指标，可以清晰的观察每个渠道的流量、转化等情况。
活跃与留存：从用户的访问和粘性出发，可以观察出产品在用户访问、回访等方面的趋势变化，清楚地了解用户对产品的粘性和沉浸程度。
事件转化：根据选择的事件和属性，生成该事件的发生次数、人数、分布等数据指标，可以了解整体的用户转化以及收益相关的数据情况。
用户特征：根据地址位置、性别、操作系统等一些基础属性，将用户进行分组，方便了解用户的分布占比情况。

3.2基础统计分析指标概览

整体概况

产品整体的使用情况，包括用户量、访问情况、留存等
帮助对产品整体指标有一个大致的了解

累计用户量：产品上线至今的累计用户量
每日新增用户量
每日的全部访问人数、次数
每日的全部访问的人均次数/时长/深度
新老用户访问占比
每日新老用户的分布情况
新用户/全部用户的7日留存：起始和后续事件都为用户进行页面访问
各页面的访问次数分布：基于pageview事件中的页面标题属性进行分组
访问终端（app /pc web /微信小程序 /H5）分布：按照访问的操作系统分组

用户获取

渠道访问

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

新增用户量：全部新用户数量，包括自然流量和渠道流量
渠道新增用户量：仅计算渠道流量新增用户数
各渠道新用户人均访问时长
异常流量：App 异常流量，定义为打开5秒内即进行关闭操作的访问行为

版本数据

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

版本访问流量
人均访问时长
各版本留存：各版本的用户7日留存

活跃与留存

访问流量

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

访问用户数
新老用户访问占比
新老用户人均使用时长
新老用户启动/访问次数
每日/每周启动时段
用户每日访问产品的时段分布
用户每周访问产品的星期分布

用户留存

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

7日留存/流失
次日留存/流失
次周留存/流失
次月留存/流失

事件转化
事件转化

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

新老用户事件发生次数/人数/人均次数
事件次数的分布

收益类事件转化

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

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

用户特征

访问省份分布
访问城市分布
访问性别分布
访问操作系统分布
新老用户占比

3.3进阶用户行为分析

漏斗分析
漏斗模型主要用于分析一个多步骤过程中每一步的转化与流失情况。
举例来说，用户购买商品的完整流程可能包含以下步骤：

1.浏览商品
2.将商品添加进购物车
3.结算购物车中的商品
4.选择送货地址、支付方式
5.点击付款
6.完成付款

可以将如上流程设置为一个漏斗，分析整体的转化情况，以及每一步具体的转化率和转化中位时间。
同时也希望能有强大的筛选和分组功能进行深度分析。

行为留存分析
留存分析是一种用来分析用户参与情况/活跃程度的分析模型，考查进行初始行为后的用户中，有多少人会进行后续行为。
这是衡量产品对用户价值高低的重要指标。

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

一个新客户在未来的一段时间内是否完成了期许的行为？如支付订单
改进了新注册用户的引导流程后，期待改善用户注册后的参与程度，如何验证？
想判断某项产品改动是否奏效，如新增了一个邀请好友的功能，观察是否有人因新增功能而多使用产品几个月？

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

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

策略调整前后，用户每天使用产品次数是否增加？
用户首次购买后是否会重复购买？
假设每天使用 3 次以上某关键功能的用户算作核心用户，那么核心用户的成分变化趋势如何？

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

目标转化事件：
选择产品的目标事件，一般为与收益相关的事件，如：提交订单详情、支付…
支持选择全部的元事件
目标转化事件的高级设置：
前向关键事件
选择目标转化事件的前向事件，主要是为了提升归因模型的计算精度。一般选择与目标事件有强关联的事件，类似商品曝光，如：查看商品详情、加入购物车…
关联属性：将目标转化事件和前向关键事件进行关联的属性
待归因事件
选择待归因事件，一般为与广告曝光、推荐曝光等运营相关事件，如：点击广告位、点击推荐位…
归因模型
首次触点模型：多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为第一个「待归因事件」功劳为 100%
末次触点归因：多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为最后一个「待归因事件」功劳为 100%
线性归因：多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为每个「待归因事件」平均分配此次功劳
位置归因：多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为第一个和最后一个「待归因事件」各占 40%
功劳，其余「待归因事件」平分剩余的 20% 功劳
时间衰减归因：多个「待归因事件」对同一个「目标转化事件」作出贡献时，认为越靠近「目标转化事件」做出的贡献越大

行为路径分析

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

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

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

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

包含了实名认证等复杂操作的注册流程，想知道用户从开始注册到注册结束，整个过程花费的时长分布。
电商类产品分析用户首次打开 app 或完成注册，到完成首次下单所花费的时长分布。
投资理财类产品分析新用户完成绑卡到完成首次投资的时间间隔分布。

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

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

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

4需求总览：业务域分析

4.1交易域

购物车分析（维度：品类、人群、时段）
当日/本周/本月日加购总数
当日/本周/本月提交总数
当日/本周/本月取消总数
订单GMV分析（维度：终端，地域，品类）
当日/本周/本月 GMV总额
当日/本周/本月订单支付总额
当日/本周/本月下单人数
当日/本周/本月客单价分析
当日/本周/本月取消订单数
当日/本周/本月取消订单用户数
当日/本周/本月退货次数
当日/本周/本月退货用户数
GMV近30日变化趋势
GMV各端贡献情况（平台类型，GMV，订单量，下单人数，客单价，笔单价）
下单金额分布（1000以下，1000-2000,2000-3000,3000-4000,4000+）
当日/本周/本月商品销售情况（商品名称，品类，店铺，购买次数、人数，销售额）
当日/本周/本月各品类商品销量趋势（品类，日期，购买次数、人数，销售额）
当日/本周/本月各店铺商品销量占比（店铺，购买、购买人数，销售额）
复购分析（维度：品类，人群，终端，地域）
当日/本周/本月各端复购率
当日/本周/本月购买频次分析（1次，2-3次，3-4次，4-5次）
订单实时分析
订单量分钟级
订单量小时级
订单用户趋势分析

4.2营销域

优惠券分析
优惠券抵扣力度（优惠券，日期，抵扣金额）
优惠券使用情况（优惠券，日期，使用次数）

团购分析
团购订单趋势
参团用户趋势
各品类开团数
各品类成团数

秒杀限时购分析
秒杀订阅人数
秒杀成交订单趋势
秒杀支付类型趋势

其他营销活动
国庆大豪礼
金秋大放送
活动地域趋势分析
活动订单趋势分析

4.3运营活动域

广告运营位分析
当日/本周/本月曝光度
当日/本周/本月点击率
当日/本周/本月转化率
拉新注册分析
当日/本周/本月渠道分布
当日/本周/本月转化率

4.4会员域（用户画像）

当日/本周/本月消费情况
当日/本周/本月充值情况
当日/本周/本月会员等级分布
当日/本周/本月活跃分布
当日/本周/本月退换货分布
当日/本周/本月商品评价分析统计
……

5整体方案设计

5.1数据收集（生成）

主要数据类别：

用户行为日志数据[需要在业务系统的前端（或后端）中做埋点]
业务数据[已经在业务系统的数据库中]
历史数据
其他第三方数据

5.2核心处理流程

1，数据采集汇聚

行为域数据
1，日志前端埋点，生成日志数据
2，日志服务器存储为日志文件
3，Flume采集落地hdfs
5，日志预处理
6，落hive数仓ODS层
业务域数据
1，业务系统增删改数据库，形成业务数据
2，Sqoop/DataX/ Kettle数据抽取
注： Kettle是一些传统企业比较熟悉的ETL（extract-transfer-load）工具
3，落hive数仓ODS层
4，增量合并处理

2，数据仓库&用户画像
核心技术选型：hive（数据仓库基础设施）
计算引擎：mapreduce + sparksql
存储系统：底层存储HDFS，产出存储（hbase,elastic search,click house,kylin,mysql）

模型设计
数仓分层运算
各类数据的产出

3，数据服务& OLAP分析平台

需要查询的明细数据，入库hbase（或者elastic search）
（用户画像标签明细，用户行为序列明细）
然后开发数据访问接口服务（restful服务）给上层应用
固定报表查询
需要查询的固定报表数据，入库mysql/HBASE
（日新、日活、pv、留存、核心业务转化、关键路径转化、关键事件报表，gmv日报周报月报等）
规范模型自助多维分析
利用kylin来提供多维分析服务
用户行为自助分析服务
要分析的数据，就放在HDFS上
由presto提供查询支撑（或clickhouse）（或impala）

5.3管理辅助系统

Azkaban/Oozie任务调度系统
Atlas元数据和血缘管理（数据治理）
其他自研系统

6埋点日志说明

日志埋点，是业务系统开发端的工作作为数据开发人员的我们，仅需提出数据埋点需求，对具体实现技术仅作基本了解

6.1埋点技术介绍

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

埋点代码可以植入到业务系统的后端程序中（比如java、php等）
也可以植入到业务系统的前端程序（原生app、页面js、微信小程序）中

后端埋点代码示例（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");// 商品 IDproperties.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>();// 用户 IPproperties.put("$ip", "123.123.123.123");// 订单 IDproperties.put("OrderId", "abcdefg");// 商品 ID 列表，List<String> 类型的属性properties.put("ProductIdList", productIdList);// 订单金额properties.put("OrderPaid", 12.10);// 记录用户订单付款事件sa.track(distinctId, true, "PaidOrder", properties);
}

前端埋点代码示例（WEB JS）
埋点代码植入前端的js文件或者html中
1，初始化收集器，设置公共属性

<script>// 初始化 SDK
// 注册公共属性
collector.registerPage({current_url: location.href,referrer: document.referrer});
</script>

2，采集用户登录事件

<script>
// 业务代码执行登录动作
var user = userLogin();//判断登录成功后，发送登录成功事件
if ......
collector.login(user.account)<script>

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

collector.track('AddCart',
{ProductName: "MacBook Pro", ProductPrice: 15600.45, IsAddedToFav: false,
}
);

6.2埋点日志中的事件类型

前端埋点，本质上就是为页面各种元素（按钮，链接，输入框……）绑定js事件；
而后端埋点，则主要是交易类行为（提交订单，支付，取消订单等）的采集；

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

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

后端埋点

小程序埋点

6.3埋点日志数据说明

埋点生成的日志数据，统一设计为JSON格式；
各个终端渠道的埋点日志，都由公共属性字段，和事件属性字段组成；
1)不同终端渠道，公共属性字段略有不同；
2)事件属性则根据事件类型，灵活多样；

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"}}

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"},
}

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"},
}

7业务数据说明

业务数据：是由业务系统（程序）根据用户的业务操作，在业务系统数据库（比如mysql）中记录下来的重要事务性数据
（比如，订单信息，用户注册信息，积分信息，物流信息，商品信息等；
通常至少几十张表，业务越丰富，表越多，上百是常事）

7.1订单交易信息表

 oms_order oms_order_item oms_order_operate_historyoms_order_return_applyoms_order_return_reason

7.2产品信息表

 pms_album pms_album_picpms_brand pms_comment pms_comment_replaypms_feight_template
pms_member_price
pms_product
pms_product_attribute
pms_product_attribute_category
pms_product_attribute_value
pms_product_categorypms_product_category_attribute_relation
pms_product_full_reductionpms_product_ladder pms_product_operate_log
pms_product_vertify_record
pms_sku_stock

7.3优惠券信息表

sms_coupon
sms_coupon_history
sms_coupon_product_category_relationsms_coupon_product_relation

7.4限时购秒杀信息表

sms_flash_promotion
sms_flash_promotion_log
sms_flash_promotion_product_relation
sms_flash_promotion_session

7.5营销广告位信息表

sms_home_advertise
sms_home_brand
sms_home_new_product
sms_home_recommend_product
sms_home_recommend_subject

7.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

7.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='购物车表';

8数据建模理论

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

第一范式（1NF）：每一列都是不可分割的原子数据项
（像下面的表格就能分割，所以它连第一范式都算不上）

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

第二范式：在1NF基础上，非主键属性必须完全依赖于主键
（在1NF基础上消除非主属性对主码的部分函数依赖）
在上面那张表中主码为：学号+课程名称，但是姓名、系名、系主任都部分依赖于主码，这不符合第二范式，所以进行拆分如下

第一张表主码为：学号、课程名称
第二张表主码为：学号
它们都是完全依赖的，因此符合第二范式。

第三范式（3NF）：在2NF的基础上，任何的非主属性不依赖于其他非主属性
（在第二范式基础上消除传递依赖）
　　注意看第二范式的学生表：存在系主任依赖于系名（系名—> 系主任），所以不符合第三范式
继续进行拆分

8.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数（指标 | 度量）
我们可以按如下口径来统计：

总pv数
每个栏目的pv数
每个省份的pv数
每个商品品类的pv数
每个省份下每个栏目的pv数

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

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

维表举例
栏目维度表：

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

地域码维表：

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

时间维表：

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

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

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

CREATE 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')

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

维度建模经典模型
星型模型

雪花模型

星座模型

9项目建模：流量域方案

以Event事件表为中心事实表
以user，页面频道信息，产品信息，活动信息等为关联维表

App端事件表
Wx端事件表
Web端事件表

10项目建模：业务域方案

按不同事实主题建设宽表

交易域
营销域
活动域
广告域
会员域

11项目建模：画像域方案

用户基本属性标签表
用户订单属性标签表
用户退换货属性标签表
用户购物车属性标签表
用户活跃属性标签表
用户偏好属性标签表

11.1用户基本属性标签表

用户属性指标主要根据业务数据来源（业务系统中的用户信息）
尽可能全面地描述用户基础属性
这些基础属性值是短期内不会有改变的，如年龄、性别、手机号归属地、身份证归属地等

11.2用户登录活跃标签表

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

11.3用户年龄段标签表

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

11.4用户交互行为标签

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

11.5用户消费能力标签

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

11.6用户订单画像标签

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

11.8用户购物偏好画像标签