我们在谈到数据仓库，都会提到数仓架构，那么数仓架构到底是什么呢？首先，架构就是把一个整体工作按需切分成不同部分的内容，由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动。而数仓架构就可以理解为是构成数据仓库的组件以及之间的具有交互机制的关系。
如上图所示，数仓的数据源可能来自业务系统的数据，或者外部获取的数据，或者从线下文件导入的数据。通过抽取工作，将这些数据存储到数仓的原始数据层中，并存储根据ETL、转换、处理等操作后的数据。在整个过程中，调度平台功能主要实现数据抽取和ETL等处理操作中需要定时完成的任务。而查询引擎功能主要实现快速的查询分析。报表展示功能主要是对数仓中最终的数据做结果展示。
数据仓库是面向主题的(Subject-Oriented)、集成的(Integrated)、非易失的(Non-Volatitle)和时变的(Time-Variant)数据集合，用于支持管理决策。
1）主题性
数据仓库是一般从用户实际需求出发，将不同平台的数据源按设定主题进行划分整合，与传统的面向事务的操作性数据库不同，具有较高的抽象性。面向主题的数据组织方式，就是在较高层次对分析对象数据的一个完整、统一并一致的描述，能完整及统一的刻画各个分析对象所涉及的有关企业的各项数据，以及数据之间的联系。
2）集成性
3）稳定性
数据仓库中的数据主要是为决策者分析提供数据依据。决策依据的数据是不允许随意修改。数据的更新调整主要在数据集成环节完成，一旦进入数据仓库后，用户仅能通过分析工具进行查询和分析。
4）动态性
想要了解数仓建设的目的，首先了解没有数仓建设之前的状况。数仓的数据往往用来为后面的即席查询、分析系统、数据集市、报表系统、数据挖掘系统做准备。在没有数仓建设之前，他们确实是直接对业务系统的数据做如此的操作，但是这样简单的访问，却会造成大量的问题。比如：
OLTP
联机事务处理OLTP，主要执行基本日常的事务处理，比如数据库记录的增删改查。
OLTP的特点：
OLAP
联机分析处理OLAP是数据仓库的主要应用，支持复杂的分析操作，侧重于决策支持，并且提供直观易懂的查询结果。典型的就是复杂的动态报表系统。
OLAP的特点：
总结
OLTP即联机事务处理，主要使用在业务系统中。
OLAP即联机分析处理，是数据仓库的核心部分。
按照数据流入流出来看的话，大致可分为三层，分别是源数据层，数据仓库层，数据应用层。
源数据层
一般是从业务系统抽取的数据、或者通过接口获取、或者通过线下导入，这里是无需做任何修改。
数据仓库层
这一层可以成为细节层，DW层的数据应该是一致的、准确的、干净的数据，即对源数据进行了清洗后的数据
数据应用
报表平台直接读取的数据源；根据报表、专题分析需求而计算生成的数据。
疑问解答？
为什么要分层呢，这不是增加管理困难？
数据集市架构是按主题组织的数据集合，用于支持部门级别的决策。有两种类型的数据集市：独立数据集市和从属数据集市。
独立数据集市
独立数据集市集中于部门所关系的单一主题域，数据以部门为基础部署，无需考虑企业级别的信息共享与集成。例如：营销部、人力资源部、制造部都有各自的数据集市。
优点是：数据量小、周期短、见效快。
缺点是：部门之间的指标不同、部门之间交互能力差、跨部分分析难
从属数据集市
这个架构跟独立数据集市很像，主要区别在于在部门级数据集市之前添加了企业级数据仓库。而企业级数据仓库是一个细节数据的集成资源库。其中的数据以最低粒度级别被捕捉，存储在满足三范式涉及的关系数据库种。
如上图所示，Kimball与Inmon两种架构的主要区别在于核心数据仓库的设计和建立。
Kimball的数据仓库包含高粒度的企业数据，使用多为模型设计，这也意味着数据仓库由星型模型的维度表和事实表构成。分析系统或者报表工具可以直接访问多维数据仓库里的数据。这里的数据集市跟Inmon架构中的数据集市不同，这里的数据集市是一个概念，只是多维数据仓库中的主题划分，并没有自己的物理存储，也可以说是虚拟的数据集市。
所谓混合型架构，就是联合使用Inmon和Kimball这两种架构
如上所示，这种架构将Inmon方法中的数据集市替换成一个多维的数据仓库，而数据集市则是多维数据仓库上的逻辑视图。
优点是：既可以利用规范式设计消除数据冗余，保证数据的粒度够细；又可以充分利用多维结构来更灵活的在企业级数仓中实现分析和展示。
第一范式：要求消除拆分字段至原子字段，即不可再拆分
第二范式：要求消除部分函数依赖，实现完全函数依赖
第三范式：要求消除传递函数依赖
函数依赖：A列属性跟主键有关系
部分函数依赖：A列函数只跟主键的部分属性有关系
完全函数依赖：A列属性只跟主键的全部属性有关系
传递函数依赖：A列属性跟B列属性有关系，B列属性跟主键有关系
元数据(MetaData)，又称为是中介数据、中继数据，为描述数据的数据。
另一种解释就是：一组用于描述数据的数据组，该数据组的一切信息都描述了该数据的某方面的特征，则该数据组即可被称为元数据。
技术元数据
业务元数据
业务元数据为管理层和业务分析人员服务，从业务角度描述数据，包括商务术语、数据仓库中有什么数据、数据的位置和数据的可用性等，帮助业务人员更好的理解数据仓库中哪些数据是可用的以及如何使用。
数仓分层的原则：
1.数据源层：ODS(OperationalDataStore)
ODS层，是最接近数据源中数据的一层，为了考虑后续需要追加数据的问题，这一层不对数据做任何处理。
2.数据仓库层：DW(DataWarehouse)
数据仓库层是我们在做数据仓库的时候要设计的最核心的一层。在这里，从ODS层中获得的数据按照主题建立各种数据模型。DW层又细分为DWD(DataWarehouseDetail)、DWM(DataWarehouseMiddle)、DWS(DataWarehouseService)
1）数据明细层：DWD
该层一般保持和ODS层一样的数据粒度，并提供一定的数据质量保证。DWD层要做的就是将数据清理、整合、规范化、脏数据、垃圾数据、不规范数据、状态不一致数据、命名不规范数据都会被处理。
同时，为提高数据明细层的易用性，该层会采用一些维度退化的手法，将维度退化至事实表，减少事实表和维表之间的关联。
在该层也会做部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性。
2）数据中间层：DWM(DataWareHouseMiddle)
该层会在DWD层的数据基础上，数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。
直观来讲，就是对通用的核心维度进行聚合操作，算出对应的统计指标
在实际的计算中，如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维度太少的问题。因此一般的做法是，在DWM层先计算多个小的中间表，然后再拼接成一个DWS的宽表。由于宽和窄的界限不易界定，也可以去掉DWM这一层，只留DWS层，将所有的数据再放在DWS层亦可。
tips:根据企业宽窄界定，可有可无
3）数据服务层：DWS(DataWareHouseService)
DWS层为公共汇总层，会进行轻度汇总，粒度比明细数据稍粗，基于DWD层上的基础数据，整合汇总分析某一个主题域的服务数据，一般是宽表。DWS层应覆盖80%的应用场景，又称为数据集市或宽表。
按照业务划分，如主题域流量、订单、用户等，生成的字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据并发。
一般来讲，该层的数据表相对较少，一张表会涵盖较多的业务内容，由于其字段较多，因此一边拿会称该层的表为宽表。
4）数据应用层：APP(Application)
在这里，主要是提供给数据产品和数据分析使用的数据，一般会存放在ES、PostgreSql、Redis等系统中供线上系统使用，也可能会存在Hive或者Druid中供数据分析和数据挖掘使用。
5）维度表：DIM(Dimension)
如果维表过多，也可以针对维表设计单独的一层，维表主要包含两部分数据：
高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级别或者上亿级别。
低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。
数仓建模主要是在DW层进行数仓建模，所以DW层是数仓建设的核心层。
常见的建模方法有范式建模、维度建模、实体类建模，从不同的角度看待业务问题。
1）范式建模法
范式建模法其实是我们在构建数据模型常用的一种方法，该方法的主要由Inmon所提倡，主要解决关系型数据仓库的数据存储，利用的一种技术层面上的方法。目前，在关系型数据库中的建模方法，大多数采用的第三范式建模法。
范式是符合某一级别的关系模式的集合。构造数据库必须遵循一定的规则，而在关系型数据库中这种规则就是范式，这一过程也被成为规范化。在数据仓库的模型设计中，一般采用第三范式。而第三范式要满足以下条件：
2）维度建模法
维度模型是数据仓库领域另一位大师RalphKimall所倡导，他的《数据仓库工具箱》是数据仓库领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快完成分析需求，同时还有较好的大规模复杂查询的响应性能。
在维度建模中最为典型的就是星型模型，还有在特殊场景用到的雪花模型和星座模型。
维度建模中比较重要的概念就是事实表和维度表。其最简单的描述就是，按照事实表、维度表来构建数据仓库、数据集市。
3）实体建模法
如上图所示，虽然实体法粗看有些抽象，其实理解起来很容易。即我们可以将任何一个业务过程划分成三个部分，实体、事件、说明。
目前在互联网公司中最常用的建模方法就是维度建模。维度建模适用于分析性数据库、数据仓库、数据集市(小型数据仓库)建模的方法。在开始建模之前，应先了解维度建模中表的类型和维度建模的模式，有利于我们更深刻的理解。
维度建模中的表主要为两种：事实表和维度表
1）事实表
发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。最低的粒度级别来看，事实表对应一个度量事件，反之亦然。事实表表示对分析主题的度量。比如一次购买行为我们就可以理解为是一个事实。
1.1）事实表-明细表(宽表):
事实表的数据中，有些属性共同组成了一个字段(糅合在一起)，比如年月日时分秒构成了事件，当需要根据某一属性进行分组统计的时候，需要截取拼接之类的操作，效率极低，如：
为了方便根据其中某一属性进行分组统计(例如按照月统计生成单数)，可以在事实表中的一个字段切割提取多个属性构成新的字段，因为字段变多了，所以称为宽表，原来的为窄表。又因为宽表的信息更加清洗明细，所以也可以称其为明细表。
1.2）事实表分类
2）维度表
每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键。维度表通常比较宽，是扁平化非规范表，包含大量的低粒度的文本属性。
总的来说，在数据仓库中不需要遵守规范化的设计原则。因为数据仓库的主导功能就算面向分析，以查询为主，不涉及数据更新的操作。事实表的设计是以能够正确记录历史信息为准则，维度表的设计是以能够以合适的角度来聚合主题内容为准则。
1）星型模型
星型模型是最常用的维度建模方式。星型模型以事实表为中心，所有维度表直接连接在事实表上，像星星一样，故称为星型模型。星型模型的维度建模由一个事实表和一堆维度表组成，且具有以下特点：
2）雪花模型
雪花模型是对星型模型的扩展。雪花模型的维度表可以拥有其他维度表，虽然这种模型相比星型模型更加规范，但是由于这种模型不易理解，维护成本高，而且性能方面需要关联多层维度表，性能也比星型模型要低。所以一般不是很常用。
3）星座模型
星座模型是星型模型延伸而来，星型模型是基于一张事实表，而星座模型是基于多张事实表，而且共享维度信息。星型模型和星座模型都是多维表对应单事实表但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大多数维度建模都是采用星座模型。
在维度建模的时候，表的类型主要分为事实表和维度表；模式有星型模型、雪花模型和星座模型。但是在实际业务中，如果拿到一堆的数据，怎么进行数据建设呢？
数仓工具箱中的维度建模四步走：
1）选择业务过程
维度建模是紧贴业务的，所以必须以业务为根基进行建模，那么选择业务过程，顾名思义就是在整个业务流程中选取我们需要建模的业务，根据运营提供的需求以及日后的易扩展性等进行选择业务。比如商城，整个商城流程分为商家端、用户端、平台端，运营需求是总订单量，订单人数，及用户购买情况。我们选择业务过程就选择用户端的数据，商家及平台端暂不考虑。业务选择非常重要，因为后面所有的步骤都是基于此业务数据展开的。
3）确认维度
维度表是作为业务分析的入口和描述性标识，所以也被称为数据仓库的“灵魂”。在一堆的数据中怎么确定哪些是维度属性呢，如果该列是对具体的描述，是一个文本或者常量，某一约束和行标识的参与者，此时该属性往往是维度属性，数仓工具箱告诉我们牢牢掌握事实表的粒度，就能将所有可能存在的维度区分开。并且要确保维度表中不能出现重复数据，应使维度主键唯一。
4）确认事实
事实表是用来度量的，基本都以数据量表示，事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。维度建模的核心原则之一是统一事实表中所有度量必须具有相同的粒度。这样能确保不会出现重复计算度量的问题。有时候往往不能确定该列数据是事实属性还是维度属性，记住最实用的事实就是数值类型和可加类事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下往往是事实。
技术是为业务服务，业务是为公司创造价值，离开业务的技术是毫无意义的
需要针对不同需求的用户开发不同的产品，所以公司内部有很多条业务线，但是对于数据部门来说，所有数据线的数据都是数据源。对数据的划分不只根据业务进行，而是结合数据的属性。
之前开发是不同业务线对应不同的数据团队，每个数据团队互不干扰，这种模式比较简单，只针对自己的业务线进行数仓建设及报表开发即可。
但是随着业务的发展，频繁迭代及跨部门的垂直业务单元原来越多，业务之间的出现耦合的情况，这时再采用这种烟囱开发就出现了问题：
还有重复开发的问题，不同业务线会出现相同的报表需求，如果每个业务方都开发各自的报表，太浪费资源。所以对于数据开发而言，需要对各个业务线的数据进行统一管理，所以就有了数据中台的出现。
数据中台的建设是根据每个公司的业务需求而搭建的，不同的业务，对中台的理解有所不同。公司内部开发的敏捷数据中台，主要从数据技术和计算能力的服用，到数据资产和数据服务的服用，数据中台以更大价值带宽，快精准直接赋能业务。提供一个统一化的管理，打破数据孤岛，追溯数据血缘，实现自助化及高复用度。
以上解释比较抽象，可以以实际项目开发来分析数据中台的便利性。比如在整个流程中，首先是数据采集，不同的数据通过Sqoop、DataX、Kettle、Nifi等工具采集到大数据平台中，然后进行数仓搭建，最后产出报表数据，放到可视化系统中展示，最终把整个流程写成脚本放到调度平台进行自动化执行(例如Azkaban,Dolphin)。
有了数据中台之后就不需要那么繁杂的事情，直接进行数仓搭建，产生报表即可，无需将精力浪费在数据源、可视化展示及调度。并且可以直观的查看数据血缘关系，计算表之间的血缘。如下图所示：
数据中台的异构数据系统可以非常简单的进行查询，比如Hive的表关联MySQL的表。可透明屏蔽异构数据系统交互方式，轻松实现跨异构数据系统透明混算。
异构数据系统原理是数据中台提供虚拟表之间的映射，终端用户无需关心数据的物理存放位置和底层数据源的特性，可直接操作数据，体验类似操作一个虚拟数据库。
数仓建设是根据公司的业务发展以及现有的数据中台进行，数仓的建设离不开公司的业务。
数仓建设核心思想：从涉及、开发、部署和使用层面，避免重复建设和指标冗余建设，从而保障数据口径的规范和统一，最终实现数据资产全链路关联、提供标准数据输出以及建立统一的数据公共层。
数仓建设主要从两个方面，规模和规范，所有业务进行统一化。
1）模型
所有业务采用统一的模型体系，从而降低研发成本，增强指标服用，并且能够保证数据口径的统一
2）模型分层
结合公司业务，后期新增需求增多，所以分层不宜过多，并且需要清晰明确各自职责，要确保数据层的稳定又屏蔽对下游影响，所以采用分层结构：
1）数据流向
遵循模型开发时分层结构，数据从ods->dw-dm-app这样正向流动，可以放置因数据引用不规范而造成数据链路混乱及SLA时效难保障等问题，同时保证血缘关系简单化，能够轻易追踪数据流向。在开发时应避免以下情况出现：
1.数据链路引用不正确，如ods-dm-app，出现这种情况说明明细层没有完全覆盖数据；如ods-dw_app，说明轻度汇总主题划分未完全覆盖。减少跨层引用，才能提高中间表的复用性，理想的数仓模型设计应当具备：数据模型可复用，完善且规范。
2.尽量避免一层的表引用当前层的表，如DW层的表生成DW层的表，这样会影响ETL效率。
3.禁止出现反向依赖，如DW表依赖于DM表
2）规范
2.1）表命名规范
1.对于ods,dm,app层表名：类型_主题_含义，如：dm_xxsh_user
2.对于dw层表名：类型_主题_维度_表含义,如：dw_xxsh_fact_users(事实表)、dw_xxsh_dim_users(维度表)
2.2）字段命名规范
构建词根，词根是维度和指标管理的基础，划分为普通词根与专有词根
1.普通词根：描述事物的最小单位，如：sex-性别
2.专有词根：具备行业专属或公司内部规定的描述题，如：xxsh-公司内部对某个产品的称呼
3.脚本命名规范：脚本名称：脚本类型.脚本共用.[库名].脚本名称，如hive.hive.dm.dm_xxsh_users
脚本常用类型：1.hivesql2.shell脚本3.python脚本
1）数据源层ODS
数据源层主要将各个业务数据导入到大数据平台，作为业务数据的快照存储。
2）数据明细层DW
事实表中的每行对应一个度量，每行中的数据是都是特定级别的细节数据，称为粒度。维度建模的核心原则就是同一事实表中所有度量必须具有相同的粒度。这样才能确保不会出现重复计算度量的问题。
维度表一般都是单一主键，少数是联合主键，注意维度表不要出现重复的数据，否则和事实表关联会出现数据发散的问题。
有时候往往不能确定该列数据是事实属性还是维度属性。记住最实用的事实就是数值类型和可加类事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下往往是事实字段。如果该列是对具体值的描述，是一个文本或常量，某一约束和行标识的参与者，此时该属性往往是维度属性。但是还要结合具体业务进行最终的判断是事实还是维度。
3）数据轻度汇总层DM
此层命名为轻度汇总层，就代表这一层已经开始对数据进行汇总，但是不是完全汇总，只是对相同粒度的数据进行关联汇总，不同粒度但是有关系的数据也可以进行汇总，此时需要将粒度通过聚合等操作进行统一。
4）数据应用APP层
数据应用层的表是提供给用户使用的，数仓建设到此就接近尾声了，接下来就根据不同的需求进行不同的取数，如直接进行不同的取数，如直接进行报表展示，或提供给数据分析的同事的数据，或其他业务支撑。
实际环境中不能像测试环境一样随意，很容易造成生产事故。所以每一步操作都必须要小心，以下为简单列出的注意事项：
实时计算一般是针对海量的数据进行的，并且要求秒级。由于大数据兴起之时，Hadoop并没有给出实时计算的解决方案，随后的Stromberg，SparkStreaming，Flink等实时计算框架应运而生，而Kafka、ES的兴起也使得实时计算领域的技术越来越得到完善，而随着物联网，机器学习等技术的推广，实时流式计算在这些领域得到充分的应用。
实时计算的三个特征：
现在大数据应用比较火爆的领域，比如推荐系统在实践之初受技术所限，可能要一分钟，一小时，甚至更久对用户进行推荐，这远远不能满足需要，我们需要更快的完成对数据的处理，而不是进行离线的批处理。
随着实时技术趋于成熟，实时计算应用越来越广泛，以下仅列举常见的各种实时计算的应用场景。
1）实时智能推荐
智能推荐会根据用户历史的购买或浏览行为，通过推荐算法训练模型，预测用户未来可能会购买的物品或喜爱的咨询。对个人来说，推荐系统起着信息过滤的作用，对Web/App服务端来说，推荐系统起着满足用户个性化需求，提升用户满意度的作用。推荐系统本身也在飞速发展，除了算法越来越完善，对时延的要求也越来越苛刻和实时化。利用flink流计算帮助用户构建更加实时的智能推荐系统，对用户行为指标进行实时计算，对模型进行实时更新，对用户指标进行实时预测，并将预测的信息推送给Web/App端，帮助用户获取想要的商品信息，另一方面也帮助企业提升销售额，创造更大的商业价值。
2）实时欺诈检测
在金融领域的业务中，常常出现各种类型的欺诈行为，例如信用卡欺诈，信贷申请欺诈登，而如何保证用户和公司的资金安全，是近年来许多金融公司及银行共同面对的调整。随着不法分子欺诈手段的不断升级，传统的反诈手段不足解决目前所面临的问题。以往可能需要几个小时才能通过交易数据计算出用户的行为指标，然后通过规则判别具有欺诈行为嫌疑的用户，再进行案件调差处理，在这种情况虾资金可能早被不发分子转移，从而给企业和用户造成德莱昂的经济损失。而运用flink流式计算技术能够在毫秒内就完成欺诈行为判断指标的计算，然后实时对交易流水进行实施拦截，避免因为处理不及时而导致经济损失。
3）舆情分析
4）复杂事件处理
对于复杂事件处理，比较常见的集中于工业领域，例如对车载传感器，机械设备登实时故障检测，这些业务类型通常数据量都非常大，且对数据处理的时效性要求更高。通过利用flink提供的CEP进行事件模式的抽取，同时应用Flink的SQL进行事件数据的转换，在流式系统中构建实施规则引擎，一旦事件触发报警规则，便立即将告警结果通知至下游系统，从而实现对设备故障快速预警监测，车辆状态监控等目的。
5）实时机器学习
1）数据同步
2）数据存储
数据存储部分主要是对原始数据、清洗关联后的明细数据进行的存储操作，基于统一的实时数据模型分层理念，将数据依次存放至各层。以及将不同应用常见的数据可以分别存储在Kafka、HDFS、Kudu、Hive、ClickHouse、Hbase、ES中进行应用。
3）数据计算
4）实时应用
以统一查询服务对各个业务数据场景进行支持，业务主要包括实时大屏、实时数据产品、实时OLAP、实时特征等。
当然一个好的大数据平台不能缺少元数据管理以及数据治理：
5）元数据指标管理
主要对实时的Kafka表、kudu表、clickhouse表、hive表等进行统一管理，以数仓模型中表的命令方式规范表的命名，明确每张表的字段含义、使用方，指标管理则是尽量通过指标系统将所有的实时指标统一管理，明确计算口径，提供给不同的业务方使用；
6）数据质量及血缘分析
数据质量分为平台监控和数据监控两个部分，血缘分析则是主要对实时数据依赖关系、实时任务的依赖关系进行分析。
以上列举的架构流程只是通用的数据模型，如果要具体的建设，需要考虑一下情况，业务需求需要实时还是准实时即可，数据时效性是妙计还是分钟级等。
于是随着诞生了大数据实时数仓，并衍生出两种架构Lamdba和Kappa。首先看一下两者简单的对比。
Lambda架构，数据从底层的数据源开始，经过Kafka、Flume等数据组件进行收集，然后分成两条线进行计算：
为什么Lambda架构要分成两条线计算？
Lambda架构属于较早的一种架构方式，早期的流处理不如现在这样成熟，在准确性、扩展性和容错性上，流处理层无法直接取代批处理层，只能给用户提供一个近似结果，还不能给用户提供一个一致准确的结果。因此Lambda架构中，出现了批处理和流处理并存的现象。
在Lambda架构中，每层都有自己所肩负的任务。
1.批处理层存储管理主数据集(不可变的数据集)和预先批处理计算好的视图：
批处理层使用可处理大量数据的分布式处理系统预先计算结果。它通过处理所有的已有历史数据来实现数据的准确性。这意味着它是基于完整的数据集来重新计算的，能够修复任何错误，然后更新现有的数据视图。输出通常存储在只读数据库中，更新则完全取代现有预先计算好的视图。
2.流处理层会实时处理新来的数据
流处理层通过提供最新数据的实时视图来最小化延迟。流处理层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整，但他们几乎在收到数据后立即可用。而当同样的数据在批处理层处理完成后，在速度层的数据就可以被替代掉了。
那Lambda架构有没有缺点呢？
导致Lambda架构的缺点根本原因是要同时维护两套系统架构：批处理层和速度层。我们已经知道，在架构中加入批处理层是因为从批处理层得到的结果具有高准确性，而加入速度层是因为它在处理大规模数据时具有低延迟性。那我们能不能改进其中一层的架构，让它具有另外一层架构的特性呢？
例如，改进批处理层的系统让它具有更低的延迟性，又或者改进速度层的系统，让它产生的视图更具准确性和更加接近历史数据呢？
另外一种在大规模数据处理中常见的架构-Kappa加偶，便是在这样的思考下诞生的。
Kafka创始人JayKreps认为在很多常见下，维护一套Lambda架构的大数据处理平台耗时耗力，于是提出在某些场景下，没有必要维护一个批处理层，直接使用一个流处理层即可满足需求，即下图所示的Kappa架构图：
Kappa架构的兴起主要又两个原因：
Kappa架构相对更简单，实时性更好，所需的计算资源小于Lambda架构，随着实时处理的需求在不断增长，更多的企业开始使用Kappa架构。但这并不意味着Kappa架构能够取代Lambda架构。
Lambda和Kappa架构都有各自的适用领域：例如流处理与批处理分析流程比较统一，且允许一定的容错，用kappa架构比较合适，少量关键指标(例如交易金额、业绩统计等)使用Lambda架构进行批量计算，增加一次校对过程。
还有一些比较复杂的场景，批处理与流处理产生不同的结果(使用不同的机器学习模型、专家系统，或者实时计算难以处理的复杂计算)，可能更适合Lambda架构。
实时数仓分层为了避免需求响应的烟囱式构建，实时数仓也引入了类似于离线数仓的的分层理念，主要为了提升模型的复用率，同时也要考虑模型的复用率，同时也要考虑易用性、一致性以及计算的成本。
当然实时数仓的分层架构在设计上并不会像离线数仓那么复杂，避免数据在流转过程中造成的不必要的延迟相应。
1）ODS层
2）DWD层
实时计算订阅业务数据消息队列，然后通过数据清洗、多数据源join、流式数据于离线维度信息等组合，将一些相同粒度的业务系统、维度中的维度属性全部关联到一起，增加数据易用性和复用性，得到最终的实时明细数据；
3）DIM层
存放用于关联查询的维度信息，可以根据数据现状来选择存储介质，例如使用HBase或者MySQL
4）DWS层
轻度汇总层是为了便于面向ADHoc查询或者OLAP分析构建的轻度汇总结果集合，适合数据维度、指标信息比较多的情况，为了方便根据自定义条件的快速筛选和指标聚合，推荐使用MPP类型数据库进行存储，此层可视场景情况是否构建
5）APP层
面向实时数据场景需求构建的高度汇总层，可以根据不同的数据应用场景决定使用存储介质或者引擎；例如面向业务历史明细、BI支持等OLAP分析场景，可以使用Durid、GreenPlum,面向实时监控大屏、高并发汇总指标等需求，可以使用KV模式的HBase；数据量较小的时候，也可以使用MySQL来进行存储。
这里需要注意的是：其实APP层已经脱离了数仓，这里虽然作为数仓的独立分层，但是实际APP层的数据已经分布存储在各种介质中用于使用。
基于Flink构建的实时数仓
基于Flink的实时数仓数据转换过程：
数据在实时数仓中的流转过程，实际和离线数仓非常相似，只是由Flink替代Hive作为了计算引擎，把存储由HDFS更换成了Kafka，但是模型的构建思路与流转并没有发生变化。
虽然实时计算在最近几年才火起来，但是在早期也有部分公司有实时计算的需求，但是数据量比较少，所以在实时方面行成不了完整的体系，基本所有的开发都是具体问题具体分析，来一个需求做一个，基本不考虑他们之间的关系，开发形式如下：
如上如所示：拿到数据源后，会经过数据清洗，扩维，通过Flink进行业务逻辑处理，最后直接进行业务输出。把这个环节拆开来看，数据源端会重复引用相同的数据源，后面进行清洗、过滤、扩维等操作，都要重复做一遍，唯一不同的是业务的代码逻辑是不一样的。
随着产品和业务人员对实时数据需求的不断增多，这种开发模式出现的问题越来越多：
大家看实时数仓的发展和出现的问题，和离线数仓非常相似，后期数据量大了之后产生各种各样的问题，离线数仓当时是怎么解决的呢？离线数仓通过分层架构使数据解耦，多个业务系统可以共用数据，实时数仓是否也可以用到分层架构呢？当前是可以的，但是细节上和离线的分层还是会有稍微的不同。
从方法论来讲，实时和离线是非常相似的，离线数仓早期的时候也是具体问题具体分析，当数据规模涨到一定量的时候才会考虑如何治理。分层是一种非常有效的数据治理方式，所以在实时数仓如何进行管理的问题上，首先考虑的也是分层的处理逻辑。
实时数仓各层次作用：
从这可以看出，实时数仓和离线数仓的分层非常相似，比如数据源层，明细层，汇总层，以及应用层，两者的命名的模式可能都是一样的。但是自己研究的话，会发现两者还是又很多的区别，比如：
Lambda架构是比较经典的架构，以前实时的场景不是很多，以离线为主，当附加了实时场景后，由于离线和实时的时效性不同，导致技术生态是不一样的。Lambda架构相当于附加了一条实时生产链路，在应用层进行一个整合，双路生产，各自独立。这在业务应用中也是顺理成章采用的一种方式。
双路生产会存在一些问题，比如加工逻辑double，开发运维也会double，资源同样会变成两个资源链路。因为存在以上问题，所以又演进了一个Kappa架构。
Kappa架构从架构涉及来讲比较简单，生产统一，一套逻辑同时生产离线和实时。但是在实际应用场景中有比较大的局限性，因为实时数据的同一份表，会使用不同的方式存储，这就导致关联时需要跨数据源，操作数据又很大的局限性，所以在业内直接使用Kappa架构生产落地的案例不多见，且场景比较单一。
关于Kappa架构，熟悉实时数仓生产的同学，可能会有一个疑问。因为我们呢经常会面临业务变更，所以很多业务逻辑是需要迭代的。之前产出的一些数据，如果口径变更了，就需要重算，甚至重刷历史数据。对于实时数仓来说，怎么去解决数据重算问题？
随着实时OLAP技术的发展，目前开源的OLAP引擎在性能上，易用性方面有了很大的提升，如Doris、Presto等，加上数据库技术的迅速发展，使得流批结合的方式变得简单。
数据从日志统一采集到消息队列，再到实时数仓，作为基础数据流的建设是统一的。之后对于日志类实时特征，实时大屏类应用走实时流计算。对于Binlog类业务分析走实时OLAP批处理。
我们看到流批结合的方式与上面几种架构的存储方式发生了变化，由Kafka换成了Iceberg,Iceberg是介于上层计算引擎和底层存储格式之间的一个中间层，我们可以把他定义成一种数据组织格式，底层存储还是HDFS，那么为什么加了中间层，就对流批结合处理的比较号了呢？Iceberg的ACID能力可以简化整个流水线的设计，降低整个流水线的延迟，并且所具有的修改、删除能力能够有效的降低开销，提升效率。Iceberg可以有效支持批处理的高吞吐数据扫描和流计算按分区粒度并发实时处理。
数据建设真正的难点不在于数仓设计，而在于后续业务发展起来，业务线变得庞大之后的数据治理，包括资产治理、数据质量监控、数据指标体系的建设等。
数据治理的范围很广，包含数据本身的管理、数据安全、数据质量、数据成本等。在DAMA数据管理知识体系指南中，数据治理位于数据管理车轮图的正中央，是数据架构、数据建模、数据存储、数据安全、数据质量、元数据管理、主数据管理等十大数据管理领域的总纲，为各项数据管理活动提供总体指导策略。
1）数据治理需要体系建设
为发挥数据价值需要三个要求：合理的平台架构、完善的治理服务、体系化的运营手段。
根据企业的规模、所属行业、数据量等情况选择合适的平台架构；治理服务需要贯穿数据全生命周期，保证数据在采集、加工、共享、存储、应用整个过程中的，完整性、准确性、一致性和实效性；运营手段应当包括规范的优化、组织的优化以及流程的优化等等方面。
2）数据治理需要夯实基础
3）数据治理需要IT赋能
数据治理不是一堆规范文档的堆砌，而是需要将治理过程中所产生的规范、流程、标准落地到IT平台上，在数据生产中通过以终为始前想的方式进行数据治理，避免事后稽核带来各种被动和运维成本的增加。
4）数据治理需要聚焦数据
5）数据治理需要建管一体化
数据模型血缘与任务调度一致性是建管一体化的关键，有助于解决数据管理与数据生产口径不一致的问题，避免出现两张皮的低效管理模式。
如上所说，数据治理的范围非常广，其中最重要的是数据质量治理，而数据质量涉及的范围也很广，贯穿数仓的整个生命周期，从数据产生->数据接入->数据存储->数据处理->数据输出->数据展示，每个阶段都需要质量治理，评价维度包括完整性、规范性、一致性、准确性、唯一性、关联性等。
在系统建设的各个阶段都应该根据标准进行数据质量检测和规范，及时进行治理，避免事后的清洗工作。
质量检测可参考以下标准：
1）规范治理
规范是数仓建设的保障。为了避免出现指标重复建设和数据质量差的情况，统一按照最详细、可落地的方法进行规范建设。
1.1）词根
词根是维度和指标管理的基础，划分为普通词根与专有词根，提高词根的易用性和关联性。
1.2）表命名规范
通用规范
表命名规则
1.3）指标命名规范
结合指标的特性以及词根管理规范，将指标进行结构化处理。
1.基础指标词根，即所有指标必须包含以下基础词根：
2.业务修饰词，用于描述业务场景的词汇，例如trade-交易
4.聚合修饰词，对结果进行聚集操作
5.基础指标，单一的业务修饰词+基础指标词根构建基础指标，例如：交易金额-trade_amt
6.派生指标，多修饰词+基础指标词根构建派生指标。派生指标继承基础指标的特性，例如：安装门店数量-install_poi_cnt
7.普通指标命名规范，与字段命名规范一致，由词汇转换即可
2）架构治理
2.1）数据分层
优秀可靠的数仓体系，往往需要清晰的数据分层结构，即要保证数据层的稳定又要屏蔽对下游的影响，并且要避免链路过长，一般的分层架构如下：
2.2）数据流向
稳定业务按照标准的数据流向进行开发，即ODS->DWD->DWA->APP。非稳定业务或探索性需求，可以遵循ODS->DWD->APP或者ODS->DWD-DWT->APP两个模型数据流。在保障了数据链路的合理性之后，又在此基础上确认模型分层引用原则：
3）元数据治理
元数据可以分为技术元数据和业务元数据：
常见的技术元数据有：
元数据治理主要解决三个问题：
4）安全治理
5）数据生命周期治理
数据治理的范围非常广，包含数据本身的管理、数据安全、数据质量、数据成本。在这么多治理内容中，大家觉得最重要的治理是什么？当然是数据质量治理，因为数据质量是数据分析结论有效性和准确性的基础，也是这一切的前提，所以如何保障数据质量，确保数据可用性是数据仓库建设中不容忽视的环节。
数据质量涉及的范围很广，贯穿数仓的整个生命周期，从数据产生->数据接入->数据存储->数据处理->数据输出->数据展示，每个阶段都需要质量治理。在系统建设的各个阶段都应该根据标准进行数据质量检测和规范，及时进行治理，避免时候的清洗工作。
场景一：作为数据分析人员，要统计一下近7天用户的购买情况，结果从数仓中统计发现，很多数据发生了重复记录，甚至有些数据统计单位不统一。
场景二：业务看报表，发现某一天的的成交gmv暴跌，经过排查发现，是当天的数据缺失。
造成这种情况的一个重要因素是忽视了对数据质量的客观评估，没有制定合理的衡量标准，导致没有发现数据已出现问题。所以，进行科学、客观的数据质量衡量标准是非常必要且十分重要的。
如何评估数据质量的好坏，业界有不同的标准，主要可以从以下六个维度进行评估：包括完整性、规范性、一致性、准确性、唯一性、及时性。
1）数据完整性
完整性指的是数据信息是否存在缺失的状况，数据缺失的情况可能是整个数据记录缺失，也可能是数据中某个字段信息的记录缺失。
2）数据规范性
规范性指的是描述数据遵循预定的语法规则的程度，是否符合其定义，比如数据的类型、格式、取值范围等。
3）数据一致性
一致性是指数据是否遵循了统一的规范，数据集合是否保持了统一的格式。数据质量的一致性主要体现在数据记录的规范和数据是否符合逻辑，一致性并不意味着数值上的绝对相同，而是数据收集、处理的方法和标准一直。常见的一致性指标有:ID重合度、属性一致、取值一致、采集方法一致、转换步骤一致。
4）数据准确性
准确性是指数据记录的信息是否存在异常或错误。和一致性不一样，存在准确性问题不仅仅只是规则上的不一致，更常见的数据准确性错误就如乱码，其次异常的大或者小的数据也是不符合条件的数据。常见的准确性指标有：缺失值占比、错误值占比、异常值占比、抽样偏差、数据噪声。
5）数据唯一性
唯一性指的是数据库的数据不存在重复的情形。比如真是成交一万条，但是数据表重复就有3000条了，成了1.3万条成交记录，这种数据不符合数据唯一性。
6）数据及时性
还有一些其他的衡量标准
1）数据资产等级
1.1）等级定义
根据当前数据质量不满足完整性、规范性、一致性、准确性、唯一性、及时性，对业务的影响程度大小来划分数据的资产等级。
重要程度：L1>L2>L3>L4>Lx。如果一份数据出现多个应用常见重，则根据其最重要程度进行标记。
1.2）等级划分
定义数据资产登基后，我们可以从数据流程链路开始进行数据资产等级标记，完成数据资产等级确认，给不同的数据定义不同的重要程度。
1.分析数据链路：
数据是从业务系统重产生的，经过同步工具进入数据仓库系统中，在数据仓库中进行一般意义上的清洗、加工、整合、算法、模型等一系列运算后，再通过同步工具输出到数据产品中进行消费。而从业务系统到数据仓库再到数据产品都是以表的形式体现，其流转过程如下图所示：
2.标记数据资产等级：
在所有数据链路，整理出消费各个表的应用业务。通过给这些应用划分数据资产等级，结合数据的上下游依赖关系，将整个链路打上某一类资产等级标签。
举例：
假如公司有统一的订单服务中心。应用层的应用业务是按照业务线，商品类型和地域统计公司的订单数量和订单金额，命名为order_num_amount。
假设该应用会影响到整个企业的重要业务决策，我们可以把应用定级为L2，从而整个数据链路上的表的数据等级，都可以标记为L2-order_num_amount,一直标记到源数据业务系统，如下图所示：
2）数据加工过程卡点校验
2.1）在线系统数据校验
在线业务复杂多变，总是在不断的变更，每一次变更都会带来数据的变化，数据仓库需要适应多变的业务发展，及时做到数据的准确性。
基于此，在线业务的变更如何高效的通知到离线数仓，同样也是需要考虑问题。为了保障在线数据和离线数据的一致性，我们可以通过工具+人员管理并行的方法来尽可能的解决以上问题：即要在工具上自动捕捉每一次业务的变化，同时也要求开发人员在意识上自动进行业务变更通知。
2.2）离线系统数据校验
数据从在线业务系统到数据仓库再到数据产品的过程，需要在数据仓库这一层完成数据的清洗、加工。正是有了数据的加工，才有了数据仓库模型和数据仓库代码的建设。如何保障数据加过程中的质量，是离线数据仓库保障数据质量的一个重要环节。
在这些环节中，我们可以采用以下方式来保障数据质量：
3）数据处理风险
风险点监控主要是针对数据在日常运行过程中出现的风险进行监控并设置报警机制，主要包括在线数据和离线数据运行风险点监控。
3.1）数据质量监控
在线业务系统的数据生产过程需要保证数据质量，主要根据业务规则对数据进行监控。
随着业务负责程度的提升，会导致规则繁多、规则配置的运行成本增大，这时可以按照我们之前的数据资产等级有针对性的监控。
离线数据风险点监控主要包括对数据准确性和数据产出及时性的监控。对数据调度平台上所有数据处理调度进行监控。
3.2）数据及时性监控
在确保准确性的前提下，需要进一步让数据能够及时提供服务，否则数据的价值将大幅度降低，甚至没有价值，所以确保数据及时性也是保障数据质量重要的环节之一：
想要真正解决数据质量问题，就要明确业务需求并从需求开始控制数据质量，并建立数据质量管理机制。从业务出发做问题定义，由工具自动、及时发现问题，明确问题负责人，通过邮件、短信等方式进行通知，保证问题及时通知到负责人。跟踪问题整改进度，保证数据质量问题全过程的管理。
1）层次调用规范
稳定业务按照标准的数据流向进行开发，即ODS->DWD->DWS->APP。非稳定业务或探索型业务，可以遵循ODS->DWD->APP或者ODS->DWD->DWM->APP等模型。
在保障数据链路合理性后，也必须保证模型分层引用原则：
2）数据类型规范
需统一规定不同的数据的数据类型，严格按照规定的数据类型执行
3）数据冗余规范
宽表的冗余字段要确保：
4）NULL字段处理规范
5）指标口径规范
保证主题域内，指标口径一直，无歧义
通过数据分层，提供统一的数据出口，统一对外输出的数据口径，避免同一指标不同口径的情况。
5.1）指标梳理
指标口径的不一致使得数据使用的成本极高，经常出现口径打架、反复核对数据的问题。在数据治理中，我们将需要梳理到的所有指标进行进一步的梳理，明确其口径，如果存在两个指标名称相同，但口径不一致，先判断是否进行合并，如需要同时存在，那么在命名上必须能够区分开。
5.2）指标管理
指标管理分为原子指标维护和派生指标维护
原子指标：
派生指标：
6）数据表处理规范
6.1）增量表
新增数据，增量数据是上次导出之后的新数据
6.2）全量表
每天的所有的最新状态的数据
6.3）快照表
按日分区，记录截止数据日期的全量数据
6.4）拉链表
记录截止日期的全量数据
7）表的生命周期管理
这部分主要是通过对历史数据的等级划分与对表类型的划分生成响应的生命周期管理矩阵。
7.1）历史数据等级划分
主要将历史数据划分P0、P1、P2、P3四个等级，其具体定义如下：
7.2）表类型划分
通过上述历史数据等级划分与表类型划分，生成相应的生命周期矩阵，如下图所示：
1）ODS层设计规范
同步规范：
表分类与生命周期：
数据质量：
2）公共维度层设计规范
2.1）设计准则
2.2）存储及生命周期管理
建议按天分区
3）DWD明细层设计规范
3.1）存储及生命周期管理
3.2）事务型事实设计准则
3.3）周期快照事实表
3.4）累计快照事实表
4）DWS公共汇总层设计规范
数据仓库的性能是数据仓库建设是否成本的重要标准之一。聚集主要是通过汇总明细粒度数据来获得改进查询性能的效果。通过访问聚集效果，可以减少数据库在响应查询时必须执行的工作量，能够快速响应用户的查询，同时有利于减少不同访问明细数据带来的结果不一致的问题。
4.1）聚集的基本原则
4.2）聚集的基本步骤
4.3）公共汇总层设计原则
除了聚集基本的原则外，公共汇总层还必须遵循以下原则：
1）词根设计规范
词根属于数仓建设中的规范，属于元数据管理范畴，现在把这个划到数据治理的一部分。完整的数仓建设是包含数据治理的，只是现在谈到数仓偏向于数据建模，而谈到数据治理，更多的是关于数据规范、数据管理。
表命名，其实在很大程度上是对元数据描述的一种体现，表命名规范越完善，我们能从表名获取到的信息就越多。比如：一部分业务是关于货架的，英文名是rack,rack就是一个词根，那么我们所有表、字段等用到的地方都叫rack,不要叫成别的什么。这就是词根的作用，用来统一命名，表达同一个含义。指标体系中有很多“率”的指标，都可以拆解为*+率，率也就是rate，那么所有关于指标的地方都使用*+rate
词根可以用来统一表名、字段名、主题域名等
2）表命名规范
2.1）常规表
规范：分层前缀[dwd_dws_ads]_部门_业务域_主题域_自定义_更新周期|数据范围
业务域、主题域都可以用词根的方式枚举清楚，不断完善
2.2）中间表
中间表一般出现在job中，是job中临时存储的中间数据的表，中间表的作用域只限于当前Job执行过程中，Job一旦执行完成，该中间表的使命就完成了，是可以删除的，不过根据公司具体情况可以保留几天。
规范：mid_table_name_[0-9|dim]
table_name是任务中目标表的名字，通常来说一个任务只有一个目标表。这里加上表名，是为了防止自由发挥的时候表明冲突，而末尾可以自定义。
通常遇到需要补全维度的表，可以使用dim结尾
2.3）临时表
临时表是临时测试的表，是临时使用一次的表，就是暂时保持下数据看看，后续一般不再使用的表，是可以随时删除的表。
规范：tmp_xxx
只要加上tmp开头即可，其他名字随意，注意tmp开头的表不要用来实际使用，只是为了测试验证
2.4）维度表
维度表是基于底层数据，抽象出来的描述类的表。维度表可以自动从底层抽象出来，也可以手工来维护
规范：dim_xxx
维度表，统一以dim，后面加工，对该指标的描述
2.5）手工表
手工表是手工维护的表，手工初始化之后，一般不会自动改变，后面变更，也是手工来维护。
一般来说，手工的数据粒度是偏细的，所以暂时统一放在dwd层，后面如果有目标值或者其他类型的手工数据，再根据实际情况分层。