标签：小美 name 数据仓库 数据表 apply 分享 数据
- 想知道靓女征友会被多少人加好友么？
- 想知道公司食堂的DAU日活么？
这些我都无法告诉你，因为我也不知道
不过如果你对这些问题感兴趣，那么你可能会希望了解下这些数据的可能来源——数据仓库
举个栗子
- 小美：前两天我和闺蜜们在bbs发征友贴好多人加我们微信呀，但是有人反馈说加好友的频率太高加不上，呜呜呜，哥哥你帮我看看到底有多少人加我们呀
- 开发小哥哥：好的！待我查找下数据！
开始开发
这个任务很简单，我要把所有人的加好友数量都计算出来，然后再过滤下她们的id就好了
- 第一步：找到原始数据表
咦？怎么原始数据表这么多，需要apply_friend member等多张表，而且涉及到的表字段也很多，还有很多无效数据，看来我需要增加一步清洗数据的工作
apply_friend表
| id | apply_name | applied_name |
|---|---|---|
| 1 | 诸葛钢铁 | 小美 |
| 2 | 于小谦 | 小可爱 |
| 3 | null | 小美 |
| 4 | 朴一生 | 小红 |
| 5 | 朴一生 | 小美 |
| 6 | 朴一生 | 小可爱 |
member表
| id | name |
|---|---|
| 1 | 诸葛钢铁 |
| 2 | 于小谦 |
| 3 | 小美 |
| 4 | null |
| 5 | 小红 |
| 6 | 朴一生 |
- 第二步：清洗原始数据产出清洗数据表
SELECT * FROM apply_friend
WHERE apply_name is not null
查询结果存入数据表 clean_apply_friend
| id | apply_name | applied_name |
|---|---|---|
| 1 | 诸葛钢铁 | 小美 |
| 2 | 于小谦 | 小可爱 |
| 4 | 朴一生 | 小红 |
| 5 | 朴一生 | 小美 |
| 6 | 朴一生 | 小可爱 |
SELECT * FROM member
WHERE name is not null
查询结果存入数据表 clean_member
| id | name |
|---|---|
| 1 | 诸葛钢铁 |
| 2 | 于小谦 |
| 3 | 小美 |
| 5 | 小红 |
| 6 | 朴一生 |
- 第三步：进行SQL聚合
SELECT applied_name
,COUNT(applied_name) AS cnt
FROM(
SELECT clean_apply_friend.id AS id
,clean_apply_friend.apply_name AS apply_name
,clean_apply_friend.applied_name AS applied_name
FROM clean_apply_friend
JOIN clean_member
ON clean_apply_friend.applied_name = clean_member.name
)
GROUP BY applied_name
查询结果存入数据表 result
| applied_name | cnt |
|---|---|
| 小美 | 2 |
| 小红 | 1 |
- 第四步：为了更方便的使用图形化工具查找，我最好再加一个数据表用于出库，可以使用BI工具
SELECT applied_name
,cnt
FROM result
查询结果存入数据表 final_result 表，并且配置出库
什么是数据仓库
如果把刚刚每一步计算出来的数据表连起来，会看到下面的结构
如果我们给他们加上一些名词，就会发现这是一个比较清晰的层级结构
- APP（Application）：数据应用层
- DM（Data Mart）：数据集市层
- DW（Data Warehouse）：数据仓库层
- ODS（Operational Data Store）：数据运营层
如果DM数据仓库层不止2个数据表，还有更多可归类的数据表，那么就会形成主题
这就是数据仓库的雏形！
真实的数据仓库
- 小美：小哥哥，你这个数据不太够，我想知道我的每日新增好友添加数量和从我使用微信以来每日累计以前的好友添加数量，可以帮帮我么
- 开发小哥哥：好的！待我查找下数据！
上述小美的表达才是更接近真实的数据需求，通常数据需求会有比较常见的2大系列，分别是：
- 每日新增数据：
- 11.17 加好友的数量是5个
- 11.18 加好友的数量是6个
- 每日累计数据：
- 从创建微信以来到11.16加好友的数量是95个
- 从创建微信以来到11.17加好友的数量是100个
- 从创建微信以来到11.18加好友的数量是106个
可以看到数据关系 95 + 5 = 100，100 + 6 = 106
如何计算每日新增和每日累计
为了完成上述两种统计数据，就要求线上数据必须每日同步增量数据，并根据数据日期ds字段进行区分
apply_friend 表
| ds | id | apply_name | applied_name |
|---|---|---|---|
| 20210901 | 1 | 诸葛钢铁 | 小美 |
| 20210901 | 2 | 于小谦 | 小可爱 |
| 20210901 | 3 | null | 小美 |
| 20210901 | 4 | 朴一生 | 小红 |
| 20210902 | 5 | 朴一生 | 小美 |
| 20210902 | 6 | 朴一生 | 小可爱 |
可以看到前 4 条数据都是2021年9月1日出现的，后 2 条数据是2021年9月2日出现的
根据这样的表计算出每日新增的数据很容易，用ds作为查询条件进行聚合即可，比如计算9月1日用户的申请的数量
SELECT COUNT(*)
FROM apply_friend
WHERE ds = 20210902
GROUP BY applied_name
而计算每日累计数据时，更建议清洗出一张全量数据表，并用其直接进行计算
什么是全量数据表
所谓的全量数据表指的是每天都存储从原始数据产生以来的所有数据，尤其是当存在状态变化时，全量数据表的存在尤为重要
比如：
apply_friend 表
| ds | id | apply_name | applied_name | status |
|---|---|---|---|---|
| 20210901 | 1 | 朴一生 | 小美 | 申请中 |
| 20210901 | 2 | 诸葛钢铁 | 小美 | 申请中 |
| 20210902 | 3 | 诸葛钢铁 | 小美 | 已查看 |
| 20210902 | 4 | 朴一生 | 小红 | 申请中 |
| 20210903 | 5 | 诸葛钢铁 | 小美 | 已拒绝 |
对应的全量数据表为：
full_apply_friend 表
| ds | id | apply_name | applied_name | status |
|---|---|---|---|---|
| 20210901 | 1 | 朴一生 | 小美 | 申请中 |
| 20210901 | 2 | 诸葛钢铁 | 小美 | 申请中 |
| 20210902 | 1 | 朴一生 | 小美 | 申请中 |
| 20210902 | 3 | 诸葛钢铁 | 小美 | 已查看 |
| 20210902 | 4 | 朴一生 | 小红 | 申请中 |
| 20210903 | 1 | 朴一生 | 小美 | 申请中 |
| 20210903 | 4 | 朴一生 | 小红 | 申请中 |
| 20210903 | 5 | 诸葛钢铁 | 小美 | 已拒绝 |
我们可以看到，9月2日，加入了9月1日的数据，9月3日又加入了1-2日的数据，并且过滤掉了多余的状态条数，也就是诸葛钢铁和小美的申请关系
上述数据关注小美相关的会发现，从9月1日-9月3日期间，诸葛钢铁申请小美好友的申请关系变化，申请中->已查看->已拒绝
如果我们统计9月1日小美累计处于申请中的好友申请数量，那么是2
统计9月2日小美累计处于申请中的好友数量，那么是1
为什么要建设数据仓库
数据仓库建设是为了解决很多数据计算的问题，其中包括
- 数据依赖关系混乱，重复计算
- 缺少数据计算规范
- 数据产出效率低
数据依赖关系混乱，重复计算
看上图对比我们就可以知道，没有数据仓库时，数据依赖关系十分混乱，存在大量数据重复计算的问题，既浪费计算资源，又让后来的开发者无所适从，不知道应该如何继续开发
而有了数据仓库之后，计算任务整洁有序，便于维护和开发，也节省资源
缺少数据计算规范
数据开发和普通的代码开发一样，也应该树立上图的开发规范，保证数据计算的顺序性，模块合理划分，也能够产生高质量的数据
一个遵循了数据规范的数据仓库图表示例，如下图所示
数据产出效率低
数据产出效率低，是有很多方面引起的问题，这里专门讲解下如何优化数据仓库性能
如何优化数据仓库性能
数据仓库性能可能常常面临的是两方面问题
- 计算任务性能差（一个任务计算8个小时，非常久）
- 计算资源消耗多（一个任务占用80%的CPU、内存）
那么下面举一些实际开发的样例，来说明优化方案
优化1：全量数据清洗优化
优化方案简介和效果：
优化前的SQL：
优化后的SQL：
每日增量数据+前一日全量数据=每日全量数据，通过这样的计算方式，可以避免以前的重复数据计算，增加数据清洗效率
优化2：全量数据多维度聚合优化
优化方案简介和效果：
优化前的SQL:
优化后的SQL：
uin是用户微信号的唯一id标识，因为用户微信号的数量相对有限，可以固定在十几亿左右，所以做一步中间聚合可以大大减少数据量，进而达到减少数据计算时间的目的
优化3：多表数据UNION优化
优化方案简介和效果：
优化前的SQL:
优化后的SQL：
每次取出数据时都会根据ds字段取出全部分区内容，如果分区被多次取出并且在同一个任务里面，那么比如这个分区的数量是10亿，取了8次就是80亿，进而会导致资源占用量急速增大，导致集群其他任务无法正常运行
优化4：多维度聚合步骤拆分
优化方案简介和效果：
优化前的SQL:
优化后的SQL：
当使用rollup进行多维度聚合时，FROM子句中包含子查询或者join时会导致重复计算的现象，进而降低数据产出效率
小结
数据仓库是为了更高效产出统计数据的工作，如果你对小美的好友数据好奇，不妨来了解了解数据仓库
本文由mdnice多平台发布
标签：小美,name,数据仓库,数据表,apply,分享,数据 来源： https://www.cnblogs.com/drawcode/p/16314637.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。