Appearance
21数仓：数据仓库的三种类型表
本课时我主要讲数据仓库，下一课时是用户研究。这两课时跟分析师会有一定挂钩，但不会特别紧密，这里我单独拿出来介绍。
本课时分为四部分内容：
数据研发工程师和数据分析师的关系；
App 日志采集中的埋点；
数据建模步骤及举例；
数据管理。
数据研发工程师和数据分析师的关系
在讲解数据研发工程师和数据分析师的关系之前，我们先看下整个大数据的体系，它包括这几部分内容：
日志的采集和传输；
数据建模；
数据管理；
数据应用。
日志采集和传输、数据建模、数据管理是一般的数据研发岗，也就是广义的数仓。作为一个分析师所言，高度要够，你一定要熟悉整个大数据体系架构，同时专于里面某个模块。当你对大数据团队里面每个岗位都有一定理解的时候，后面跟数据研发沟通时，效率会很高。
然后我们看下数据研发工程师和数据分析师之间的关系。
- 大公司：分工很明确，分析师有点"风险性"，研发工程师相对比较稳。
日志采集和传输、数据建模、数据管理都是对数据本身进行开发。大公司本身数据就需要做底层清洗，那要做的事情也非常具体，所以研发工程师的具体价值很清楚。而很多公司在考量分析师价值的时候就有点头痛，大多时候是看专题报告的质量和数量，看有哪些报告建议点落地了，而这确实是分析师的真正价值。其实大公司在这一块，有些落地事情很复杂，所以分析师岗位是有点风险性的。如果你真的没有把握好，可能真的是在做杂事，稳定性上不如研发工程师。
- 小公司：全部是数据研发工程师，分析师的活也干了，所以看似什么都懂，但不会很专。
小公司基本上全都是研发部门------所谓的 BI 工程师。他们把分析师的活也干了，从数据的采集到数据的应用都干了，看似什么都懂，但肯定不会很专，特别是在业务分析这一块不会很专。因为在前面日志采集、日志传输、数据建模时，特别耽误时间，可能过一段时间就出现一些小问题。
所以即使作为研发工程师，也要懂业务，否则你研发出来的产品真的没人用；即使作为分析师，也要懂研发，否则你的沟通效率、提数效率会比较低。
App 日志采集中的埋点
我举个例子------ App 日志采集中的埋点。日志的采集和传输里面具体的技术比较复杂，包括实时传输，批量传输。这里面有一个点就是埋点，埋点和分析师挂钩很大。
在埋点前中期。数据分析师进入一家公司时，一定要主动参与到埋点的讨论，不要把前后端研发想得多专业。如果埋点出问题了，会非常耽误业务的分析，很多研发纯粹凭感觉埋点，在这过程中一定要把埋点规范建立起来。
比如，一个 App 营销活动，研发和业务直接对，研发很多时候按照他们的理解来埋点。但是在分析的时候，分析师发现有一些点没有埋，或者说埋错了，这意味着又要重新进行一次埋点，或者导致这个活动很难分析出什么结论，浪费大家时间。
在埋点后期，就不要投入太多时间去想新的埋点，文档化即可，这样后面所有的人都可以参照文档。另外日志上报中的公参是分析师来定，也就是说有些参数是所有行为日志一定要有的。总结而言，埋点这件事一定是分析师牵头，虽然很烦琐，但非常重要。
数据建模步骤及举例
数据建模，首先就是为什么要建模？我们先以分析师的痛点来说。
日志量太大，跑数很慢：一个简单的 Join 都要半个小时才能出结果，而 SQL 又非常容易出错，从而就导致整个分析团队产出效率太低。
日志太乱，很多重要的数拿不出来：想算近一个月新增用户的订单量，如果没有好的数据建模，根本就跑不出来，从而就导致很多重要的思考点都无法落地，显得很不专业。
这是旧业务当中最常见的两个痛点，数据建模可以缓解这些痛点且有以下好处：
提高整体计算效率，减少重复开发；
历史数据追踪，中间表数据可以存储一年；
更好适应业务发展，修改影响范围较小；
清晰数据结构，分析师更加容易理解。
数据建模主要步骤及举例
数据建模可以分为三步，如下图所示。
像日常我们看到的报表其实都是上层数据的一个聚合和展示过程，那么这个过程究竟是怎么回事呢？这就涉及数据建模或者说数据仓库，一般是这样一个过程：
首先底层日志每天按照任务调度方式传输到 ODS 层，你可以把这个 ODS 理解为原始日志的一些初步加工，也就是经过了一些明显的不合理清洗，比如字段取值过滤。
ODS 下一层就是 DWS，这个是对底层日志进行用户粒度的聚合，所以怎么聚合非常体现专业力。
最后再到 DM 常规应用，常规应用也就是上层想看维度和指标的呈现。
ODS(Operational Data Store) 操作性数据：是作为数据库到数据仓库的一种过渡，ODS 的数据结构一般与数据来源保持一致，便于减少 ETL 的工作复杂性，而且 ODS 的数据周期一般比较短且最终流入 DWS。
DWS (Data Warehouse Store)数据仓库：是数据的归宿，这里保证所有从 ODS 到来的数据，并长期保存，而且这些数据不会被修改。这一层最重要，也是做数据同学的专业力体现，涉及各种表如何去聚合。
DMS(Data Mart Store) 数据集市：为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据，面向应用。
数据建模举例------头条
以头条为例，我们知道头条是做信息流的下发。
第一步：ODS
用户基础属性表：imei,prov,city,machine
用户文章下发表：imei,article_id,xiafa_time
用户文章点击表：imei,article_id,dianji_time
文章属性表：article_id,category_id,title
看过日志的同学都懂，一般一家公司的原始日志都是分为这些，其中用户基础属性表和文档属性表就是维度表，而对于用户文章下发表和用户文章点击表就是这种 ODS 类型。
第二步：DWS
在这一层，假设上述就是原始数据。在这个基础之上，DWS 就是做用户粒度文章明细表。比如我们会做如下两张表。
用户文章基础属性表：imei,prov,city,machine,article_id,category_id,title,xiafa_pv,dianji_pv,xiafa_time,dianji_time
用户分类基础属性表：
imei,prov,city,machine,category_id,xiafa_pv,dianji_pv
这样就可以通用于每个用户。
第三步：DM（业务应用表）
省市下发点击 PV 数：prov,city, xiafa_pv,dianji_pv
分类下发点击 PV 数：category_id,xiafa_pv,dianji_pv
在这个中间表 DWS 层的基础之上，就要看业务想看什么样的数据，然后针对性聚合就可以了，这就是 DM 层，也就是业务应用表。比如想要各个省市下发的点击 PV ，那就在上一层表上面聚合省份城市下发 PV、点击 PV。如果要 UV 的话，那也可以进行一次聚合。有些时候会涉及多张表 Join 之后的聚合，原理也一样。可以看出，基本上 DM 层都是确定的。主要是要和业务方聊，想业务方看什么数据即可，然后在此基础上去设计。
在做数仓这一块，我的感触就是不要搞得太复杂，很精细。一定要让业务倒逼，先把最核心的数据快速弄出来。之前遇到一个例子，有一个同学跟我说，他们公司当下要他们开发一套类似于大数据的平台，具体为什么要搞，管理层自己说的也不是特别清楚，当然这里面可能有一些其他因素。其实这很耽误时间，所以逐步迭代往往比大而全好得多。
如果你把时间投入到这一块，你肯定没有时间做分析师该做的事情------搞业务。在这个基础之上，最后你做出来的东西没人用怎么办？做出来之后，我相信也会存在一些问题，如果业务方就是不用怎么办，你还能逼着他们去用吗？所以在大数据平台这件事上一定要让业务倒逼。我之前就遇到过一个团队，就是这种情况。在这一块推倒重来，再推倒重来，这个团队也很快解散，这对个人成长以及对公司都没有任何贡献，所以在这件事情上一定要想好。
接下来我们看看，在数据建模的时候，分析师使用表时的注意事项。
不要过度相信研发的话：一定要自己动手试一次，比如用表计算一次日活。
不要去做研发做的事：调度异常、表大小、配置错误、UDF 函数、日志传输，这些东西非常耽误时间，对你做业务也没好处，可以提建议但不动手。
不要去等研发开发表：数仓对分析师而言最直接的好处就是快，而分析师的最终目的是有数据，所以目标不要搞错。
数据管理
在数据管理这一块，像存储、计算等很多时候跟分析师关系不大，那么我就重点说。
计算管理：Join 的时候要注意数据倾斜，选择哪张表很关键，对 MR 内部原理的掌握也很重要。
数据存储管理：核心的表尽量保存久一点（3 个月以上），非核心的表 1 个月内即可，分析师要对表的存储周期有概念，很多时候都要去看历史数据。
权限管理：分析师往往是管理员权限，所以不要随便给其他人开权限。你如果做好了没啥，一旦有问题就是大问题，所以采用最小可满足原则给权限就行，同时给读权限。
总结
埋点的重要性：主动性和文档化
数据建模的三层次：快速迭代
数据的管理：权限管理
今天的课程就到这里，你听完大概就知道整个大数据体系是怎么回事了。但是这里面有很多细节，且每一家公司又不太一样，如果大家感兴趣，可以看我之前推荐过一本书------《阿里巴巴大数据实战》。
如果你有什么疑问，可以在留言区留言。同时欢迎你关注我本人的公众号（微信搜索：数据分析学习之道），之后会定期更新原创高质量的数据分析文章，下节课见，谢谢。