从ODS到ADS，万字详解数仓分层！

只有数据模型将数据有序的组织和存储起来之后，大数据才能得到高性能、低成本、高效率、高质量的使用。

1）清晰数据结构：每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。

数据关系条理化：源系统间存在复杂的数据关系，比如客户信息同时存在于核心系统、信贷系统、理财系统、资金系统，取数时该如何决策呢？数据仓库会对相同主题的数据进行统一建模，把复杂的数据关系梳理成条理清晰的数据模型，使用时就可避免上述问题了。

2）数据血缘追踪：简单来讲可以这样理解，我们最终给业务诚信的是一能直接使用的张业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。
3）数据复用，减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。数据的逐层加工原则，下层包含了上层数据加工所需要的全量数据，这样的加工方式避免了每个数据开发人员都重新从源系统抽取数据进行加工。通过汇总层的引人，避免了下游用户逻辑的重复计算， 节省了用户的开发时间和精力，同时也节省了计算和存储。极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低存储和计算成本。
4）把复杂问题简单化。讲一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。

5）屏蔽原始数据的(影响) ，屏蔽业务的影响。业务或系统发生变化时，不必改一次业务就需要重新接入数据。提高数据稳定性和连续性。

屏蔽源头业务系统的复杂性：源头系统可能极为繁杂，而且表命名、字段命名 、字段含义等可能五花八门，通过 DW 层来规范和屏蔽所有这些复杂性，保证下游数据用户使用数据的便捷和规范。如果源头系统业务发生变更，相关的变更由 DW 层来处理，对下游用户透明，无须改动下游用户的代码和逻辑。数据仓库的可维护性：分层的设计使得某一层的问题只在该层得到解决，无须更改下一层的代码和逻辑。大数据系统需要数据模型方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡！ETL(extractiontransformation loading)负责将分散的、异构数据源中的数据抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中。ETL 是实施数据仓库的核心和灵魂，ETL规则的设计和实施约占整个数据仓库搭建工作量的 60%～80%。

数据抽取（extraction），包括初始化数据装载和数据刷新：初始化数据装载主要关注的是如何建立维表、事实表，并把相应的数据放到这些数据表中；而数据刷新关注的是当源数据发生变化时如何对数据仓库中的相应数据进行追加和更新等维护(比如可以创建定时任务，或者触发器的形式进行数据的定时刷新)。

数据清洗（cleaning）主要是针对源数据库中出现的二义性、重复、不完整、违反业务或逻辑规则等问题的数据进行统一的处理。即清洗掉不符合业务或者没用的的数据。比如通过编写hive或者MR清洗字段中长度不符合要求的数据。

数据转换（transformation）主要是为了将数据清洗后的数据转换成数据仓库所需要的数据：来源于不同源系统的同一数据字段的数据字典或者数据格式可能不一样(比如A表中叫id,B表中叫ids)，在数据仓库中需要给它们提供统一的数据字典和格式，对数据内容进行归一化；另一方面，数据仓库所需要的某些字段的内容可能是源系统所不具备的，而是需要根据源系统中多个字段的内容共同确定。

数据加载（loading）是将最后上面处理完的数据导入到对应的存储空间里（hbase，mysql等）以方便给数据集市提供，进而可视化。 一般大公司为了数据安全和操作方便，都是自己封装的数据平台和任务调度平台，底层封装了大数据集群比如hadoop集群，spark集群，sqoop,hive,zookeepr,hbase等只提供web界面，并且对于不同员工加以不同权限，然后对集群进行不同的操作和调用。以数据仓库为例，将数据仓库分为逻辑上的几个层次。这样对于不同层次的数据操作，创建不同层次的任务，可以放到不同层次的任务流中进行执行（大公司一个集群通常每天的定时任务有几千个等待执行，甚至上万个，所以划分不同层次的任务流，不同层次的任务放到对应的任务流中进行执行，会更加方便管理和维护）。数仓层内部的划分不是为了分层而分层，分层是为了解决 ETL 任务及工作流的组织、数据的流向、读写权限的控制、不同需求的满足等各类问题。业界较为通行的做法将整个数仓层又划分成了 DWD、DWT、DWS、DIM、DM等很多层。然而我们却始终说不清楚这几层之间清晰的界限是什么，或者说我们能说清楚它们之间的界限，复杂的业务场景却令我们无法真正落地执行。所以数据分层这块一般来说三层是最基础的，至于DW层如何进行切分，是根据具体的业务需求和公司场景自己去定义。

数据中台包含的内容很多，对应到具体工作中的话，它可以包含下面的这些内容：

系统架构：以Hadoop、Spark等组件为中心的架构体系

数据架构：顶层设计，主题域划分，分层设计，ODS-DW-ADS

数据建模：维度建模，业务过程-确定粒度-维度-事实表

数据管理：资产管理，元数据管理、质量管理、主数据管理、数据标准、数据安全管理

辅助系统：调度系统、ETL系统、监控系统

数据服务：数据门户、机器学习数据挖掘、数据查询、分析、报表系统、可视化系统、数据交换分享下载
数据仓库标准上可以分为四层。但是注意这种划分和命名不是唯一的，一般数仓都是四层，但是不同公司可能叫法不同。但是核心的理念都是从四层数据模型而来。

数据引入层（ODS，Operational Data Store，又称数据基础层）：将原始数据几乎无处理地存放在数据仓库系统中，结构上与源系统基本保持一致，是数据仓库的数据准备区。这一层的主要职责是将基础数据同步、存储。一般来说 ODS 层的数据和源系统的数据是同构的，主要目的是简化后续数据加工处理的工作。从数据粒度上来说 ODS 层的数据粒度是细的。ODS 层的表通常包括两类，一个用于存储当前需要加载的数据，一个用于存储处理完后的历史数据。历史数据一般保存 3-6 个月后需要清除，以节省空间。但不同的项目要区别对待，如果源系统的数据量不大，可以保留更长的时间，甚至全量保存。

注意：

在这层，理应不是简单的数据接入，而是要考虑一定的数据清洗，比如异常字段的处理、字段命名规范化、时间字段的统一等，一般这些很容易会被忽略，但是却至关重要。特别是后期我们做各种特征自动生成的时候，会十分有用。

有的公司ODS层不会做太多数据过滤处理,会放到DWD层来处理。有的公司会在一开始时就在ODS层做数据相对精细化的过滤.这个并没有明确规定,看每个公司自己的想法和技术规范。

数据来源区分

数据按照时间分区存储,一般是按照天,也有公司使用年、月、日三级分区做存储的。

进行最基本的数据处理,如格式错误的丢弃,关键信息丢失的过滤掉等等。

数据实时离线

离线方面：每日定时任务型：跑批任务，业务库，比如我们典型的日计算任务，这里经常会使用 Sqoop 来抽取，比如我们每天定时抽取一次。每天凌晨算前一天的数据，早上起来看报表。这种任务经常使用 Hive、Spark 来计算，最终结果写入 Hive、Hbase、Mysql、Es 或者 Redis 中。

实时数据：日志埋点数据或者业务库，这部分主要是各种实时的系统使用，比如我们的实时推荐、实时用户画像，一般我们会用 Spark Streaming、Flink 来计算，最后会落入 Es、Hbase 或者 Redis 中。数据源是业务数据库，可以考虑用 Canal 监听 Mysql 的 Binlog，实时接入即可，然后也是收集到消息队列中，最终再由 Camus 拉取到 HDFS。

1）数据主要来源：

数据源是业务数据库，公司所有的系统产生的数据

是通过在客户端埋点上报，收集用户的行为日志，以及一些后端日志的日志类型数据源。对于埋点行为日志来说，一般会经过一个这样的流程，首先数据会上报到 Nginx 然后经过 Flume 收集，然后存储到 Kafka 这样的消息队列，然后再由实时或者离线的一些拉取的任务，拉取到我们的离线数据仓库 HDFS

外部数据（包括合作数据以及爬虫获得的数据），将所采集的数据汇总到一起

2）数据存储策略（增量、全量）

实际应用中，可以选择采用增量、全量存储或拉链存储的方式。

增量存储：

为了满足历史数据分析需求，您可以在ODS层表中添加时间维度作为分区字段。以天为单位的增量存储，以业务日期作为分区，每个分区存放日增量的业务数据。

说明：交易、日志等事务性较强的ODS表适合增量存储方式。这类表数据量较大，采用全量存储的方式存储成本压力大。此外，这类表的下游应用对于历史全量数据访问的需求较小（此类需求可通过数据仓库后续汇总后得到）。例如，日志类ODS表没有数据更新的业务过程，因此所有增量分区UNION在一起就是一份全量数据。

>>举例如下：

1月1日，用户A访问了A公司电商店铺B，A公司电商日志产生一条记录t1。1月2日，用户A又访问了A公司电商店铺C，A公司电商日志产生一条记录t2。采用增量存储方式，t1将存储在1月1日这个分区中，t2将存储在1月2日这个分区中。

1月1日，用户A在A公司电商网购买了B商品，交易日志将生成一条记录t1。1月2日，用户A又将B商品退货了，交易日志将更新t1记录。采用增量存储方式，初始购买的t1记录将存储在1月1日这个分区中，更新后的t1将存储在1月2日这个分区中。

全量存储：

以天为单位的全量存储，以业务日期作为分区，每个分区存放截止到业务日期为止的全量业务数据。

>>举例如下：

例如，1月1日，卖家A在A公司电商网发布了B、C两个商品，前端商品表将生成两条记录t1、t2。1月2日，卖家A将B商品下架了，同时又发布了商品D，前端商品表将更新记录t1，同时新生成记录t3。采用全量存储方式， 在1月1日这个分区中存储t1和t2两条记录，在1月2日这个分区中存储更新后的t1以及t2、t3记录。

说明：对于小数据量的缓慢变化维度数据，例如商品类目，可直接使用全量存储。

拉链存储：

拉链存储通过新增两个时间戳字段（start_dt和end_dt），将所有以天为粒度的变更数据都记录下来，通常分区字段也是这两个时间戳字段。

>>举例如下：

方案

概念：又称为接口层(stage)，用于存储每天的增量数据和变更数据

数据生成方式：直接从kafka接收源数据，需要业务表每天生成update,delete,inseret数据，只生成insert数据的业务表，数据直接入明细层。

讨论方案：只把canal日志直接入缓冲层，如果其它有拉链数据的业务，也入缓冲层。

日志存储方式：使用impala外表，parquet文件格式，方便需要MR处理的数据读取。

日志删除方式：长久存储，可只存储最近几天的数据。讨论方案：直接长久存储。

表schema：一般按天创建分区，partitioned by 一般都是按照天进行存放。

库与表命名。库名：ods,表名：初步考虑格式为ods日期业务表名,待定。 数据仓库层(DW)层：数据仓库层是我们在做数据仓库时要核心设计的一层，本层将从 ODS 层中获得的数据按照主题建立各种数据模型，每一个主题对应一个宏观的分析领域，数据仓库层排除对决策无用的数据，提供特定主题的简明视图。在DW层会保存BI系统中所有的历史数据，例如保存10年的数据。DW层又细分为维度层（DIM）、明细数据层（DWD）和汇总数据层（DWS），采用维度模型方法作为理论基础， 可以定义维度模型主键与事实模型中外键关系，减少数据冗余，也提高明细数据表的易用性。在汇总数据层同样可以关联复用统计粒度中的维度，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。

维度层（DIM，Dimension）：以维度作为建模驱动，基于每个维度的业务含义，通过添加维度属性、关联维度等定义计算逻辑，完成属性定义的过程并建立一致的数据分析维表。为了避免在维度模型中冗余关联维度的属性，基于雪花模型构建维度表。

明细数据层（DWD，Data Warehouse Detail）：以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细事实表。可将某些重要属性字段做适当冗余，也即宽表化处理。

汇总数据层（DWS，Data Warehouse Summary）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标表。以宽表化手段物理化模型，构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。 1）公共维度层（DIM，Dimension）公共维度汇总层（DIM）主要由维度表（维表）构成。维度是逻辑概念，是衡量和观察业务的角度。维表是根据维度及其属性将数据平台上构建的表物理化的表，采用宽表设计的原则。因此，构建公共维度汇总层（DIM）首先需要定义维度。

高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。

低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。 完成维度定义后，您就可以对维度进行补充，进而生成维表了。

维表的设计需要注意：

建议维表单表信息不超过1000万条。

维表与其他表进行Join时，建议您使用Map Join。

避免过于频繁的更新维表的数据。

在设计维表时，您需要从下列方面进行考虑：

维表中数据的稳定性。例如A公司电商会员通常不会出现消亡，但会员数据可能在任何时候更新，此时要考虑创建单个分区存储全量数据。如果存在不会更新的记录，您可能需要分别创建历史表与日常表。日常表用于存放当前有效的记录，保持表的数据量不会膨胀；历史表根据消亡时间插入对应分区，使用单个分区存放分区对应时间的消亡记录。

是否需要垂直拆分。如果一个维表存在大量属性不被使用，或由于承载过多属性字段导致查询变慢，则需考虑对字段进行拆分，创建多个维表。

是否需要水平拆分。如果记录之间有明显的界限，可以考虑拆成多个表或设计成多级分区。

核心的维表产出时间通常有严格的要求。

设计维表的主要步骤如下：

完成维度的初步定义，并保证维度的一致性。

确定主维表（中心事实表，本教程中采用星型模型）。此处的主维表通常是数据引入层（ODS）表，直接与业务系统同步。例如，s_auction是与前台商品中心系统同步的商品表，此表即是主维表。

确定相关维表。数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。以商品维度为例，根据对业务逻辑的梳理，可以得到商品与类目、卖家、店铺等维度存在关联关系。

确定维度属性，主要包括两个阶段。第一个阶段是从主维表中选择维度属性或生成新的维度属性；第二个阶段是从相关维表中选择维度属性或生成新的维度属性。以商品维度为例，从主维表（s_auction）和类目 、卖家、店铺等相关维表中选择维度属性或生成新的维度属性。

公共维度汇总层（DIM）维表规范

命名规范：dim_{业务板块名称/pub}_{维度定义}[_{自定义命名标签}]

所谓pub是与具体业务板块无关或各个业务板块都可公用的维度，如时间维度。

例如：公共区域维表dim_pub_area，商品维表dim_asale_itm 2）DWD（data warehouse detail）数据明细层，明细粒度事实层

DWD（Data Warehouse Detail 明细粒度事实层），是业务层与数据仓库的隔离层，这一层主要解决一些数据质量问题和数据的完整度问题。以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。明细粒度事实层的表通常也被称为逻辑事实表。该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证，在ODS的基础上对数据进行加工处理，提供更干净的数据。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，当一个维度没有数据仓库需要的任何数据时，就可以退化维度，将维度退化至事实表中，减少事实表和维表的关联。例如：订单id,这种量级很大的维度，没必要用一张维度表来进行存储，而我们一般在进行数据分析时订单id又非常重要，所以我们将订单id冗余在事实表中，这种维度就是退化维度。
DWD层做了哪些事？

①数据清洗过滤

去除废弃字段,去除格式错误的信息

去除丢失了关键字段的信息

过滤核心字段无意义的数据，比如订单表中订单id为null，支付表中支付id为空

对手机号、身份证号等敏感数据脱敏

去除不含时间信息的数据(这个看公司具体业务,但一般数据中都会带上时间戳,这样方便后续处理时,进行时间维度上信息分析处理和提取)

有些公司还会在这一层将数据打平,不过这具体要看业务需求.这是因为kylin适合处理展平后数据,不适合处理嵌套的表数据信息

有些公司还会将数据session做切割,这个一般是app的日志数据,其他业务场景不一定适合.这是因为app有进入后台模式,例如用户上午打开app用了10分钟,然后app切入后台,晚上再打开,这时候session还是一个,实际上应该做切割才对.(也有公司会记录app进入后台,再度进入前台的记录,这样来做session切割)

数据规范化,因为大数据处理的数据可能来资源公司不同部门,不同项目,不同客户端,这时候可能相同业务数据字段,数据类型,空值等都不一样,这时候需要在DWD层做抹平.否则后续处理使用时,会造成很大的困扰

如boolean,有使用0 1标识,也有使用true false标识的

如字符串空值,有使用"",也有使用null,的,统一为null即可

如日期格式,这种就差异性更大,需要根据实际业务数据决定,不过一般都是格式化为YYYY-MM-dd HH:mm:ss 这类标准格式

清洗掉多少数据算合理：1万条数据清洗掉1条。

②数据映射,转换

将GPS经纬度转换为省市区详细地址。业界常见GPS快速查询一般将地理位置知识库使用geohash映射,然后将需要比对的GPS转换为geohash后跟知识库中geohash比对,查找出地理位置信息当然,也有公司使用open api,如高德地图,百度地图的api进行GPS和地理位置信息映射,但这个达到一定次数需要花钱,所以大家都懂的

会将IP地址也转换为省市区详细地址。这个有很多快速查找库,不过基本原理都是二分查找,因为ip地址可以转换为长整数.典型的如ip2region库

将时间转换为年,月,日甚至周,季度维度信息

明细粒度事实表设计原则：

一个明细粒度事实表仅和一个维度关联。

尽可能包含所有与业务过程相关的事实 。

只选择与业务过程相关的事实。

分解不可加性事实为可加的组件。

在选择维度和事实之前必须先声明粒度。

在同一个事实表中不能有多种不同粒度的事实。

事实的单位要保持一致。粒度

谨慎处理Null值。

使用退化维度提高事实表的易用性。

明细粒度事实表整体设计流程

方案

概念：是数据仓库的细节数据层，是对STAGE层数据进行沉淀，减少了抽取的复杂性，同时ODS/DWD的信息模型组织主要遵循企业业务事务处理的形式，将各个专业数据进行集中，明细层跟stage层的粒度一致，属于分析的公共资源

数据生成方式：部分数据直接来自kafka，部分数据为接口层数据与历史数据合成。canal日志合成数据的方式待研究。

讨论方案：canal数据的合成方式为：每天把明细层的前天全量数据和昨天新数据合成一个新的数据表，覆盖旧表。同时使用历史镜像，按周/按月/按年 存储一个历史镜像到新表。

日志存储方式：直接数据使用impala外表，parquet文件格式，canal合成数据为二次生成数据，建议使用内表，下面几层都是从impala生成的数据，建议都用内表+静态/动态分区。

日志删除方式：长久存储。

表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。

库与表命名。库名：ods,表名：初步考虑格式为ods日期业务表名,待定。

旧数据更新方式：直接覆盖

明细粒度事实层（DWD）规范

命名规范为：dwd_{业务板块/pub}_{数据域缩写}_{业务过程缩写}[_{自定义表命名标签缩写}] _{单分区增量全量标识}

pub表示数据包括多个业务板块的数据。单分区增量全量标识通常为：i表示增量，f表示全量。

例如：dwd_asale_trd_ordcrt_trip_di（A电商公司航旅机票订单下单事实表，日刷新增量），dwd_asale_itm_item_df（A电商商品快照事实表，日刷新全量）。 3）DWS（ data warehouse service）数据服务层，汇总层宽表

基于 DWD 明细数据层，我们会按照一些分析场景、分析实体等去组织我们的数据，组织成一些分主题的汇总数据层 DWS。明细粒度 ==> 汇总粒度DWS层（数据汇总层）宽表，面向主题的汇总，维度相对来说比较少，DWS是根据DWD层基础数据按各个维度ID进行粗粒度汇总聚合，如按交易来源，交易类型进行汇合。整合汇总成分析某一个主题域的服务数据，一般是宽表。以DWD为基础，按天进行轻度汇总。统计各个主题对象的当天行为，（例如，购买行为，统计商品复购率）。该层数据表会相对比较少，大多都是宽表(一张表会涵盖比较多的业务内容，表中的字段较多)。按照主题划分，如订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。融合多个中间层数据，基于主题形成事实表，比如用户事实表、渠道事实表、终端事实表、资产事实表等等，事实表一般是宽表，在本层上实现企业级数据的一致性。

DWS层做了哪些事？

DWS将DWD层的数据按主题进行汇总，按照主题放到一个表中，

比如用户主题下会将用户注册信息、用户收货地址、用户的征信数据放到同一张表中，而这些在DWD层是对应多张表的,按照业务划分，如流量、订单、用户等，生成字段比较多的宽表。

方案

概念：又称数据集市或宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。

数据生成方式：由轻度汇总层和明细层数据计算生成。

日志存储方式：使用impala内表，parquet文件格式。

表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。

库与表命名。库名：dws, 表名：初步考虑格式为：dws日期业务表名,待定。

旧数据更新方式：直接覆盖

聚集是指针对原始明细粒度的数据进行汇总。DWS公共汇总层是面向分析对象的主题聚集建模。在本教程中，最终的分析目标为：最近一天某个类目（例如：厨具）商品在各省的销售总额、该类目Top10销售额商品名称、各省用户购买力分布。因此，我们可以以最终交易成功的商品、类目、买家等角度对最近一天的数据进行汇总。

注意：

聚集是不跨越事实的。聚集是针对原始星形模型进行的汇总。为获取和查询与原始模型一致的结果，聚集的维度和度量必须与原始模型保持一致，因此聚集是不跨越事实的。

聚集会带来查询性能的提升，但聚集也会增加ETL维护的难度。当子类目对应的一级类目发生变更时，先前存在的、已经被汇总到聚集表中的数据需要被重新调整。

此外，进行DWS层设计时还需遵循以下原则：

数据公用性：需考虑汇总的聚集是否可以提供给第三方使用。您可以判断，基于某个维度的聚集是否经常用于数据分析中。如果答案是肯定的，就有必要把明细数据经过汇总沉淀到聚集表中。

不跨数据域。数据域是在较高层次上对数据进行分类聚集的抽象。数据域通常以业务过程进行分类，例如交易统一划到交易域下， 商品的新增、修改放到商品域下。

区分统计周期。在表的命名上要能说明数据的统计周期，例如_1d表示最近1天，td表示截至当天，nd表示最近N天。

公共汇总事实表规范

命名规范：dws_{业务板块缩写/pub}_{数据域缩写}_{数据粒度缩写}[_{自定义表命名标签缩写}]_{统计时间周期范围缩写}。

关于统计实际周期范围缩写，缺省情况下，离线计算应该包括最近一天（_1d），最近N天（_nd）和历史截至当天（_td）三个表。如果出现_nd的表字段过多需要拆分时，只允许以一个统计周期单元作为原子拆分。即一个统计周期拆分一个表，例如最近7天（_1w）拆分一个表。不允许拆分出来的一个表存储多个统计周期。

对于小时表（无论是天刷新还是小时刷新），都用_hh来表示。

对于分钟表（无论是天刷新还是小时刷新），都用_mm来表示。

举例如下：

dws_asale_trd_byr_subpay_1d（买家粒度交易分阶段付款一日汇总事实表）

dws_asale_trd_byr_subpay_td（买家粒度分阶段付款截至当日汇总表）

dws_asale_trd_byr_cod_nd（买家粒度货到付款交易汇总事实表）

dws_asale_itm_slr_td（卖家粒度商品截至当日存量汇总表）

dws_asale_itm_slr_hh（卖家粒度商品小时汇总表）---维度为小时

dws_asale_itm_slr_mm（卖家粒度商品分钟汇总表）---维度为分钟

数据应用层（ADS，Application Data Store）：存放数据产品个性化的统计指标数据，报表数据。主要是提供给数据产品和数据分析使用的数据，通常根据业务需求，划分成流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。从数据粒度来说，这层的数据是汇总级的数据，也包括部分明细数据。从数据的时间跨度来说，通常是DW层的一部分，主要的目的是为了满足用户分析的需求，而从分析的角度来说，用户通常只需要分析近几年的即可。从数据的广度来说，仍然覆盖了所有业务数据。

方案

概念：应用层是根据业务需要，由前面三层数据统计而出的结果，可以直接提供查询展现，或导入至Mysql中使用。

数据生成方式：由明细层、轻度汇总层，数据集市层生成，一般要求数据主要来源于集市层。

日志存储方式：使用impala内表，parquet文件格式。

表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。

库与表命名。库名：暂定ads，另外根据业务不同，不限定一定要一个库。

旧数据更新方式：直接覆盖。

项目实战：ADS 层复购率统计

CREATE TABLE app_usr_interact( user_id string COMMENT '用户id',nickname string COMMENT '用户昵称',register_date string COMMENT '注册日期',register_from string COMMENT '注册来源',remark string COMMENT '细分渠道',province string COMMENT '注册省份',pl_cnt bigint COMMENT '评论次数',ds_cnt bigint COMMENT '打赏次数',sc_add bigint COMMENT '添加收藏',sc_cancel bigint COMMENT '取消收藏',gzg_add bigint COMMENT '关注商品',gzg_cancel bigint COMMENT '取消关注商品',gzp_add bigint COMMENT '关注人',gzp_cancel bigint COMMENT '取消关注人',buzhi_cnt bigint COMMENT '点不值次数',zhi_cnt bigint COMMENT '点值次数',zan_cnt bigint COMMENT '点赞次数',share_cnts bigint COMMENT '分享次数',bl_cnt bigint COMMENT '爆料数',fb_cnt bigint COMMENT '好价发布数',online_cnt bigint COMMENT '活跃次数',checkin_cnt bigint COMMENT '签到次数',fix_checkin bigint COMMENT '补签次数',house_point bigint COMMENT '幸运屋金币抽奖次数',house_gold bigint COMMENT '幸运屋积分抽奖次数',pack_cnt bigint COMMENT '礼品兑换次数',gold_add bigint COMMENT '获取金币',gold_cancel bigint COMMENT '支出金币',surplus_gold bigint COMMENT '剩余金币',event bigint COMMENT '电商点击次数',gmv_amount bigint COMMENT 'gmv',gmv_sales bigint COMMENT '订单数')PARTITIONED BY( dt string)--stat_dtdate COMMENT '互动日期',

①如何分析用户活跃？

在启动日志中统计不同设备 id 出现次数。

②如何分析用户新增?

用活跃用户表 left join 用户新增表，用户新增表中 mid 为空的即为用户新增。

③如何分析用户 1 天留存？

留存用户=前一天新增 join 今天活跃

用户留存率=留存用户/前一天新增

④如何分析沉默用户？

(登录时间为 7 天前,且只出现过一次)

按照设备 id 对日活表分组，登录次数为 1，且是在一周前登录。

⑤如何分析本周回流用户？

本周活跃 left join 本周新增 left join 上周活跃，且本周新增 id 和上周活跃 id 都为 null。

⑥如何分析流失用户？

(登录时间为 7 天前)

按照设备 id 对日活表分组，且七天内没有登录过。

⑦如何分析最近连续 3 周活跃用户数？

按照设备 id 对周活进行分组，统计次数大于 3 次。

⑧如何分析最近七天内连续三天活跃用户数？

查询出最近 7 天的活跃用户，并对用户活跃日期进行排名

计算用户活跃日期及排名之间的差值

对同用户及差值分组，统计差值个数

将差值相同个数大于等于 3 的数据取出，然后去重，即为连续 3 天及以上活跃的用户 ADS应用层优先调用数据仓库公共层数据。如果已经存在CDM层数据，不允许ADS应用层跨过CDM中间层从ODS层重复加工数据。CDM中间层应该积极了解应用层数据的建设需求，将公用的数据沉淀到公共层，为其他数据层次提供数据服务。同时，ADS应用层也需积极配合CDM中间层进行持续的数据公共建设的改造。避免出现过度的ODS层引用、不合理的数据复制和子集合冗余。

总体遵循的层次调用原则如下：

ODS层数据不能直接被应用层任务引用。如果中间层没有沉淀的ODS层数据，则通过CDM层的视图访问。CDM层视图必须使用调度程序进行封装，保持视图的可维护性与可管理性。

CDM层任务的深度不宜过大（建议不超过10层）。

一个计算刷新任务只允许一个输出表，特殊情况除外。

如果多个任务刷新输出一个表（不同任务插入不同的分区），DataWorks上需要建立一个虚拟任务，依赖多个任务的刷新和输出。通常，下游应该依赖此虚拟任务。

CDM汇总层优先调用CDM明细层，可累加指标计算。CDM汇总层尽量优先调用已经产出的粗粒度汇总层，避免大量汇总层数据直接从海量的明细数据层中计算得出。

CDM明细层累计快照事实表优先调用CDM事务型事实表，保持数据的一致性产出。

有针对性地建设CDM公共汇总层，避免应用层过度引用和依赖CDM层明细数据。