摘要：将数据模型分为三层：数据运营层（ ODS ）、数据仓库层（DW）和数据应用层（APP），ODS层存放的是接入的原始数据，DW层是存放我们要重点设计的数据仓库中间层数据，APP是面向业务定制的应用数据。
将数据模型分为三层：数据运营层（ ODS ）、数据仓库层（DW）和数据应用层（APP），ODS层存放的是接入的原始数据，DW层是存放我们要重点设计的数据仓库中间层数据，APP是面向业务定制的应用数据。
1.源数据层ODS（Operational Data Store）
直接加载原始日志、数据，数据保持原貌不做处理(字段不变)。
“面向主题的”数据运营层/准备区，也叫ODS层。源头系统的数据表通常会原封不动的存储一份(保持数据的完整性)，它们是后续数据仓库层加工数据的来源，因此ODS层的表结构会和原始数据保持一致。需要存储的数据量是最大的，存储的数据也是最原始，最真实未经过太多处理的数据。ODS层建立表时,如果使用hive进行处理,一般建立外部表，外部表的特点除了文件地址可以指定外，删表时数据不会被删除。
ODS层数据还起到一个数据备份作用。如果是比较特殊行业，在ODS层的数据会保留一年甚至多年具体还看数据量和存储压力以及存储预算决定。数据采用压缩，减少磁盘存储空间。压缩采用 LZO，压缩比是 100g 数据压缩完 10g 左右。创建分区表，防止后续的全表扫描。(1)ODS层数据同步
需要将业务系统的数据抽取到ODS表中。一般来说，数据同步的方式大概可以分为三大类：文件抽取、数据库表的抽取和原始日志的抽取。
①文件抽取——很少使用
通常情况下，ODS层表的存储位置与业务系统表的存储位置是不一样的，比如业务表存在MySQL中，而ODS层存储在Hive中。另外，有的时候，ODS层需要对接多个不同类型的业务系统库，比如DB2、Oracle、Mysql等等，一种比较简单实用的做法是和各个业务系统约定好数据接口，并让业务系统按照数据接口格式生成数据文件和完结标示文件给到ODS。
这种方式有两个明显的优势：一方面可以降低ODS处理多种类型数据库系统能力需求，另一方面也减少了对业务系统的性能影响。但是这种方式也存在一些不足：数据的抽取过程和加载过程是分开的，由业务系统和ODS分别负责，同时接口新增和变更比较麻烦，需要较大的沟通维护成本，另外，数据落地到文件增加了额外的上传下载工作，会造成效率比较低。
②直连同步
直连同步是指通过定义好的规范接口API和基于动态链接库的方式直接连接业务库，比如ODBC/JDBC等规定了统一的标准接口，不同的数据库基于这套标准提供规范的驱动，从而支持完全相同的函数调用和SQL实现。比如经常使用的Sqoop就是采取这种方式进行批量数据同步的。直连同步的方式配置十分简单，很容易上手操作，比较适合操作型业务系统的数据同步，但是会存在以下问题：
数据同步时间：随着业务规模的增长，数据同步花费的时间会越来越长，无法满足下游数仓生产的时间要求。性能瓶颈：直连数据库查询数据，对数据库影响非常大，容易造成慢查询，如果业务库没有采取主备策略，则会影响业务线上的正常服务，如果采取了主备策略，虽然可以避免对业务系统的性能影响，但当数据量较大时，性能依然会很差。抽取增量数据需要依靠修改业务系统，新增时间戳字段，并且按时间戳增量抽取的数据准确性不能得到保障，业务系统做数据补丁不更新时间戳字段将会导致漏数；实时性差，只能在某个时刻抽取数据，不能满足准实时数据需求；在实际的生产过程中，这种方式的数据同步经常被使用，值得注意的是：数据库直连抽取比较适用于小批量表的数据抽取，对于大批量的数据而言，性能会比较差。
③日志解析
数据库日志抽取是指通过分析数据库日志，将业务系统的DDL和DML语句在一个镜像系统还原，并通过数据流的方式对外提供实时数据服务。所谓日志解析，即解析数据库的变更日志，比如MySQL的Binlog日志，Oracle的归档日志文件。通过读取这些日志信息，收集变化的数据并将其解析到目标存储中即可完成数据的实时同步。这种读操作是在操作系统层面完成的，不需要通过数据库，因此不会给源数据库带来性能上的瓶颈。
由于是数据库日志抽取是获取所有的变更记录，落地到ODS表的时候我们需要根据主键去重按照日志时间倒排序获取最后状态的变化情况。通常使FULL OUTER JOIN全外连接的方式进行Merge数据。
数据库日志解析的同步方式可以实现实时与准实时的同步，延迟可以控制在毫秒级别的，其最大的优势就是性能好、效率高，不会对源数据库造成影响，目前，从业务系统到数据仓库中的实时增量同步，广泛采取这种方式。
当然，任何方式都不是完美的，使用日志解析的方式进行数据同步也会存在一些已知的问题：比如在业务系统做批量补数时会造成数据更新量超过处理的能力，从而导致数据延迟。另外，这种方式需要额外补数一个实时抽取的系统，从而也增加了投入和处理的复杂性。
④该如何选择同步方式
在实际的生产环境中，直连同步和日志解析是非常普遍的两种数据同步方式，随着实时技术的发展，使得实时数据同步的方式变得越来越方便，越来越多的企业开始尝试使用日志解析的方式进行数据同步。这里需要注意的是，每种方式都有其优缺点及适用的场景，找到合适的方式就是最好的方式。
另外，数仓的建设是为业务服务的，应该把时间和精力放在如何支持业务、如何发挥数仓的价值、如何用数据为业务提供支持决策上来，深入理解业务和数据才是数仓建设的第一要义。
(2)ODS层规范
通常而言，ODS层表跟业务系统保持一致，但又不完全等同于业务系统。在设计ODS物理表时，在表命名、数据存储等方面都需要遵循一定的准则。
比如：不管是表命名还是字段命名尽量和业务系统保持一致，但是需要通过额外的标识来区分增量和全量表，”_delta”来标识该表为增量表。
另外，为了满足历史数据分析需求，我们需要在ODS表中加一个时间维度，这个维度通常在ODS表中作为分区字段。如果是增量存储，则可以按天为单位使用业务日期作为分区，每个分区存放日增量的业务数据。如果是全量存储，只可以按天为单位使用业务日期作为分区，每个分区存储截止到当前业务时间的全量快照数据。
①命名规范
命名采用前缀+业务系统表名的方式字段名与业务系统字段名一致字段类型尽可能保持一致增量表利用后缀标识，如ODS__业务系统缩写_业务系统表名_delta按小时同步的增量表，利用后缀标识hh，如ODS_业务系统表名_delta_hh表名长度不超过三十个字符②数据同步规范
对于数据量较大的业务数据表，如果采用增量同步的方式，则需同时建立增量表和全量表对于日志、文件等半结构化数据，不仅要存储原始数据，还要存储结构化后的数据对于非结构化数据，不保留原始文件，只保留对原始数据文件的描述，比如地址、名称、类型、分辨率等(3)ODS层常见的问题
实时和准实时数据需求、数据飘移处理、巨型数据量表处理、如何有效控制数据存储。
①实时性
实时数据仓库的主要思想就是：在数据仓库中，将保存的数据分为两类，一种为静态数据，一种为动态数据，静态数据满足用户的查询分析要求；而动态数据就是为了适应实时性，数据源中发生的更新可以立刻传送到数据仓库的动态数据中，再经过响应的转换，满足实时的要求。
由于实时处理的特殊性及复杂性，很多情况下实时分析是建立在ODS上而不是数据仓库上，因为ODS处理逻辑简单，数据链路相对较短，产出更快。
根据表的刷新频率，可以将ODS层的表分为三大类：
实时ODS接近实时地与业务库的数据保持同步刷新，主要用于实时分析计算，比如实时的反欺诈，天猫双11实时大屏等等。这类表的ETL是实时进行的，一般情况下，这类表会存储在消息中间件中，比如Kafka，指的注意的是：要求涉及的业务过程不能过多，处理的业务逻辑不能过于复杂。这类ODS的表一般只是用于实时计算，相比批处理的表而言，其维护成本是相对较高的。准实时ODS例如15分钟到1小时刷新一次,这类ODS比实时ODS成本要低些，基本可以满足大部分的准实时需求。并且可以根据实际需求调整刷新频率，具有较好的灵活性。在做处理这类准实时的ODS表时，需要特别注意ETL任务的产出效率，通常这类任务的产出时间最多不能超过ODS表的刷新周期时间。例如小时级别的表，任务不能超过1个小时。传统ODS这是离线数仓最常见的一种表，即T+1，其数据一天刷新一次,可以利用业务系统的空闲时间进行刷新（通常是每天凌晨0-2点）,可实现所有业务系统的数据集成和刷新。刷新频率的下降也给系统有更多的时间进行数据更正和清洗。该类ODS层的表是最容易维护的。②数据漂移
所谓数据漂移，指的是：ODS表的同一个业务日期数据中包含前一天或后一天凌晨附近的数据或者丢失当天的变更数据。由于ODS需要承接面向历史的细节数据查询需求，这就需要物理落地到数据仓库的ODS表按时间段来切分进行分区存储，通常的做法是按某些时间戳字段来切分，实际往往由于时间戳字段的准确性问题导致数据飘移问题的发生。
在实际的生产过程中，以上三个时间戳往往会存在差异：比如由于网络或者系统压力问题，log_time或者modified_time会晚于proc_time。当时用数据库记录更新时间或者数据库日志更新时间进行切分数据分区时，有可能会导致凌晨时间产生的数据记录漂移到后一天，如果使用业务时间进行限制，则会遗漏很多其他过程的变化记录。
那么，该如何解决上述的问题呢？常见的方式有两种：
多冗余数据:基本原则是宁多勿少，即ODS每个时间分区中向前向后都多冗余一些数据，具体的数据切分让下游根据自身不同的业务场景根据不同的业务时间proc_time来限制。这种情况同样也会存在一些误差：比如一个订单是在6.1日支付的，但在6.2号凌晨申请退款关闭了该条订单，那该条订单记录就会被更新，下游再统计支付订单状态时会错误统计。多个时间戳字段限制时间来获取相对准确的数据首先确保数据不遗漏，根据log_time分别冗余前一天最后15分钟的数据和后一天凌晨开始15分钟的数据，并用modified_time过滤非当天数据，此时会过滤掉一部分后一天凌晨开始15分钟的数据，但是还是会冗余一部分前一天的数据，由于log数据保存了多个状态的数据，所以还需要根据log_time进行降序排列，获取最新状态的记录，这样就去掉了中间状态的数据。下一步就是处理漂移到后一天的数据，根据log_time取后一天的15分钟数据；针对此数据，按照主键根据log_time作升序排列去重。因为我们需要获取的最接近当天记录变化情况（数据库日志数据将保留所有变化的数据，但是落地到ODS的表是需要根据主键去重获取最后状态的变化情况)，这样就会把漂移到后一天的最初状态的数据筛选出来了。最后将前两步的结果数据作全外连接，限定业务时间proc_time来获取我们需要的数据③数据存储
避免重复抽取数据，必须建立统一的ODS层，收拢权限，由专门的团队统一管控。表的生命周期管理一般而言，全量表保存3~7天，增量表要永久保存无下游任务的表比如一些表上源表不产生数据了，或者该表没有被下游任务使用，这种情况下要及时下线同步任务，避免造成资源的浪费(4)数据质量
对分区空数据进行监控；对枚举类型字段， 进行枚举值变化和分布监控；ods 表数据量级和记录数做环比监控；ods 全表都必须要有注释。2.数据仓库层（DW）
命名规则适合采用[层次][主题][子主题][内容描述][分表规则]
DW 层的数据应该是一致的、准确的、干净的数据，即对源系统数据进行了清洗（去除了杂质）后的数据。是数据仓库的主体，在这里ODS层中获得的数据按照主题建立各种数据模型。DW层的表通常包括两类，一个用于存储当前需要加载的数据，一个用于存储处理完后的历史数据。
(1)数据明细层dwd(Data Warehouse Detail) 对ODS层数据进行清洗
DWD又叫做数据明细表，会有ETL，逻辑会比较复杂，这一层主要解决一些数据质量问题和数据的完整度问题，这也是离线批处理的第一步。
DWD层的数据单纯从条数上看可能和ODS差不多，但是经过清洗过后，占用的存储空间会小很多。该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。另外，在该层也会做一部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性
清洗的手段：Sql、mr、rdd、kettle、Python等等清洗掉多少数据算合理：1 万条数据清洗掉 1 条。脱敏：对手机号、身份证号等敏感数据脱敏维度退化：对业务数据传过来的表进行维度退化和降维。（商品一级二级三级、省市县、年月日）LZO压缩：列式存储 parquet、orc大量的原始数据逐条筛选处理，需要处理的内容包括但不限于如下：
去除废弃字段,去除格式错误的信息，空值去除去除丢失了关键字段的信息。比如订单表中订单 id 为 null，支付表中支付 id 为空数据规范化,因为大数据处理的数据可能来资源不同，这时候可能相同业务数据字段，数据类型，空值等都不一样，这时候需要在DWD层做抹平，否则后续处理使用时，会造成很大的困扰如后续有业务需要，需要对DWD层数据进行水平或垂直切割(2)数据中间层：DWM（Data WareHouse Middle）
该层会在DWD层的数据基础上，对数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。直观来讲，就是对通用的核心维度进行聚合操作，算出相应的统计指标。
在实际计算中，如果直接从 DWD 或者 ODS 计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在 DWM 层先计算出多个小的中间表，然后再拼接成一张 DWS 的宽表。由于宽和窄的界限不易界定，也可以去掉 DWM 这一层，只留 DWS 层，将所有的数据再放在 DWS 亦可。
(3)数据服务层DWS（Data WareHouse Servce）
以DWD为基础，按天/主题进行轻度汇总，聚集主要是通过汇总明细粒度数据来获得改进查询性能的效果。又称数据集市或宽表,轻度汇总的数据。一般使用主题建模或维度建模等方式，主题建模，顾名思义，围绕某一个业务主体进行数据建模，将相关数据抽离提取出来。维度建模，其实也差不多,不过是根据业务需要，提前将后续数据查询处理需要的维度数据抽离处理出来，方便后续查询使用。
主题建模——轻度汇总顾名思义，围绕某一个业务主体进行数据建模，将相关数据抽离提取出来将流量会话按照天、月进行聚合将每日活跃用户进行聚合将某样商品按用户或时间聚合维度建模根据业务需要，提前将后续数据查询处理需要的维度数据抽离处理出来，方便后续查询使用将运营位维度数据聚合将渠道拉新维度数据聚合DWS层一般都是存储与一定业务相关的数据，可以说是一种结果数据，建模数据。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。一般来讲，该层的数据表会相对比较少，一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。
在实际计算中，如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在DWM层先计算出多个小的中间表，然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定，也可以去掉DWM这一层，只留DWS层，将所有的数据在放在DWS亦可。
DWS 层有 3-5 张宽表（处理 100-200 个指标 70%以上的需求）。具体宽表名称：用户行为宽表，用户购买商品明细行为宽表，商品宽表，购物车宽表，物流宽表、登录注册、售后等。哪个宽表最宽？大概有多少个字段？最宽的是用户行为宽表。大概有 60-100 个字段具体用户行为宽表字段名称。评论、打赏、收藏、关注–商品、关注–人、点赞、分享、好价爆料、文章发布、活跃、签到、补签卡、幸运屋、礼品、金币、电商点击、gmvDWS 层统计各个主题对象的当天行为，DWS层的宽表字段，是站在不同维度的视角去看事实表，重点关注事实表的度量值，通过与之关联的事实表，获得不同的事实表的度量值。
(4)DWT(data warehouse Topic)
DWS层是天表，DWT层是累计值。DWS层存放的所有主题对象当天的汇总行为，例如每个地区当天的下单次数，下单金额等，DWT层存放的是所有主题对象的累计行为，例如一个地区最近（7天，15天，30天，60天）的下单次数、下单金额等。
月活、周活、留存、留存率、新增（日、周、年）、转化率、流失、回流、七天内连续 3 天登录（点赞、收藏、评价、购买、加购、下单、活动）、连续 3 周（月）登录、GMV、复购率、复购率排行、点赞、评论、收藏、领优惠价人数、使用优惠价、沉默、值不值得买、退款人数、退款率 topn 热门商品。
(5)DW层规范
①命名规范
事实表前缀+业务领域拼音缩写+事实表英文标识+表名的方式
DW_业务领域_F_具体表名
维度表前缀+业务领域拼音缩写+维度表英文标识+表名的方式
DW_业务领域_D_具体表名
②模型规范
采用星型模型建模，星型模型一般采用降维的操作，利用冗余来避免模型过于复杂，提高易用性和分析效率。核心是一个事实表及多个非正规化描述的维度表组成，维度表之间是没有关联的，维度表是直接关联到事实表上。当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故将该模型称为星型模型。
3.数据应用层(ADS或DA或APP)
前端应用直接读取的数据源；根据报表、专题分析的需求而计算生成的数据。主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。
ADS层叫应用服务层，一般就直接对接OLAP分析，或者业务层数据调用接口了。这是最顶层，一般都是结果类型数据，可以直接拿去使用或者展示的数据了，也是对数据抽离分析程度最高的一层数据。这一层是需求最明确的一层，根据业务需求来决定数据维度和结果分析。该层首要考虑的，一般是查询效率问题，所以针对不同的业务系统，需要考虑使用不同的数据库进行存储。
(1)关注点
如何分析用户活跃？在启动日志中统计不同设备 id 出现次数。如何分析用户新增?用活跃用户表 left join 用户新增表，用户新增表中 mid 为空的即为用户新增。如何分析用户 1 天留存？留存用户=前一天新增 join 今天活跃。用户留存率=留存用户/前一天新增如何分析沉默用户？(登录时间为 7 天前,且只出现过一次)按照设备 id 对日活表分组，登录次数为 1，且是在一周前登录。如何分析本周回流用户？本周活跃 left join 本周新增 left join 上周活跃，且本周新增 id 和上周活跃 id 都为 null。如何分析流失用户？(登录时间为 7 天前)按照设备 id 对日活表分组，且七天内没有登录过。如何分析最近连续 3 周活跃用户数？按照设备 id 对周活进行分组，统计次数大于 3 次。如何分析最近七天内连续三天活跃用户数？查询出最近 7 天的活跃用户，并对用户活跃日期进行排名计算用户活跃日期及排名之间的差值对同用户及差值分组，统计差值个数将差值相同个数大于等于 3 的数据取出，然后去重，即为连续 3 天及以上活跃的用户7 天连续收藏、点赞、购买、加购、付款、浏览、商品点击、退货1 个月连续 7 天连续两周(2)ADS层规范
①命名规范
前缀+表名的方式，前缀为ADS_，表名为指标英文标识。
②数据表规范
应用数据层的建设是强业务驱动的，业务部门需要参与到应用数据层的建设中来。推荐的方式是，了解业务的人员将业务需求告知开发人员，然后在建模过程中深入沟通，这样形成的应用数据层的表设计才能既满足业务需求又符合整体的规范。因此应用数据层的结构为：
应用场景是多维的即席分析，一般为了减少连接、提升性能，会采用大宽表的形式组织。如果是特定指标的查询，可以采用K-V表形式组织。(3)区别
ADS一定要是面向业务的，不是面向开发的，这部分数据让业务能最短的时间去理解，甚至直接使用。DWS必须是指标，DWS汇总基本上就是ADS的支撑。DWD就是明细层，明细层怎么建呢？建议采用的是维度建模的方式，企业有维表，有事实表，维表也有很多层级维度，比如枚举维度，事实表有周期快照。当然在这里有一个点就是DWD的字段必须是可被直接理解的，不要有二义性，一旦有二义性的时候，DWS使用的时候会有问题，会导致整个上游应用都有问题。
4.TDM 标签数据层
随着互联网的普及，获客成本越来越高，这也使得公司对用户运营提出了更高的要求，不仅需要精细化更需要个性化。解决这一问题的办法之一就是建立相对完备的标签系统，而数仓的标签层对于标签系统而言就像数据仓库对于数据系统一样，有着举足轻重的地位，这样的标签系统需要与业务进行紧密结合，从业务中获取养分—用户标签，同时也要服务于业务—给用户提供更加精准和个性的服务。
底层的标签系统就像一个索引，层层展示大千世界，而用户就从这大千世界中不断选择一些东西表明自己的身份和喜好，也不断反哺，使得这个大千世界更加丰富多彩。其实到最后用户就是一些标签的集合。
对跨业务板块、跨数据域的特定对象进行数据整合，通过统一的ID-Mapping 把各个业务板块，各个业务过程中同一对象的数据打通，形成对象的全域数据标签体系，方便深度分析、挖掘、应用。ID-Mapping 可以认为是通过对象的标识对不同数据体系下相同对象进行关联和识别。 对象的标识可以标识一个对象，一般是对象的ID,比如手机号，身份证，登录账号
完成对象的ID 打通需要给对象设置一个超级ID,需要根据对象当前业务体系的ID和获取得到或者计算得到超级ID,进而完成所有业务标识的ID打通一般来说ID打通是建设标签体系的前提，如果没有ID打通就无法收集到一个对象的全面信息，也就无法对这个对象进行全面的标签刻画。
传统的计算方法要有 ID-ID之间的两两关系，例如邮箱和手机号可以打通，手机号和身份证号可以打通，那么邮箱就和身份证号可以打通，但是当数据量非常大，且业务板块非常多的时候，例如有上一个对象，每个对象有数十种ID,这个时候打通就需要非常漫长的计算
那么什么是标签呢，利用原始数据，通过一定的逻辑加工产出直接能被业务所直接使用的、可阅读的，有价值的数据。标签类目，是标签的分类组织方式，是标签信息的一种结构化描述，目的是管理、查找，一般采用多级类目，一般当一个对象的标签个数超过50个的时候，业务人员查找标签就会变得非常麻烦，这个时候我们往往会通过标签类目进行组织管理
标签的分类
标签按照产生和计算方式的不同可分为属性标签，统计标签，算法标签，关联标签。
属性标签。对象本身的性质就是属性标签，例如用户画像的时候打到用户身上的标签。统计标签。对象在业务过程中产生的原子指标，通过不同的计算方法可以生成统计标签。算法标签。对象在多个业务过程中的特征规律通过一定的算法产出的标签。关联标签。对象在特定的业务过程会和其他对象关联，关联对象的标签也可以打在主对象上。5.数仓层次调用规定
应用层应优先调用统一数仓层(DW层)数据，必须存在DW层数据，不允许应用层跨过DW层从ODS层重复加工数据。一方面，DW层团队应该积极了解应用层数据的建设需求，将公用的数据沉淀到CDW层，为其他团队提供数据服务；另一方面，应用层团队也应积极配合DW层团队进行持续的数据公共建设的改造。必须避免出现过度的引用ODS层、不合理的数据复制以及子集合冗余。
6.数据仓库构建步骤
(1)ODS层
①数据收集步骤
业务系统的数据库名称，表名称，字段名称，字段类型等，产出数据模型。
检查原始数据质量，记录问题详情，产出数据治理文档，作为数据治理工作的依据。
研究业务系统数据的更新方式以及更新频率，决定数据同步工具的更新方式。
②数据同步介绍
确定业务系统源表与贴源数据层目标表配置数据字段映射关系，目标表可能会增加采集日期、分区、原系统标识等信息，业务内容不做转换如果是增量同步或者有条件地同步部分数据，则配置数据同步条件清理目标表对应数据启动同步任务，往贴源数据层目标表导入数据验证任务是否可以正确运行，并且采集到准确数据发布采集任务，加入生产调度，并配置相关限速、容错、质量监控、告警机制(2)DW层
在业务调研之后，构建CDW层需要对数据进行建模，采用星型模型设计维度模型，构建事实表和维度表，以订单下单为例，维度表包含用户信息、定价模型、优惠活动等，事实表采用拉链表结构存储订单事实，当订单状态发生变化时，在拉链表中增加一条记录表示该事实。
①数据来源与存储库
②业务调研与需求分析
在构建CDW层之前，首先进行全面的业务调研。需要请相关的业务人员介绍具体的业务，以便明确各个团队的分析员和运营人员的需求，沉淀出相关文档。
③事实表与维度表设计的过程
④实现步骤
确定ODS层数据源以及存储库进行业务调研与需求分析，产出业务结构等相关文档根据调研结果，结合维度建模模型，进行CDW层的维度建模，设计事实表与维度表选择某一业务线进行，DW层事实表与维度表的构建，设计数据模型，确定事实表采用的结构以及维度表应该包含的信息开启同步任务，进行数据定时同步，将ODS层数据定时导入DW层(3)ADS层
①指标体系的构建
识别核心业务场景：识别各方愿景及核心业务场景、流程。摸清核心数据网络：深入分析业务场景、流程，摸清核心数据网络：有什么角色在什么系统做什么事情产生哪些数据探索价值数据体系：从运营管控价值角度出发，将指标进行层级区分，并识别指标业务维度及业务场景指标分级：一级、二级、三级业务维度：企业经营环节、市场拓展环节（更多的消费端和供给端）、运营增长环节（更好的质量和用户粘性）业务场景：指标围绕不同场景细致分析细化各级核心指标：根表指标体系，细化核心指标：指标等级业务领域指标维度指标名称指标计算公式指标目的数据来源对齐/下发核心指标数据：征集客户意见，对齐核心指标设计。开发与持续迭代：根据细化的指标设计可视化界面，并进行指标开发：指标可视化设计（分析目的、选择图表、价值维度）②建设步骤
调研业务应用对数据内容、使用方式、性能的要求，需要明确业务应用需要哪些数据，数据是怎么交互的，对于请求的响应速度和吞吐量等有什么期望。盘点现有数据是否满足需求；如果有个性化指标需求，统一数仓层数据无法满足，则进行个性化数据加工。组装应用层数据。来源：正正杂说
