first commit

数据仓库/DBA/数仓几种表.md

@@ -0,0 +1,8 @@
+### 全量表
+有无变化都要上报，只有一个分区或者没有分区，每次往全量表里面写数据都会覆盖之前的数据，不能记录数据的历史变化，只能截止到当前最新、全量的数据
+### 增量表
+每天新增的数据和改变的数据都会存储在当日的分区中；增量表记录每次增加的量，只报变化量，无变化的不用报
+### 快照表
+因为全量表无法反映历史的变化，这时快照表就可以使用了，快照表记录截止数据日期的全量数据（每个分区都是记录截止当前分区日期的全量数据），但是在数据量大的情况下，每个分区存储的都是全量数据，数据冗余和浪费存储空间
+### 拉链表
+记录了数据的增删改操作，并按照时间顺序存储。拉链表通常用于日志数据仓库或实时数据仓库，可以记录数据的完整操作历史

数据仓库/业务数据表.md

@@ -0,0 +1,9 @@
+### 业务数据表基础信息描述
+#### 元信息
+
+| 表名                        | 行数      | Hive(DataWorks)中大小 | 记录日期       |
+| ------------------------- | ------- | ------------------ | ---------- |
+| meiqia.knowledge_question | 1053290 | 19.36 MB           | 2024-05-29 |
+| meiqia.knowledge_category | 31274   | 582.07KB           | 2024-05-29 |
+| meiqia.enterprise         | 304141  | 12.88 MB           | 2024-05-29 |
+| meiqia.agent              | 701454  | 65.90 MB           | 2024-05-29 |

数据仓库/数仓分层.md

@@ -0,0 +1,84 @@
+### 数仓分层目的
+分层的主要原因是在管理数据的时候，能对数据有一个更加清晰的掌控，详细来讲，主要有下面几个原因：
+•	清晰数据结构：每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
+•	方便数据血缘追踪：简单来说，最终给业务呈现的是一个能直接使用业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。
+•	减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
+•	把复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
+•	屏蔽原始数据的异常：屏蔽业务的影响，不必改一次业务就需要重新接入数据
+
+### STAGE-数据接入层
+业务源系统数据映射到此层，此层数据不做任何加工，通常用来将不同数据源建Hive外部表，方便使用Hive SQL进行ETL处理。
+主要有以下外部表：
+•	HBase：从kafka消费的数据，以准实时的方式写入HBase，后续以更新时间做增量的方式导入到ODS表
+•	Elasticsearch
+•	MongoDB
+•	HDFS
+
+### ODS-数据准备层
+Operational Data Store，操作数据层。
+在结构上与业务系统的增量或者全量数据基本保持 一致。
+它相当于一个数据准备区，同时又承担着基础数据的记录以及历史变化。其主要作用是把基础数据以增量、全量、实时的方式引入到数仓，为DWD层提供基础原始数据，可减少与业务系统的耦合，避免互相影响。
+建模方式及原则：
+从业务系统增量（全量、实时）抽取、保留时间由业务需求决定、可分表进行周期存储、数据不做清洗转换与业务系统数据模型保持一致、按主题（业务系统）逻辑划分。
+ODS层数据源：
+•	业务数据库
+经常会使用sqoop来抽取MySQL数据，比如每天定时抽取一次。
+在实时方面， 用canal监听MySQL的binlog，实时接入即可。
+•	埋点日志
+线上系统会打入各种日志，这些日志一般以文件的形式保存，可以选择用flume（filebeat）定时抽取，再用Spark Streaming或者Flink来实时接入，当然，需要kafka承担消息管道的职责。
+•	消息队列
+来自ActiveMQ、Kafka的数据等。
+
+### DW-数据仓库
+Data Warehouse，数据仓库。
+从ODS层中获得的数据按照主题建立各种数据模型。DW数据分层，由下到上为 DWD，DWB，DWS
+在DW主要关注四个概念：
+•	维度（Dimension）
+•	事实（Fact）
+•	指标（Index）
+•	粒度（ Granularity）
+
+### DWD-明细数据层
+Data Warehouse Detail，明细数据层。
+是业务层与数据仓库的隔离层，为DW层提供来源明细数据，提供业务系统细节数据的长期沉淀，为未来分析类需求的扩展提供历史数据支撑。
+建模方式及原则：
+数据模型与ODS层一致，不做清洗转换处理、为支持数据重跑可额外增加数据业务日期字段、可按年月日进行分表、用增量ODS层数据和前一天DWD相关表进行merge处理
+
+### DWB-基础数据层
+Data Warehouse Base，基础数据层。
+存储的是客观数据，一般用作中间层，可以认为是大量指标的数据层。
+DWB是根据DWD明细数据进行转换，如维度转代理键、身份证清洗、会员注册来源清晰、字段合并、空值处理、脏数据处理、IP清晰转换、账号余额清洗、资金来源清洗等。
+建模方式及原则：
+•	聚合、汇总增加派生（衍生）事实
+•	关联其它主题的事实表，DW层可能会跨主题域
+•	DWB保持低粒度汇总加工数据，DWS保持高粒度汇总数据
+•	数据模型可能采用反范式设计，合并信息等
+
+### DWS-汇总数据层
+Data Warehouse Summary，汇总数据层。
+基于DWB上的基础数据，整合汇总成分析某一个主题域的服务数据，一般是宽表。
+DWS是根据DWB层数据按各个维度ID进行高粒度汇总聚合，如按交易来源，交易类型进行汇合。
+建模方式及原则：同DWB
+
+### ADS-应用数据层
+Application Data Service，应用数据层。
+根据DW层经过聚合汇总统计后的粗粒度事实表。
+该层主要是提供数据产品和数据分析使用的数据，面向用户应用和分析需求，包括前端报表、分析图表、KPI、仪表盘、OLAP、ROLAP、MOLAP、专题等分析，面向最终结果用户。
+一般会存放在ES、MySQL、HBase、MongoDB等系统中供线上系统使用，也可能会存在Hive或者Druid中供数据分析和数据挖掘使用。
+例如：报表数据，或者说那种大宽表，一般就放在这里。
+建模方式及原则：
+•	保持数据量小
+•	维度建模，星形模型
+•	各维度代理键+度量
+•	增加数据业务日期字段，支持数据重跑
+•	不分表存储
+
+### DM-数据集市
+Data Market，数据集市层。
+可以是一些宽表，是根据DW层数据按照各种维度或多种维度组合把需要查询的一些事实字段进行汇总统计并作为单独的列进行存储。
+满足一些特定查询、数据挖掘应用。
+应用集市数据存储。
+建模方式及原则：
+•	尽量减少数据访问时计算(优化检索)
+•	维度建模，星型模型
+•	分表存储

数据仓库/数据开发相关概念/数据分析基建：从数据库到湖仓一体.md

@@ -0,0 +1,17 @@
+## 数据库
+
+
+## 数据仓库
+
+
+### 离线数仓
+
+
+### 实时数仓
+
+
+## 数据湖
+
+
+## 湖仓一体
+