kyugao/obsidian_vault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

new

Browse Source
This commit is contained in:
AdamGao
2025-12-27 11:44:50 +08:00
commit ccd43fac1f
1193 changed files with 384161 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
settings/archived/work/2021/数据仓库/DW数据模型定义/业务信息域.md
+36
View File
@@ -0,0 +1,36 @@
主要保存公司内部外部业务系统。
**现有业务**
```plantuml
!theme sketchy-outline
package "社区服务平台" {
[智慧小区]
[网格管理业务]
}
package "保险" {
[医疗责任]
[校园责任]
[小区责任]
}
```
**数据模型**
```plantuml
!theme minty
package 公司业务信息域 {
class Service<服务信息> {
string service_id
string name
string code
string provider_corp_id
}
class ServiceUserMapping<系统用户关系映射> {
string person_id
string user_id
string service_id
datatime register_date
}
}
Service ||--o{ ServiceUserMapping
Person ||--o{ ServiceUserMapping
```
settings/archived/work/2021/数据仓库/DW数据模型定义/人员基本信息域.md
+58
View File
@@ -0,0 +1,58 @@
```plantuml
!theme sketchy-outline
package 人员基本信息域 {
class Person<人员基本信息>{
string name
string given_name
string family_name
string person_id
string license_type
string license_no
string gender_code
date birthday
}
class ContactPerson<联系人> {
string person_id
string contact_person_id
string relationship_code{关系}
}
enum ContactType {
Mobile
Phone
Email
Address
}
class Phone<电话> {
string provider
string number
}
class ContactMethod<联系方式> {
string contact_type_code
string contact_value
}
class Mobile<联系电话> {
string provider
string number
}
class Email<电子邮箱> {
string person_id
string address
}
class Address<地址> {
string address_id
string country_id
string province_code
string city_code
string district_code
string address
}
}
Mobile }-- ContactMethod : 包含
Address }-- ContactMethod : 包含
Email }-- ContactMethod : 包含
Phone }-- ContactMethod : 包含
ContactMethod }o--|| Person : 拥有
License }o--|| Person : 拥有
ContactPerson }o--|| Person : 属于
```
settings/archived/work/2021/数据仓库/DW数据模型定义/字典数据定义.md
+154
View File
@@ -0,0 +1,154 @@
---
number headings: auto, first-level 3, max 6, 1.1
---
### 1 字典表结构ER
```mermaid
erDiagram
Dict {
string id
string type
string code
string name
string level
string value
string description
string category_dict_id
string standard_dict_id
string base_dict_id
string parent_dict_id
boolean idc_base
}
```
### 2 字典表字典说明
**字段说明**
| 字段 | 类型 | 备注 |
|:---------------- |:-------:|:-------------------------------------------- |
| id | string | 唯一标识 |
| type | string | 记录类型, [standard \| category \| dict] |
| code | string | 字典编码 |
| name | string | 字典中文名 |
| level | string | 字典内级别 |
| value | string | 字典值 |
| description | string | 字典描述 |
| category_dict_id | string | 字典组标识 |
| standard_dict_id | string | 标准标识 |
| base_dict_id | string | 外部字典使用，基准ID关联，用于字典映射转换。 |
| parent_dict_id | string | 父级字典ID |
| idc_base | boolean | 系统基准字典标识 |
## 2 初始数据定义
### 3 基准标准(base_standard)
| 字段 | 类型 | 取值 | 备注 |
|:---------------- |:-------:| -------------:|:---------------------------------------------------------- |
| id | string | 1 | 唯一标识 |
| type | string | standard | 记录类型, [standard \| category \| dict] |
| code | string | base_standard | 字典编码 |
| name | string | BASE基准标准 | 字典中文名 |
| level | string | NULL | 字典内级别，标准不适用 |
| value | string | NULL | 字典值，标准不适用 |
| description | string | 平台基准标准 | 字典描述 |
| category_dict_id | string | NULL | 字典组标识，标准类型不适用 |
| standard_dict_id | string | NULL | 标准标识，标准类型不适用 |
| base_dict_id | string | NULL | 外部字典使用，基准ID关联，用于字典映射转换，标准类型不适用 |
| parent_dict_id | string | NULL | 父级字典ID，，标准不适用 |
| idc_base | boolean | true | 系统基准字典标识 |
### 4 基准字典组
#### 4.1 性别分组(base_gender_category)
| 字段 | 类型 | 取值 | 备注 |
|:---------------- |:-------:| --------------------:|:----------------------------------------------- |
| type | string | category | 记录类型 |
| code | string | base_gender_category | 平台标准性别 |
| name | string | 平台标准性别 | 字典名称 |
| level | string | NULL | 字典内级别，分组不适用 |
| value | string | NULL | 字典值，分组不适用 |
| description | string | CYY平台基准性别标准 | 字典描述 |
| category_dict_id | string | NULL | 字典组标识 |
| standard_dict_id | string | 1 | 表示属于base_standard表示这个分组是系统内部标准 |
| base_dict_id | string | NULL | 基准ID关联，内部字典不适用 |
| parent_dict_id | string | NULL | 父级字典ID，分组不适用 |
| idc_base | boolean | true | 内部标准字典标记 |
#### 4.2 政区分组(base_district_category)
| 字段 | 类型 | 取值 | 备注 |
|:---------------- |:-------:| ----------------------:|:----------------------------------------------- |
| type | string | category | 记录类型 |
| code | string | base_district_category | 平台标准性别 |
| name | string | 平台标准政区 | 字典名称 |
| level | string | NULL | 字典内级别，分组不适用 |
| value | string | NULL | 字典值，分组不适用 |
| description | string | 平台标准政区分组 | 字典描述 |
| category_dict_id | string | NULL | 字典组标识 |
| standard_dict_id | string | 1 | 表示属于base_standard表示这个分组是系统内部标准 |
| base_dict_id | string | NULL | 基准ID关联，内部字典不适用 |
| parent_dict_id | string | NULL | 父级字典ID，分组不适用 |
| idc_base | boolean | true | 内部标准字典标记 |
#### 4.3 证件类型(base_license_type_category)
| 字段 | 类型 | 取值 | 备注 |
|:---------------- |:-------:| --------------------------:|:----------------------------------------------- |
| type | string | category | 记录类型 |
| code | string | base_license_type_category | 证件类型 |
| name | string | 证件类型 | 字典名称 |
| level | string | NULL | 字典内级别，分组不适用 |
| value | string | NULL | 字典值，分组不适用 |
| description | string | 证件类型 | 字典描述 |
| category_dict_id | string | NULL | 字典组标识 |
| standard_dict_id | string | 1 | 表示属于base_standard表示这个分组是系统内部标准 |
| base_dict_id | string | NULL | 基准ID关联，内部字典不适用 |
| parent_dict_id | string | NULL | 父级字典ID，分组不适用 |
| idc_base | boolean | true | 内部标准字典标记 |
#### 4.4 汽车品牌(base_vehicle_brand_category)
| 字段 | 类型 | 取值 | 备注 |
|:---------------- |:-------:| ---------------------------:|:----------------------------------------------- |
| type | string | category | 记录类型 |
| code | string | base_vehicle_brand_category | 平台标准汽车品牌 |
| name | string | 汽车品牌字典 | 字典名称 |
| level | string | NULL | 字典内级别，分组不适用 |
| value | string | NULL | 字典值，分组不适用 |
| description | string | 汽车品牌字典 | 字典描述 |
| category_dict_id | string | NULL | 字典组标识 |
| standard_dict_id | string | 1 | 表示属于base_standard表示这个分组是系统内部标准 |
| base_dict_id | string | NULL | 基准ID关联，内部字典不适用 |
| parent_dict_id | string | NULL | 父级字典ID，分组不适用 |
| idc_base | boolean | true | 内部标准字典标记 |
#### 4.5 机构类型(base_corporation_category)
| 字段 | 类型 | 取值 | 备注 |
|:---------------- |:-------:| -------------------------:|:----------------------------------------------- |
| type | string | category | 记录类型 |
| code | string | base_corporation_category | 机构类型 |
| name | string | 机构类型 | 字典名称 |
| level | string | NULL | 字典内级别，分组不适用 |
| value | string | NULL | 字典值，分组不适用 |
| description | string | 机构类型 | 字典描述 |
| category_dict_id | string | NULL | 字典组标识 |
| standard_dict_id | string | 1 | 表示属于base_standard表示这个分组是系统内部标准 |
| base_dict_id | string | NULL | 基准ID关联，内部字典不适用 |
| parent_dict_id | string | NULL | 父级字典ID，分组不适用 |
| idc_base | boolean | true | 内部标准字典标记 |
#### 4.6 小区业务(base_community_business_category)
| 字段 | 类型 | 取值 | 备注 |
|:---------------- |:-------:| --------------------------------:|:----------------------------------------------- |
| type | string | category | 记录类型 |
| code | string | base_community_business_category | 小区业务 |
| name | string | 小区业务 | 字典名称 |
| level | string | NULL | 字典内级别，分组不适用 |
| value | string | NULL | 字典值，分组不适用 |
| description | string | 小区业务 | 字典描述 |
| category_dict_id | string | NULL | 字典组标识 |
| standard_dict_id | string | 1 | 表示属于base_standard表示这个分组是系统内部标准 |
| base_dict_id | string | NULL | 基准ID关联，内部字典不适用 |
| parent_dict_id | string | NULL | 父级字典ID，分组不适用 |
| idc_base | boolean | true | 内部标准字典标记 |
settings/archived/work/2021/数据仓库/DW数据模型定义/小区信息域.md
+12
View File
@@ -0,0 +1,12 @@
```plantuml
!theme sketchy-outline
package 小区信息域 {
class Community {
string community_id
string province_code
string city_code
string district_code
string address
}
}
```
settings/archived/work/2021/数据仓库/DW数据模型定义/机构信息域.md
+14
View File
@@ -0,0 +1,14 @@
```plantuml
!theme sketchy-outline
package 组织机构信息域 {
class Corporation {
string license_number
string corporation_id
string name
string province_code
string city_code
string district_code
string address
}
}
```
settings/archived/work/2021/数据仓库/DW数据模型定义/证件信息域.md
+22
View File
@@ -0,0 +1,22 @@
```plantuml
!theme sketchy-outline
package 证件信息域 {
enum LicenseType<证件类型字典> {
IdCard 人员证件/身份证
Passport 人员证件/护照
Driver 人员证件/驾照
SecurityCard 人员证件/社保卡
VehicleLicense 车辆证件/行驶证
HouseLicense 房产/房产证
BusinessLicense 企业/营业执照
}
class License<证件> {
string license_id
string license_type
string license_no
date valid_since_date
date valid_due_date
string issuer
}
}
```
settings/archived/work/2021/数据仓库/DW数据模型定义/资产信息域.md
+30
View File
@@ -0,0 +1,30 @@
```plantuml
!theme sketchy-outline
package 资产信息域 {
class Vehicle {
string vehicle_id
string vehicle_brand_code
string license_no
datetime register_date
}
Vehicle ||--|| License : has
class House {
string house_id
string community_id
string province_code
string city_code
string district_code
string address
}
House ||--|| License : has
class ParkSpot {
string park_spot_id
string community_id
string code
}
ParkSpot ||--|| License : has
}
Vehicle ||--o{ AssetRecord : has
House ||--o{ AssetRecord : has
ParkSpot ||--o{ AssetRecord : has
```
settings/archived/work/2021/数据仓库/DW数据模型定义/资产所有权变更信息域.md
+27
View File
@@ -0,0 +1,27 @@
```plantuml
!theme sketchy-outline
enum AssetType_Dict<资产类型> {
Vehicle 车
House 房
ParkSpot 车位
}
enum AssetOwnStatus_Dict<资产> {
Owned 拥有
Transferred 已转让
Rent 租用
}
class AssetRecord {
string asset_id
string asset_type
string asset_no
string owner_type
string owner_id //关联人员/机构组织ID
string asset_id_ref //关联资产信息
string own_status //状态
date register_date //状态变更时间
}
Person ||--o{ AssetRecord : 关联
Asset -- Vehicle : 关联
Asset -- House : 关联
Asset -- ParkSpot : 关联
```
settings/archived/work/2021/数据仓库/kettle使用/Kettle基本信息.md
+5
View File
@@ -0,0 +1,5 @@
开源仓库地址
https://github.com/pentaho/pentaho-kettle
发行版下载地址
https://sourceforge.net/projects/pentaho/files/
settings/archived/work/2021/数据仓库/创医元数据中心建设第一阶段构思.md
+147
View File
@@ -0,0 +1,147 @@
---
title: 创医元数据中心建设第一阶段构思
number headings: auto, first-level 2, max 6, 1.
---
<h1 style="text-align:center;padding-bottom:30px">
创医元数据中心建设第一阶段构思
</h1>
数据中心的建设，对目前的团队来说，并不是一个一促而就的事情。从这两天的学习情况总结，在对业务有充分了解，进而制定一系列数据标准后，才更容易分析出各种领域的数据应该如何去组织。
如果是要逐渐完善这样一个系统，基于前人的经验，我们可以先明确一下目标，确定我们上山的第一个满足需求，有挑战且不会太高的台阶。
## 1. 目标分析
### 1.1. 数据流
首先可以明确的一点是，数据服务并不是产生数据的业务服务系统，对这个服务来说，数据是它加工的源材料。如下图所示：
``` mermaid
graph LR
异构采集-->保存ODS-->清洗加工-->存储DW-->统计-->展示
```
这是现在我们的基本需求，从分散的业务系统中抽取数据，在数据中心清洗、沉淀，进而为业务系统提供统计分析。
### 1.2. 功能模块图
下图是一个数据中台的示意图。有别于常见的业务系统，这里每一个功能点的核心都是数据。
<div style="padding-top:10px;padding-bottom:10px">
<img src="http://thoughts.taotechip.com/uPic/eSFks6.jpg" width=80%/>
</div>
### 1.3. 数据服务体系的层次
数据采集：从数据源同步，采集数据，存入ODS；
数据的处理：清洗，加工，重组，存入DW；
数据的应用：组织DW的数据，对外提供服务，共享，分析，展现。
<div style="padding-top:10px;padding-bottom:10px">
<img src="http://thoughts.taotechip.com/uPic/2sDndM.jpg" width=70%/>
</div>
详细的分层说明，可以参考链接[数据仓库--通用的数据仓库分层方法](https://www.cnblogs.com/itboys/p/10592871.html)
## 2. 方案
### 2.1. 技术方案
#### 2.1.1. 数据流入
``` mermaid
graph LR
subgraph 数据流入
A1[业务系统数据]-->B[ODS层源数据]-->DW仓库数据
A2[业务系统日志]-->B
end
```
**1. 采集工具选择**
* Kettle
通过数据采集，将业务中的数据收集到数据中心系统（ODS）。然后仍然使用kettle，将采集到的源数据，清洗加工进入数据中心核心仓库（DW）。
**2. 采集策略**
通常来说都是会有延时的，但部分工具可以通过一些配置手段，实现延时相对小的效果。
* 实时采集
<div style="padding-top:10px;padding-bottom:10px">
<img src="http://thoughts.taotechip.com/uPic/R5KWne.png" width=80%/>
</div>
* 定时批量采集
<div style="padding-top:10px;padding-bottom:10px">
<img src="http://thoughts.taotechip.com/uPic/zx98Nn.png" width=60%/>
</div>
#### 2.1.2. 数据存储
从ODS层的角度来说，数据结构与逻辑会保留与原业务库的一致性，因此，基于现在我们的系统架构，在ODS层，可能会以mysql结构化数据存储，以mongodb做文档，或系统运行日志数据的存储。
到了DW层，目前的思考是以mongodb建立多中心数据集群，同时依赖Mongodb对于大数据的优化能力，为日后的数据分析，提供更好的基础。
``` mermaid
graph LR
subgraph 数据源
S1[JSON日志]
S3[MONGODB]
S2[MYSQL源]
end
subgraph ODS库
S1-->T1[MONGODB]
S3-->T1
S2-->T2[MYSQL]
end
subgraph DW库
T1-->DW[MONGODB]
T2-->DW
end
```
[[ODS层]] [[DW层]]
#### 2.1.3. 整体方案
<div style="padding-top:10px;padding-bottom:10px;background:#ffffff">
<img src="http://thoughts.taotechip.com/uPic/overall1.png" width=100%/>
</div>
### 2.2. 业务方案
通过业务熟悉分析，来确定数据模型。数仓的建模与业务服务数据库的建模有很大的不同，熟悉业务后，还需要了解下面的建模思路。
* 学习参考资料
[数据仓库学习（二）——数据仓库建模](https://blog.csdn.net/livan1234/article/details/80993391)
[数据仓库学习（四）——星型模型与雪花模型](https://blog.csdn.net/livan1234/article/details/80993541)
## 3. 域模型设计
![[人员基本信息域]]
![[小区信息域]]
![[业务信息域]]
![[机构信息域]]
![[证件信息域]]
![[资产所有权变更信息域]]
![[资产信息域]]
![[字典数据定义]]
## 4. 工作步骤
1. 业务建模（2周）
上面已经找到数据仓库的建模指引，完成初步的DW数据模型设计，预计需要一到两周时间。
1. 测试环境搭建（2周）
上面的整体结构部署和测试工作预期一周时间
1. 构建数据映射（2周）
源数据到仓库各域对象字段的映射。
1. 配置kettle同步脚本与计划任务（2周）
## 5. 二阶段预期
完成基于graphQL的数据服务体系。
待完善...
### 5.1. 数据集市 - 域对象设计Schema
待完善...
### 5.2. 数据服务
#### 5.2.1. 接口框架
Spring GraphQL
#### 5.2.2. 权限管理
##### 5.2.2.1. 账户分配
待完善...
##### 5.2.2.2. 控制到表
待完善...
##### 5.2.2.3. 控制到字段
待完善...
## 6. 参考
1. [基于mongodb的数据中台建设](https://www.doc88.com/p-1846198097871.html?r=1)
1. [kafka官网](http://kafka.apache.org/)
1. [kettle仓库](https://github.com/pentaho/pentaho-kettle)
1. [数据仓库学习系列](https://blog.csdn.net/livan1234/category_7751887.html)
settings/archived/work/2021/数据仓库/域划分.md
+15
View File
@@ -0,0 +1,15 @@
基本确定使用，维度模型
<div style="text-align:center">
<img src="http://thoughts.taotechip.com/uPic/JMSUPZ.jpg"/>
</div>
* 系统记录域（System of Record）：
属于[[ODS层]]，这部分是主要的数据仓库业务数据存储区，数据模型在这里保证了数据的一致性。
* 内部管理域（Housekeeping）：
这部分主要存储数据仓库用于内部管理的元数据，数据模型在这里能够帮助进行统一的元数据的管理。将在这里进行对从数据源采集到的数据进行整理和清洗，对应[[模型设计]]中定义的内容。
* 汇总域（Summary of Area）：这部分数据来自于系统记录域的汇总，数据模型在这里保证了分析域的主题分析的性能，满足了部分的报表查询。
* 分析域（Analysis Area）：这部分数据模型主要用于各个业务部分的具体的主题业务分析。这部分数据模型可以单独存储在相应的数据集市中。
* 反馈域（Feedback Area）：可选项，这部分数据模型主要用于相应前端的反馈数据，数据仓库可以视业务的需要设置这一区域。
settings/archived/work/2021/数据仓库/概念/DA应用层.md
+1
View File
@@ -0,0 +1 @@
在这里，主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。
settings/archived/work/2021/数据仓库/概念/DW层.md
+25
View File
@@ -0,0 +1,25 @@
数据仓库层是我们在做数据仓库时要核心设计的一层，在这里，从 ODS 层中获得的数据按照主题建立各种数据模型。DW层又细分为 DWD（Data Warehouse Detail）层、DWM（Data WareHouse Middle）层和DWS（Data WareHouse Servce）层。
## 数据明细层：DWD（Data Warehouse Detail）
该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。
另外，在该层也会做一部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性，后文会举例说明。
## 数据中间层：DWM（Data WareHouse Middle）
该层会在DWD层的数据基础上，对数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。
直观来讲，就是对通用的核心维度进行聚合操作，算出相应的统计指标。
## 数据服务层：DWS（Data WareHouse Servce）
又称数据集市或宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。
一般来讲，该层的数据表会相对比较少，一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。
在实际计算中，如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在DWM层先计算出多个小的中间表，然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定，也可以去掉DWM这一层，只留DWS层，将所有的数据在放在DWS亦可。
^[[字典数据定义]]
^[[核心数据域]]
settings/archived/work/2021/数据仓库/概念/ODS层.md
+3
View File
@@ -0,0 +1,3 @@
“面向主题的”数据运营层，也叫ODS层，是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的 ETL 之后，装入本层。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。
一般来讲，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的DWD层来做。
settings/archived/work/2021/数据仓库/概念/入门数据仓库.md
+4
View File
@@ -0,0 +1,4 @@
目标
通过熟悉业务，了解业务对于数据的需要，希望达到什么目标。进而确定数据仓库要解决什么问题。
报表
指标
settings/archived/work/2021/数据仓库/概念/数据中台建设.md
+67
View File
@@ -0,0 +1,67 @@
从某个角度来看，数据中台很帖近数据仓库
## 数据中台功能模块图
![eSFks6](http://thoughts.taotechip.com/uPic/eSFks6.jpg)
从上所可知，基于数据中台，要实现的是基于数据的应用体系：
* 数据图表化
* 基于数据，对业务进行分析
* 基于数据，提供的服务
因此，我们要实现这一平台，需要做的，并不是业务本身，而是通过对业务的分析，找到便于分析的数据。
为了实现这一目标，区别于一众业务服务，对业务进行建模，数据中台，要基于业务的分析，对数据进一步抽象。
## 功能层次
功能层次类似于业务系统中，每一层分工完成对入参的解析，加工处理，存储，提取，加工，输出。
![jpQadZ](http://thoughts.taotechip.com/uPic/jpQadZ.png)
附上一篇CSDN中对于数据分层说明的文章
![CSDN 数据仓库—stg层_数据仓库和数据分层](https://blog.csdn.net/weixin_39692253/article/details/111497058)
### 采集层（STG）
这一层主要做的是数据采集与抽取，定义策略来把数据采集回来，好像一种计划任务，批量或是实时。
是根据CDC策略把各个源系统的数据抽取到数据仓库中。STG层主要是面向批处理的形式，如果是根据日志信息实时同步，可以跳过STG层直接进入ODS层。
[知乎上关于CDC的说明](https://zhuanlan.zhihu.com/p/76997736)
* 数据源类型（mysql, log, mongodb）
* 源数据格式 (json, db result set)
* 采集策略 (CDC)
* 采集模式 (批量，实时)
* 采集工具 (oplog, kettle, dataX)
[[明确采集层工作内容]]
### ODS层
ODS层，操作数据层，也叫贴源层，本层直接存放从业务系统抽取过来的数据，这些数据从结构上和数据上与业务系统保持一致，降低了数据抽取的复杂性，本层数据大多是按照源头业务系统的分类方式而分类的。一般来讲，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可。
某种意义上来说，这一层仅仅是为了保证原始数据的完整性。源系统依照标准把数据上报，存到这个临时空间，
* 日志，JSON数据
* 结构化数据
使用mongodb存储
### DW(Data Warehouse)层 - 数据仓库层
数据仓库层是我们在做数据仓库时要核心设计的一层，本层将从 ODS 层中获得的数据按照主题建立各种数据模型，每一个主题对应一个宏观的分析领域，数据仓库层排除对决策无用的数据，提供特定主题的简明视图。DW层又细分为 DWD(Data Warehouse Detail)层、DWM(Data Warehouse Middle)层和DWS(Data Warehouse Service)层。
即是说，这一层的数据，便是面向数据分析，大数据接口服务的核心数据。
### DM层
为数据集市层，这层数据是面向主题来组织数据的，通常是星形或雪花结构的数据。
### APP层
为应用层，这层数据是完全为了满足具体的分析需求而构建的数据，也是星形或雪花结构的数据。
## 模块细化
### 从源系统抽取数据
#### 问题1 异构数据服务
#### 问题2 实时抽取
#### 问题3 批量抽取
### 数据处理
settings/archived/work/2021/数据仓库/概念/数据抽取.md
View File
settings/archived/work/2021/数据仓库/概念/明确采集层工作内容.md
+1
View File
@@ -0,0 +1 @@
[[核心数据域]]
settings/archived/work/2021/数据仓库/模型设计.md
+137
View File
@@ -0,0 +1,137 @@
---
number headings: auto, first-level 2, max 6, 1.1
title: 模型设计
date: 2021-12-20
tags: 每日工作
---
## 1 星座型
<div style="text-align:center">
<img src="http://thoughts.taotechip.com/uPic/2Yi46R.jpg" width=80%>
</div>
## 2 数据域模型
[[证件信息域]]
[[小区信息域]]
[[机构信息域]]
[[资产信息域]]
[[业务信息域]]
[[资产所有权变更信息域]]
### 2.1 公共字典域
字典表，该表向整个平台提供统一的字典服务，系统之间不同标准的字典映射。
* 表示结ER图参考[[字典数据定义#字典表结构ER]]
* 模型字段说明参考[[字典数据定义#字典表字典说明]]
#### 2.1.1 字典类型
```mermaid
graph TB
BASE[字典类型]-->A
BASE-->B
BASE-->C
A[标准]
B[分组]
C[键值]
```
##### 2.1.1.1 标准类型字典(standard)
**一：定义**
不同系统间的字典定义有所不同，如对于性别男的定义可能为1、M、Male、男。为了在数据清洗加工过程中做转换处理，字典服务提供字典数据整理外，还提供字典信息的映射查询等能力。
**二：举例**
1. BASE标准：
系统默认标准，数据平台默认的基础标准，来自不同外部系统的数据，如有相关字段需要，会按照BASE标准的数据进行转化。转化依据为各字典记录中的base_dict_id，这个字段记录了外部系统字典对应的平台base标准字典。定义：[[字典数据定义#2 1 基准标准 base_standard]]
1. 三方标准
各地区、机构、政府会有自定义的标准，有些三方系统的字典，可能没有标准依据，仅仅定义字典值本身。因此本数据平台中会有部分字典，源于组织，机构，或地区的定义。
##### 2.1.1.2 字典分组(category)
**一：定义**
字典组，即属于相关概念的一组字典KV。如性别，行政区，工作分类等等。
**二：举例**
1. 基准性别字典组，定义参考[[字典数据定义#2 2 1 性别分组 base_gender_category]]
2. 基准政区字典组，定义参考[[字典数据定义#2 2 2 政区分组 base_district_category]]
3. 基准证件类型字典组，定义参考[[字典数据定义#2 2 3 证件类型 base_license_type_category]]
4. 基准汽车品牌字典组，定义参考[[字典数据定义#2 2 4 汽车品牌 base_vehicle_brand_category]]
5. 基准机构类型字典组，定义参考[[字典数据定义#2 2 5 机构类型 base_corporation_category]]
6. 基准小区业务类型字典组，定义参考[[字典数据定义#2 2 6 小区业务 base_community_business_category]]
##### 2.1.1.3 基础字典(dict)
**字典转化**
```mermaid
graph LR
ODS源数据--外部字典-->字典映射--转化BASE标准-->DW仓库标准数据
```
### 2.2 基本信息域
基本信息域，保存基本信息与实体间的关系，基于公司内部业务分析，暂定以下几点：
```mermaid
graph
M[域模型]-->人员信息域
M-->车辆信息域
M-->机构信息域
M-->小区信息域
M-->不动产信息域
```
#### 2.2.1 人员信息域
**定义**
1. 人员信息域-[[核心数据域#人员信息]]
1. 车辆信息域-[[核心数据域#车辆信息域]]
1. 机构信息域-[[核心数据域#机构信息域]]
1. 小区信息域-[[核心数据域#小区信息域]]
1. 不动产信息域-[[核心数据域#不动产信息域]]
### 2.3 业务信息域
基于公司内的系统，以及所含子服务的分析，大致划分以下三个大的业务域范围。下文先以智慧小区系统进行分析。
```mermaid
graph TB
ROOT[业务划分]
ROOT-->SECURITY[保险业务]
ROOT-->COMMUNITY_BUSI[小区业务]
ROOT-->GRIDMGMT_BUSI[网格管理业务]
```
#### 2.3.1 小区业务域
基于智慧社区系统，对小区业务域进行划分
```mermaid
graph TB
subgraph 智慧小区核心服务业务
COMMUNITY_BUSI_AUTH[小区服务授权域]
COMMUNITY_SVC_MEMBER[服务人员信息域]
COMMUNITY_SCHEDULE_TASK[计划任务信息域]
COMMUNITY_ORDER_TASK[工单记录信息域]
end
subgraph 智慧小区大健康业务
COMMUNITY_OTHER[更多业务]
end
```
#### 2.3.2 居委业务域
待补充
#### 2.3.3 保险业务域
```mermaid
graph
subgraph 业务域
SECURITY[保险业务域]
SECURE_SCHOOL[校园安全保]
SECURE_MEDICAL[医疗安全保]
SECURE_OTHER[...]
end
SECURITY-->SECURE_SCHOOL
SECURITY-->SECURE_MEDICAL
SECURITY-->SECURE_OTHER
```
### 2.4 事件信息域
系统事件，各系统运行日志
事物事件