obsidian_vault/settings/archived/work/2021/数据仓库/创医元数据中心建设第一阶段构思.md

title, number headings

title	number headings
创医元数据中心建设第一阶段构思	auto, first-level 2, max 6, 1.

创医元数据中心建设第一阶段构思

数据中心的建设，对目前的团队来说，并不是一个一促而就的事情。从这两天的学习情况总结，在对业务有充分了解，进而制定一系列数据标准后，才更容易分析出各种领域的数据应该如何去组织。

如果是要逐渐完善这样一个系统，基于前人的经验，我们可以先明确一下目标，确定我们上山的第一个满足需求，有挑战且不会太高的台阶。

1. 目标分析

1.1. 数据流

首先可以明确的一点是，数据服务并不是产生数据的业务服务系统，对这个服务来说，数据是它加工的源材料。如下图所示：

graph LR
	异构采集-->保存ODS-->清洗加工-->存储DW-->统计-->展示

这是现在我们的基本需求，从分散的业务系统中抽取数据，在数据中心清洗、沉淀，进而为业务系统提供统计分析。

1.2. 功能模块图

下图是一个数据中台的示意图。有别于常见的业务系统，这里每一个功能点的核心都是数据。

1.3. 数据服务体系的层次

数据采集：从数据源同步，采集数据，存入ODS； 数据的处理：清洗，加工，重组，存入DW； 数据的应用：组织DW的数据，对外提供服务，共享，分析，展现。

详细的分层说明，可以参考链接[数据仓库--通用的数据仓库分层方法](https://www.cnblogs.com/itboys/p/10592871.html)

2. 方案

2.1. 技术方案

2.1.1. 数据流入

graph LR
	subgraph 数据流入
	A1[业务系统数据]-->B[ODS层源数据]-->DW仓库数据
	A2[业务系统日志]-->B
	end

1. 采集工具选择

• Kettle 通过数据采集，将业务中的数据收集到数据中心系统（ODS）。然后仍然使用kettle，将采集到的源数据，清洗加工进入数据中心核心仓库（DW）。

2. 采集策略 通常来说都是会有延时的，但部分工具可以通过一些配置手段，实现延时相对小的效果。

• 实时采集

• 定时批量采集

2.1.2. 数据存储

从ODS层的角度来说，数据结构与逻辑会保留与原业务库的一致性，因此，基于现在我们的系统架构，在ODS层，可能会以mysql结构化数据存储，以mongodb做文档，或系统运行日志数据的存储。

到了DW层，目前的思考是以mongodb建立多中心数据集群，同时依赖Mongodb对于大数据的优化能力，为日后的数据分析，提供更好的基础。

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. 整体方案

2.2. 业务方案

通过业务熟悉分析，来确定数据模型。数仓的建模与业务服务数据库的建模有很大的不同，熟悉业务后，还需要了解下面的建模思路。

• 学习参考资料 数据仓库学习（二）——数据仓库建模 数据仓库学习（四）——星型模型与雪花模型

3. 域模型设计

!人员基本信息域 !小区信息域 !业务信息域 !机构信息域 !证件信息域 !资产所有权变更信息域 !资产信息域 !字典数据定义

4. 工作步骤

1. 业务建模（2周） 上面已经找到数据仓库的建模指引，完成初步的DW数据模型设计，预计需要一到两周时间。
2. 测试环境搭建（2周） 上面的整体结构部署和测试工作预期一周时间
3. 构建数据映射（2周） 源数据到仓库各域对象字段的映射。
4. 配置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的数据中台建设
2. kafka官网
3. kettle仓库
4. 数据仓库学习系列