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