既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
- 为了解耦合、分布执行、降低出问题的风险。
- 用空间换时间用多步换取最终使用的数据的高效性。
- 指标或者报表出问题了，可以快速的进行溯源。
分层更多的是一个逻辑上的概念。
分域： 分为主题域和数据域。主题域与数据域严格意义上并没有标准划分。主题域一般是面向分析用的，主题域通常是联 系较为紧密的数据主题的集合， 比如财务主题域、人力主题域、供应链 主题域等。数据域一般指的是一组/ 一串/ 一类业务活动单元的集合， 如日志、交易等。
分类： 严格意义上来说其不属于数据仓库常见的一个概念，其更多的是对应用系统的数据进行一个分类。我们知道数据仓库的上游基本上都来自于业务数据库、日志的信息、爬虫或者其他的第三方的数据。针对这些数据我们需要进行分类。只有分类才能更好的管理与使用，所以我们一般为了更好的管理数据， 会把数据划分为主数据、交易数据、参考数据、元数据等。业务系统数据的一个划分。
维度： 由独立不重叠的数据元素组成的数据集， 所构成的可进行统计的对象。常见的如人、产品、地点。维度通俗来说就是我们观察某一事物的一个角度。
事实： 描述业务过程的度量(最小单体)。
粒度： 事实表中一条记录所表达的业务细节程度。
维度与事务的区分，比如说在sql中，如果能够使用where条件判断的话，那么其就是一个维度。
2. 拓展
业务过程： 业务过程代表一个被管理实体或系统的事实， 是对业务活动 单元/ 事件的定义。常见的如下单、支付。基本上把它划分为最小的一个单元体。
原子指标： 原子指标一般情况下划分为基础指标(原子指标)、复合指标、派生(衍生)指标等等，不同公司会稍有不同。原子指标是对业务事实中度量的统计定义， 与SQL中select内容等价。常见的如支付金额、买家数。
业务限定 ： 业务限定是对业务中圈选的统计范围的定义， 与SQL中where条件等价。常见的如商品品类、已支付。
派生指标： 派生指标即常规的统计指标， 通过原子指标与各种业务限定的组合而生成。如最近一天或者最近一个月买家支付金额。
汇总逻辑表： 描述维度统计信息（ 即派生指标） 及维度属性信息的数据 集合集， 所构成的数据仓库模型。
三、数据仓库建设步骤
1.建设步骤
- 需求调研
数据仓库与业务关系是较为紧密的。一个数仓项目的成败，很大程度上取决于你对整个公司的了解程度。比如说刚刚对各个主题域的划分。如果说你对你们公司的整体的业务都不熟悉，怎么进行划分。如果对业务不熟，你是构建不出来的。 - 数据调研
首先我们需要对整个的业务流程有所了解，业务流程是通过怎样的系统承接下来的。在承接的过程中，我们的数据他是什么样的结构，数据量是多少，数据质量如何等等，这些都是我们需要去了解的。 - 构建总线矩阵
总线矩阵个人认为更多的是为了帮助我们更好的统一规划数据仓库，也是为了更加的标准化。关于总线矩阵是怎么划分的？下面简单的说下，通常为一行代表业务过程。每一列是一个维度。在数仓建设的过程中，对一次性维度、一次性事实是有要求的。前面说过，在整个数仓的过程中，我们需要统一整个公司的数据的指标的口径，包括数据的一些认知等等，所以需要构建数据的总线矩阵。 - 构建CRUD矩阵
我们需要对每一个实体的创建、更新、删除等。比如说在整数仓中，我们选择一个维度，一般面临两个步骤：选择主维表和进行维度的主键的设计。在我们选择主维表的时候，如果你连这个维度在哪个系统创建的，在哪个系统更新的，在哪个系统删除的都不知道的话，如果出现这种情况是不太好的，所以我们需要构建CRUD矩阵。
2. 数仓规划(以下表为例)
数仓的上游统一的称之为数据源。统一生成数据源后，我们会把整个公司的业务进行划分。
比如说对业务线，业务板块进行划分，每一个业务线下可能会有很多业务板块。每个业务板块下面又有许多数据域。
每个数据域下面我们也会进行划分，比如说维度和业务过程。
维度我们设计成维度逻辑表，就是我们刚才所说的，你需要考虑以下三点，一个点就是你的主维表，第二个点就是你的维度的主键的设计，第三个点就是维度属性的选择。我们在做维度逻辑表的时候，我们建议尽量把我们的维度属性设计的丰富一点，因为现在的业务变化有点快，丰富一点对于整个数仓的稳定性和健壮性都是有好处的。
划分业务过程形成事实上的逻辑表，事实逻辑表包括事务性的事实，快照性的事实。更细的划分暂时就不进行细讲了。在此大家知道有这样一个概念就可以了。划分完成过后会形成整个公司的逻辑，包括维度逻辑这样一个表，会形成我们所说的DWD(数仓明细表)。
然后进行一个汇总，汇总我们更多的是根据派生指标包括像时间周期来进行一个指标的汇总，以此来形成汇总逻辑表。
3.数据仓库分层划分
根据上图可以看到数仓一般分为三层。第一层为ods层，我们通常把其叫做原始数据层，或者叫做操作数据层。第二层为中间层，第三层我们面向推荐系统、报表、数据分析等等，划分为ads层。整个数据仓库最重要的设计是中间层的设计，即是从明细层->dws层(数据汇总层)这一块的设计。
具体的分层要根据公司的实际需要来进行分层。
每层的作用：
ods层：在此层中不建议进行太多的数据清洗、转换。只需要把业务系统中的数据，日志数据等等原汁原味的采集同步过来即可。
- 这样做的好处：
①降低对业务系统的入侵，减少业务系统的压力。
②如果指标出错，ods层数据被改掉的话，只能从业务数据库或者日志数据库查找数据，这样是不利于我们进行血缘追溯和出错排查的。
因此所有的操作我们可以放在ods到dwd时进行，包括我们常见的维度退化、过滤、缺省值处理，按照业务过程进行拆分，冗余一些属性。
还可以把事实的粒度降低。
ads层响应整个推荐，包括报表等等响应应用。我们要把更多的一个逻辑划层放在中间层去做。可以保证整个公司的稳定性。
dim层是一个维度的层，维度层是可以各层级调用的，我们可以把部分的维度下沉或者冗余到其他层里面。
在做数仓的时候，我们要尽量减少Join，因为它不利于数据的处理。
数仓遵循的原则：不允许跨层调用，跨层出数。比如说在数据建模之后，我们需要对模型进行考评，模型建立的好不好，有一个指标就是看你跨层的调用率，包括你跨层出数的比率。如果上层应用、基本数据都来自于ads层，少部分来自于dws层，那么相对而言这个数仓的建设是比较不错的。
四、问题与思考
1. 维表的主键选择
自然键（NaturalKey），它是业务系统中已经存在的，通常是具有一定业务含义的一个字符型的标志符，可以唯一地标志维度表中的每一条记录。比如机构的代码、缩写、时间标签等。
另一种是代理键（SurrogateKey），通常是数据库系统赋予的一个数值，是自增型的，按顺序分配，没有内置含义但也可以唯一地标识一条维度信息。
项目经验，推荐采用第二种，即代理键。原因如下：
首先，自然键虽然在逻辑上可以唯一地标识出一条维度信息，但它通常是字符型的，且一般比较长，若用它作为维度表中的主键，那就意味着在事实表中也要加入同样的外键信息，而事实表记录行数往往是巨大的，在多个维度表上重复这样的做法会使事实表由于列宽过于膨胀而导致性能的急剧下降。
其次，代理键可以作为数据仓库与源系统之间的“缓冲”。自然键通常具有一定的业务含义，但日久天长，这些信息是有可能发生变化的，比如身份证号码，由最初的15位变成了现在的18位。如果这种主键一旦发生了变化，由于它同时作为事实表中的外键，必然会对事实表产生影响，因为已有的事实记录已经找不到与之匹配的维度记录，这就带来了很大的麻烦。但若采用代理键作为维度表中的主键，就完全可以把这些变化屏蔽在维度表内，不会对事实表产生任何影响（当然这个还要结合缓慢变化维度的处理）。
最后，从关联效率考虑，数值型的关联要比字符型的关联快很多。
2. 缓慢变化维(SCD)
- 维度保持不变；
- 直接进行维度的替换。如果发生变化，直接采用最新的，但是使用此方法想看到历史是什么样子就看不到了；
- 增加维度行或者维度列，此方法并不是太好。
以纬度行举例：增加纬度行以后，想把某一个事实全部关联成一个维度，这是非常难去处理的，所以其对处理这一块是不好的。
以维度列举例：增加维度列以后，确实是可以解决看历史看现在的问题。但是如果没变化一次就加一列的话，最终会导致表不利于维护，除此之外也不利于后续的数据分析。 - 使用拉链表，不过我们在使用拉链表的时候是需要进行细节考虑的。
- 维度快照，个人认为更方面处理各种情况。我们可以提前生成一个维度快照，等到查看的时候只需通过不同的快照去查就可以了，但是这样做的话，会增加我们的存储，会产生一定的浪费。
个人认为拉链表与维度快照是解决缓慢变化维比较好的方法。
3. 主数据与oneID的关系？
如果是传统型公司的话，可能会有这样一个问题。他们大都可能有这样一个问题：我们的主数据与oneID有什么样的一个关系?我们在建设数仓或者数据中台的时候，要不要先上一个主数据的系统呢？大概就是这样一个问题，如果遇到这种问题，我们应该如何回答呢？
说了oneID，我们就不得不说onedata。现在的数据中台很多都是基于onedata理论构建的。下图为onedata方法论。
OneData体系是阿里数据中台的核心方法论，其包含了三个方面内容：OneModel 即建立企业统一的数据公共层，从设计、开发、部署和使用上保障了数据口径规范和统一，实现数据资产全链路管理，提供标准数据输出。OneID 即建立业务实体要素资产化为核心，实现全域链接、标签萃取、立体画像，其数据服务理念根植于心，强调业务模式。OneService 即数据被整合和计算好之后，需要提供给产品和应用进行数据消费，为了更好的性能和体验，需要构建数据服务层，通过统一的接口服务化方式对外提供数据服务。
由于问题为主数据与oneID的关系。所以此部分简单介绍oneID。
在阿里巴巴数据中台官方宣传资料中，我们看到这样的定义：“OneID是以商业要素资产化为核心，实现全域链接、标签萃取、立体画像，数据应用服务整体解决方案。”这里的商业要素就是消费者、企业、内容、商品、位置等核心业务实体数据，传统上我们称其为主数据。而OneID也叫数据萃取中心，就是通过标签技术、知识图谱技术、画像技术在虚拟的网络世界实现商业要素（主数据）的唯一身份识别，保证企业核心数据的身份唯一性、一致性、完整性、相关性和准确性。所以，OneID可以理解为主数据管理，只是用的技术更先进些罢了。
个人认为：“阿里数据中台的OneID，本质上就是企业主数据管理”。但我相信一定也有人反对这个观点，因为在现行的主数据管理方案中，总体上还是趋于用标准、制度、流程、集成技术等手段解决主数据的问题，标签体系、知识图谱、画像技术、混合云技术等先进的技术目前还没有大规模用在主数据管理领域，但是我相信这终将是主数据发展的趋势！技术推动社会发展，主数据管理又岂能固步自封！
4. 如何进行模型调优？
我们知道数据仓库核心的是业务，那么业务又是怎么通过数仓来体现的，其核心是模型。那么模型如何进行调优和优化就是一个比较重要的问题。
在进行模型调优之前，我们需要先判断数据模型的好坏。具体步骤如下：
①完善度
- 汇总数据能直接满足多少查询需求，即应用层访问汇总层数据的查询比例
- 跨层引用率：ODS 层直接被 DWS/ADS/DM 层引用的表，占所有 ODS 层表比例
- 可以快速响应业务方的需求
比较好的模型，使用方是可以直接从该模型获取所有想要的数据的，如果dws，ads，dm层直接引用ods层的表比例太大，即跨层引用率太高，则该模型不是最优，可以继续优化
②复用度
- 模型引用系数：模型被读取并产出下游模型的平均数量
③规范度
- 主题域归属
- 分层信息
- 脚本及任务命名规范
- 表命名符合规范(清晰、一致，见名知意)
- 字段命名是依赖于词根
④稳定性
- 能否保证日常的sla（时效保障）
⑤扩展性
- 新增加的模型是否和老的模型出现冲突
⑥准确性&一致性
- 输出的指标数据质量能够保证
⑦健壮性
- 业务快速更新迭代的情况下不会太影响底层模型
⑧低成本
- 计算时间成本
- 计算资源成本
- 存储成本
⑨总结
- 完善度，复用度，规范度基本上是需要了解业务，然后根据元数据信息去做统计分析的
- 稳定性，低成本是需要对任务进行优化，比如sql调优等
- 准确性和一致性是需要一套质量管理系统及指标一致性管理方案的，包括数据源，口径和指标管理平台等。
知道判断模型的方法后，下面就可以针对这些方面进行调优。比如说我们创建维表的时候，选择主维表时，要尽量丰富我们的维度属性。我们在做维度设计的时候，一般情况下我们还会进行维表的整合与差分。这样做是为了让模型更加稳定。
五. 对数据仓库的思考
虽然数仓建设能带来诸多的益处，但其是一个庞大复杂耗时的工程，需要一些支持系统的配合，比如说元数据管理系统、调度系统等，而且也并不是所有的业务一开始都要建设数仓，要根据业务发展所处的状态和未来的发展趋势以及分析决策的复杂性等综合评判。
大数据系统，其复杂度之高，是几乎不可能在一开始就完整和完美地进行自上而下定义和设计的，其设计过程必然遵守从需求->设计->迭代->理论的过程。大数据的真正价值在于生命性和生态型，其价值是随着使用场景和方式动态变化的。
数据仓库的业务意义，在于从底层的数据采集、数据处理，到挖掘算法、数据应用服务以及数据产品的全链路、标准化的大数据体系。通过这个体系，超过EB级别的海量数据能够高效融合，并以秒级的响应速度，服务并驱动自身的业务和外部千万用户的发展。
数据仓库的技术意义，在于规避重复建设，统一计算口径，有效降低成本，提升开发效率。
文章内容到这里就结束了，如有不足请指出~
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
片转存中…(img-RuCgghuT-1715463247318)]
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
1028
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
