我软件专业的，职业是大数据工程师，投的都是医疗行业，发现这几家处理的都是体检数据。那么来说说建模。

本人想成为某个领域的数据专家，因为自己喜欢生物，所以想成为医疗方面的专家，医疗他会长久不衰，只要人类还在，那么这个行业就一直存在。但是我意识到一个问题，如果发生战争了互联网不能用了，信号被中断了，停电了。那么数据相关职业可能会比较少，那时候大家支付宝微信也不能用了。所以自己不能只在软件行业，个人也要往实体行业相关发展。

---

数仓建模的本质是，为了更快速的做分析。

快速的做分析，包含：

1.查询的时候的性能（原始数据->宽表->业务统计表），查小表（业务表）就很快。

2.ETL的规范，字段规范，数据处理的时候就会规范，避免了重复数据

3.更好的分析，数据都规范了，才能分析。假如一个身高，一个是164cm一个是1600毫米，1.6米，这种就不能分析了。

4.数据的关联性，将数据关联起来，比如产检号、门诊号、孩子胎序、母亲人口学。这些信息，如果不关联起来，就在特定业务场景没法分析。假设要分析孕期儿童肥胖，怎么分析呢？你如果只有孩子的信息，但是做检验的却是它的母亲，所以得做关联。

数仓本质其实就是这4种。

---

医疗数据其实最适合的就是维度建模。医疗是和人相关的，人又是独立的个体，大部分的都是关联这个人的。人与人之间也有关联，比如说孩子和父亲以及母亲。但是他们的关系就这几种，在医疗上面。

ods：数据原始层，在数据库种以ods_tableName。命名，这些数据通常是没有处理的原始数据。如果是医院我们就会要求他们写ETL变成表单的形式，xls这种。为什么采用这种？为什么不自己写？肯定有人这样问。因为你写的话，你就得熟悉整个医院的系统，你就得问医院信息科，你问的时间以及他们告诉你的时间，其实他们已经写完了。由于有些医院是内网，还有断网的情况，你的ETL就会失效。每家医院都不一样，这样如果有1000家医院，你就得维护1000家，你得招1000个人，其实这种东西2个人就能搞定数仓。但是如果你走医院维护ETL的模式，相当于你给医院单独招了个人，成本太高了，变相亏钱，不用做了。第二种xls，医院信息科自己处理，他们只用写个程序把数据导出来就行了，他们本来就要维护他们自己的系统，他们系统改变的话，他们自己在修改数据就可以了，医生或者科研工作者自己导出为xls，上传到数仓的业务系统，这样入库，我们就不用再去做这些繁琐且无意义的对接。想要达到这一步，必须先定义ods层相关的字典，并且要能满足所有的医院，如果A医院的数据不在字典中，那我们就得给他加上这个字典字段。

所以第一步是先对接医院，然后建立初始字典，后面对接其他医院或者检验中心就不断的更新这个字典。通常我们的数据来自的系统有His系统（医生操作的病例系统），ris系统（影像学放射系统）。一般不涉及药品金额，收入开支这些系统（这些系统是医院的隐私，并且跟咱们科研无关）

隐私数据（敏感数据，如身份证，姓名等）要脱敏和对称加密。

---

ods表数据获取后，下一步主题建模。主题建模主要是根据探查，我们观察ods有哪些数据，然后将他们进行归类，设定一些主题。比如，影像及超声：1.超声 2.影像学 3.心电图 

我们把这3张表都归属到 影像及超声这个类目。

又或者，血常规、病毒检查、支原体衣原体、尿液分析。这些我们把他们归属到实验室检查类目。

比如这种。然后去各个ods表里，将这几个表的字段全部列出来，并且列出他们的中英文。

这个东西就叫做主题建模（主题大概有24个）。我们大概有60张这样的表，ods层大概有这么多表。然后我们给他们起新名字，比如dim层，dwd层，给他们表名加前缀。设定他们的字段类型。关联信息。

---

Dimension（dim层，公共层）

维度表：一般是固定不变的数据

维度表有2种，全量表和拉链表（用于存储表更新的全部状态）。医疗数据百分之95用不到拉量表。因为你不会经常去改身份证，或者改姓名。比如说做了某个检验，那就是定了，复查又是另外的单子，不存在我检验后，又修改结果的情况。

假如，母亲人口学信息、父亲人口学信息。这些就是dim，不改变的。

这种数据都比较少，像检查项这种就比较多，他们能关联上这个人口学信息表。这样就减少了冗余。否则一个检查项一个信息表就太多了。

---

我们公司就直接dwd层了。明细层的数据了，就是详细数据。我们公司没有做数据清洗什么的，领导觉得数据清洗太费时费力，医疗数据很多单位，不同厂商也不一样。所以就没有做数仓的数据清洗，新数据来了还得清洗。所以就没有做，就直接dwd层了。

---

ads应用层，这些的数据都是从dwd以及dim关联出来的。这部分就是做了一些计算的，以及业务要求处理的。