共计 2837 个字符，预计需要花费 8 分钟才能阅读完成。
简介：分层架构很容易在各种书籍和文档中去了解，然而把建模办法和分层架构放在一起就会呈现很多困惑了。接下来，我会从数据研发与建模的角度，演进一下分层架构的设计起因与档次的意义。
分层架构很容易在各种书籍和文档中去了解，然而把建模办法和分层架构放在一起就会呈现很多困惑了。
一、分层的演进
之所以会有分层架构，最次要的起因还是要把简单简短的数据吹流程分拆成一些有明确目的意义的档次，这样简单就被拆解为一些绝对简略小的模块。那么分层架构中各层都是怎么产生的呢，咱们能够简化看一下。
第一个数据加工工作
我要进行第一个数据加工工作，所有平台档次都没有，我只有一个 MaxCompute。我该怎么做呢？
第一步，我须要本人做一下数据集成，把源零碎的数据集成到 MaxCompute。
第二步，我须要把增量合并全量生成 ODS 层，这样我就失去了与业务零碎一样的表构造和全量的数据。
第三步，因为我对业务零碎的数据表关联关系有理解，所以，我能够依据业务需要应用 ODS 的全量表做表关联，加工出我想要的数据后果。
第一个数据利用
如果我不只是做一个业务需要，我是有很多业务需要，这样我就造成了我的第一个数据利用。所以，我会集成更多的数据，做更多的数据合并全量的工作，并且我的全量 ODS 的表能够在多个业务场景复用。
然而试想一下，如果不是一个人在开发，那么团队外部是不是要协调一下，对工作进行一下分工。做集成的和做合并的是不是能够分给一部分人，而后把前面业务需要开发再分给另外一部分人。这样就防止了反复工作，和便于工作的专业性。
于是就能够拆分进去上图中的第一个方块“集成”（STG）和第二个方块“全量”（ODS），这部分是纯技术性的工作，还没有波及到业务需要。对于理论业务需要计算局部，就是咱们的应用层集市层（ADM）。
第二个数据利用
随着第二个数据利用的呈现，各自做集成合并曾经是十分不适宜的做法了，于是就有个独立的 STG 和 ODS 层。
很多时候，做完 ODS 就能够做业务数据加工了。并且这种状况从数据处理技术倒退之初，数据仓库概念提出之前就存在了，当初仍然很广泛。集市各自依赖 ODS 会遇到的多源加工指标不统一的问题逐步遭人诟病，而造成指标不统一的次要起因反复加工。不同的人对同一业务的了解都很难保障一致性，更何况不同的部门的利用。对于这个问题，能够在各个大型企业晚期的数据场景都会遇到，所以，在阿里对外宣传大数据平台的时候也会提到这个晚期各个业务部门数据口径不统一的问题。这个问题在 ODS 的层面无奈解决，必须要独立出一个团队来做公共的这部分数据，让各个利用集市去做各自独立的局部，这也是公共层（CDM）的由来。
二、分层与建模
通过下面的内容，咱们终于晓得了数据加工过程为什么要分层。那么数据建模应该如何来做呢？因为在数据仓库畛域，在数据建模始终有两种争锋绝对的观点，就是范式建模还是维度建模。咱们在目前大数据这个场景，个别就只提一种办法了，就是维度建模。
维度建模的经典办法与教程中没有中间层的概念，也没有主题域划分的概念。维度建模个别用在数据集市场景，也就是 ODS+ADM 场景，各个业务通过一致性维度实现企业级的数据一致性。在传统的被 IOE 统治的时代，Teradata、IBM、Oracle 都有基于关系型数据库（包含 MPP 数据库），在某些重要的行业，例如金融这些企业都会构建大型的企业级的维度模型来给集市提供公共数据服务，这就是公共层。因为范式模型导致实体都比拟窄，跟理论的剖析型业务需要（维度模型）差别太大，所以须要做一层中间层（绝对范式模型更宽的表，这也是宽表说法的由来）来做为利用集市层共性加工工作的档次，这就是当初咱们在架构中提到的 ODS+CDM+ADM 的架构。
那么问题就在这里进去了，咱们全副应用维度模型建模，如何应用范式模型的架构与概念。这也是咱们在分层架构设计中目前最难以讲清楚的问题，也是咱们理论在我的项目外面做的很顺当的起因：不足实践与实际撑持。
维度模型的构建是以理论业务需要为导向，模型是一直的需要累积进去的，适应疾速的业务变动。而且维度模型不是一个倡议一开始就进行企业级的思考设计的模型设计办法，是由部分业务逐步扩张构建的。所以，我认为维度模型的架构不太合适一开始做太重的太业务化公共层。反而应该强调在公共层构建共性加工的汇合，去协调同步多个利用集市的计算，从而实现全局性的一致性维度和一致性事实。因为维度建模的建设也不是简略欲速不达的，也是须要屡次和多种数据处理当前能力最终变成合乎业务需要的后果。多个不同的利用集市有大量的共性的加工需要，这些需要就是咱们公共层的收集的建模需要。把这些共性需要在公共层应用维度建模的办法实现才是建设公共层的正当办法，而不是越俎代庖的去建设面向具体某个业务场景的指标标签（就是尽管理论是做了指标和标签的计算，然而我只是一个两头加工过程）。
接下来，咱们持续利用下面解说分层的办法来解说公共层与集市层的关系。
第一个利用
随着第一个利用呈现，就能够基于局部的需要构建第一个公共层了。共性加工需要在一个中型的利用集市就很显著了。一、数据荡涤。一个表的数据荡涤后，会有多个数据加工工作都会应用这个荡涤后的表，这就是最简略的共性加工的了解。二、多表关联。多张表的关联也是多个数据加工工作中能够提炼进去的，一次把须要关联应用的字段都关联合并到一张新表，后续的工作就能够间接用这个新表。三、共性汇总。对于数据从明细到汇总的 group by，对立依据多个罕用条件进行汇总，生成一张新表，后续的工作就能够间接用这个新表。一致性维度是维度建模中最要害的局部，间接影响到各个利用集市的数据规范与一致性问题，是公共层最重要的工作。
第二个利用
随着利用的减少，需要也在一直的裁减，长期层和镜像层集成的表更多了。在公共层的明细和汇总也呈现了多个利用集市都在共用的数据需要，会扩大补充到公共层。并且随着工夫的变动，公共层的逻辑的正确性和公共性也须要在多个利用进入后整体思考。
公共层与利用关系
通过下面两步演进，咱们曾经看到了公共层与应用层的关系了，是一体的。并不是各做各的，而是一件事件从专业化分工上做了切分。公共层与应用层只有一个独特指标，就是为满足业务需要而做数据加工。不同偏重的是应用层只须要关注本人部门的最终业务指标，公共层则须要从企业级的全局一致性、资源经济性上全盘考虑。
公共层与应用层的关系就是后勤部队与后方作战部队的关系，一个负责根底的资料筹备工作，一个负责利用这些输入投入到实在战场。公共层是高效的数据复用和综合更低的资源代价，应用层则就是理论的业务需要。所以，最终的业务模型在应用层才有残缺的针对性业务场景，在公共层是模型是多种场景业务需要的一个复合，代表了平台最根底和最通用的模型。
从档次上来说，公共层向下是一块整体，负责跟上游多个交易型业务零碎对接，对利用集市屏蔽了上游变动带来的影响，使得应用层能只关注于利用公共层的模型解决本人的业务需要。
原文链接
本文为阿里云原创内容，未经容许不得转载。
