一，项目背景
??????? 最近要做个数据仓库，以前也参与过类似的项目，根据自己的印象，大概做点设计。这个项目的思路很好理解，就是在基层建立一个数据仓库，实现数据在区县-街道-社区之间的三级贯穿。目前一体化平台有大量的数据，但是只是归集，没有做处理；就相当于给了你一座金矿，但是你不会挖。为了解决这个问题，有两种方法，一是建立一个数据仓库，在其中建设很多主题库，把这些涉及到同一个人的数据都关联聚类起来，再把这些应用到场景里面去，那上层的应用就可以使用这些有价值的数据了。也还有第二种方法，你只要对这些表格很熟悉，设计几个功能齐全的sql，想要的数据都能找到，那问题也都解决了。
建设数据仓库的意义有2点：
1，可以持续维持数据的动态更新，一份表格丢入一体化以后，会自动完成抽取-清洗-加载（ETL）的过程，这样可以持续保持数据的鲜活。
2，换个管理员，也能轻松接手。
项目基本的建设内容分为2块：
1，数据仓，标准的数据仓库，设置人口、房屋、企业、事件、物联网设备、统一地址等基础信息主题库。建立一些场景，疫情防控，共同富裕，智能亚运、信用体系、营商环境、基层减负、住房保障一类的。
2，区街社，其实就是增加一个地址字段，说明这条数据是属于哪个街道哪个社区的。从现实意义上看，价值比较大；从技术角度看，没难度，也不需要区分每个街道和社区的子库。
?图1 数据仓库架构图
二，现状
1，数据来源都是一体化平台，几百个表格，但是其中很多表格是空的或者字段不齐全的。数据质量很一般，需要做大量的清洗。以前开发商拿到这些数据说清洗，实际上都是不清洗的，因为问到具体清洗过程的时候，就回答不出来了，因为没做啊。主要是3个原因：1，这块工作是很难的，很细碎，需要消耗大量的时间。2，需要对很多其他业务系统的表格也了解，开发商他们要做到这点是有一点点难度的。3，这些在数据库里面的东西，领导是看不到的；领导能够看到的驾驶舱和大屏，那会做的很努力，修改五六次。从产品质量的角度出发，这是有问题的；但是从利益的角度出发，这么鸡贼好像是对的。
2，三级驾驶舱，是一个给各个街道社区做的驾驶舱，希望是通过三级数据仓来提供数据，但是目前为止，这个事情没做，现在两个项目是相互独立的。
3，统一地址库，这是个独立的东西，需要通过地址把人-房-企链接起来，也是通过地址，区分到具体的街道和社区。这块内容的处理和数据仓关系不大，是一个纯机器学习或者baidu地图可以解决的问题，只要把结果传回数据仓就可以了，另外会写一篇文章介绍处理方法，这里不具体讲了。
三，数据仓库的一般设计
????????数据仓的架构是采用分层设计的，通常可分为数据接入层、数据明细层、数据汇总层、数据集市层、数据应用层、临时层和公共维度层。其中数据明细层和数据汇总层又合称为数据仓库层。
?
图2 数据仓分层设计图
??????? 数据接入层ODS （Operational Data Store，ODS），也称数据贴源层，通常从业务数据库直接导入，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的DWD层来做。
????????数据明细层DWD (Data Warehouse Detail，DWD) ，这层和 ODS 层保持一样的数据结构，只不过在从 ODS 里抽取到 DWD 的时候这个过程叫 ETL，后面我们会再讲 ETL，在抽取时对数据进行清洗加工，提供一定的数据质量保证，提供更干净的数据。
????????数据汇总层DWS（Data Warehouse Summary, DWS），对各个表进行JOIN操作，产生业务所需要的完整数据。该层主要存放明细事实宽表、聚合试试宽表等。
????????数据集市层DWM，也叫数据中间件，(Data Warehouse Middle,DWM)，该层是在DWD层的数据基础上，对数据做一些轻微的聚合操作，生成一些列的中间结果表，提升公共指标的复用性，减少重复加工的工作。简答来说，对通用的核心维度进行聚合操作，算出相应的统计指标。从广度来说，它包含了所有的业务数据。
????????数据应用层，该层中，数据高度汇总，数据粒度较大，但不一定涵盖所有业务数据，也可能只是数据集市层数据的一个子集。该层主要是提供给数据产品和数据分析使用的数据，一般会存放在ES、Redis、PostgreSql等系统中供线上系统使用；也可能存放在hive或者Druid中，供数据分析和数据挖掘使用，比如常用的数据报表就是存在这里的。
????????临时层TMP，临时存放一些中间数据计算结果。
四，具体的主题库建设
下次讲讲
?
