2023/04/10 晚 教5

Author: dasenCoding

README.md

@@ -1,15 +1,70 @@
 # DevelopAction-DataWareHouse
 This project builds an offline data warehouse based on the 2020 Github annual logs provided by OpenDigger. 
 
+## pre.为什么想自己搭建数仓🦄
+在次之前，已经在B站学习过电商数仓项目，但是学完总感觉空落落的，感觉学了东西，又感觉没有学东西。
+很幸运的是学校与华师大X-Lab实验室有交集，并了解到了该实验室的开源项目OpenDigger，并且提供了2020年GitHub的全域开发者行为数据，虽然数据是已经被处理之后的，不是原汁原味的数据，但是通过观察发现该日志数据中一种行为的字段还包括了其他行为的字段，导致大量的空值。因此其实还有很大的空间能够来充分利用这些数据。
+
+目前来说，
+
+1. 自己也通过电商数仓了解到数仓的搭建和构造，并且也开始阅读William H.Inmon的《数据仓库》、跟着B站一些数据总监发布的数仓讲解进行学习。但是感觉数仓的建模以及搭建不像大数据的其他技术栈学习后就会使用，其本身需要不断地了解那种建模思想和实际应用才能从中不断地提取自己想要地内容，不断地进行优化，所以也很清楚距离自己能够真正搭建中规中矩的数仓还是有很长一段路需要走🐢。
+2. 另一方面，正好有亿级别地开发者行为数据。
+
+介于此，正好可以将自己学习地内容通过实践来进行一个提升，在实际构建地过程中思考🤯:
+1. 数仓建模地目的
+2. 如何梳理业务流程
+3. 为什么要进行数仓地建模
+4. 如何进行数仓的建模
+5. 之后如何进行优化？
+6. 数仓的扩展性如何？
+> 其实还有很多的问题，这些问题在之后的记录中不断地记录并解答，如果有新的问题，再标注进来同时做好问题的时序，防止重复地陷入某个问题中去。
+
+**🐂“纸上得来终觉浅，绝知此事要躬行”🐂**
+
+--------------------------------------------------------------------------------------------------------
+好了进入正题🎉：
+
 该 project 主要用来帮助自己更好的熟悉离线数据仓库的搭建过程，从数仓的业务梳理、建模到分层等各个环节。
 
 提交的大部分内容可能包含了一些笔记、图片或者一些代码片段，记录了自己从0搭建的整个过程。
 
-一定会存在问题或者漏洞，假如作为更加了解数仓各个环节的你能为我提出一些建议和改进的方法，我会倍感荣幸和兴奋！
+一定会存在问题或者漏洞，假如作为更加了解数仓各个环节的你能为我提出一些建议和改进的方法，我会倍感荣幸和兴奋！😆🤩
 
 --------------------------------------------------------------------------------------------------------
 ## 1 前期准备
 
 自己电脑的配置无法处理亿条数据，目前准备使用阿里云/华为云，租赁3台服务器，用来作为集群，同时将opendigger中公开的2020开发者全域数据从clickhouse中导入到集群中，这部分的配置过程以及注意事项会保存在 /cluster-service中。
 
-> 介于长时间租赁高性能的服务器比较昂贵，这里先进行规划，等准备完成后，直接拼接各个部分从服务器的租赁到集群搭建再到数据的导入一起完成。
+> 介于长时间租赁高性能的服务器比较昂贵😥，这里先进行规划，等准备完成后，直接拼接各个部分从服务器的租赁到集群搭建再到数据的导入一起完成。
+> 
+--------------------------------------------------------------------------------------------------------
+
+## 2 数仓搭建前的一些思考
+
+👉 思考1
+
+在构建数仓之初，个人感觉最重要的是能够清楚的知道构建数仓的目的。目前自己的知识认知认为数仓的最终目的之一是进行数据服务，帮助领导进行决策，在这里来讲就是我搭建的数仓是否能够为我提供数据服务。说白了就是：假如我从ods层直接提出数据进行目标的分析处理的效果比从数仓产出的数据分析的结果要好，那我费劲的做这个数仓干什么？毫无用途，浪费精力。类比到实际应用中，假如领导直接取ods层的数据进行分析，不需要数仓产出的数据为他服务，那还要数仓干啥🥶。
+
+所以数仓的目的之一就是具备强大的数据服务能力。
+
+👉 思考2
+
+另外一个方面，数仓的是对现存的数据进行有效的分类组织和存储，避免重复建设以及数据的不一致性。
+
+举个例子：GitHub中存在成千上万的仓库，几乎每个具备一定规模的仓库下都会有开发者提出的 issue 与 pr，这些 issue 需要仓库管理者或者其他开发者来进行解答，pr 需要仓库的代码 review 进行代码的审查。审查通过的代码予以通过，最终合并到主分支中。
+
+假如仓库的持有者，关心自己仓库下这些内容：
+1. issue 的平均解决事件/
+2. issue 提出后的响应速率/
+3. 常驻的开发者有哪些？
+4. 核心开发者的留存情况如何？
+5. pr 的解决周期的长短？
+6. pr 废弃的比率
+
+等等一些关于GitHub仓库的问题，上面的几个问题中明显有3类主题维度，但是在日志数据中其中一个维度的数据记录中还包括了另外两个维度的字段，假如我要获取 issue 的所有信息，需要进行筛选、处理空值、处理 issue 和开发者/pr交叉的信息（这里指的是pr中的comment可能会引用某个issue）。这样一来，每次处理的时候都需要进行同样的操作，重复工作太多意味着重复的查询很多。
+
+这次使用的数据有大概8亿条数据，不同于之前很少的数据，当数据量很大的时候进行过多的重复查询毫无意义同时增加集群的负担，所以这里能体会到数仓要解决的其中一个问题就是进行解耦，多次同样的查询数据可以抽取作为某一层的数据，当使用的时候直接获取。
+
+> 🤓上面是目前的一些思考，思考会不全面，同时也有局限性，因为自己每天在看很多内容，可能思考的思路会有对错，这里遇到了就记录一下，日后等数仓基本完成了再进行一下整理。(ps:2023/04/10晚上 教5)
+
+## 3 开发者行为日志业务流程分析梳理