数仓-概念的理解和方法论

大数据相关概念

什么是大数据

大数据是指某应用涉及的数据规模已经超过传统数据库软件采集、存储、管理、分析的处理范围。则称这些数据为大数据。这里并没有明确的数据量界限，在不同行业、不同时间节点的数据容量也不一样。

大数据主要涉及的行业

金融
用户经营、风控。为客户推荐合适产品、预测理财产品的受欢迎程度
汽车
分析消费者行为决定汽车营销方向、分析用户维保行为评估二手车价值、智能导航、自动驾驶
电商
电信
物流
政府
导航

对数仓相关概念的初步理解

数仓

https://zhuanlan.zhihu.com/p/189640832

数据仓库就相当于超市的仓库（相对于展厅而言），在这里，数据（家具）按照特定的模型，如FS-LDM等（货架-位置）组织起来，这种模型，对于顾客（业务人员，数据最终用户）是不友好的，但是对于开发人员（仓库管理员，宜家员工）来说相对友好，开发人员可能知道某个指标怎么跑出来的，但这个指标怎么用只有业务人员知道。
因为他按照一种更加集约化的规则将数据（家具）管理起来了，存放集中、规整，提取数据（提货）不用跨库（货仓）寻找，查找的效率更加高。
这也就是为什么需要数据集市层和应用层了，其实就是把数据ETL，让业务人员能更方便的使用这些数据。数据仓库是进行数据挖掘、知识发现的基础。

数据集市

上文提到，数据仓库对业务人员不是很友好，同样，你总不能让顾客直接逛仓库吧？顾客的需求，是按照家具的种类分门别类，按照家庭的不同房间，组合在一起展示的，正如宜家楼上的展厅，购物体验肯定比逛仓库来得好多了。

所以，数据集市就像宜家楼上的展厅，正如其名字“集市”一样，是一个面向最终用户（顾客）的数据市场，在这里，数据（家具）以一种更加容易被业务人员（顾客）接受的方式组合在一起，这些组合方式可能是多变的，因为业务人员（顾客）的需求是多变的，因此我们需要定期调整集市的计算口径（展厅的陈列方式），经常会创建新的数据集市（装修新的展厅）。

所以market完全可以翻译成展厅、超市，毕竟货都是来源于仓库、直接面向用户。

数据集市是按主题分类的，以应对不同用户的需求。比如用户主题（可以在此基础上营销分析）、订单主题（预测商品销量分布）

数据仓库和集市的概念理解了，其他一些相关问题也就迎刃而解，

• 比如为什么有了数据仓库还要建数据集市？
• 为什么要分ods

数据中台（数据仓库和数据中台区别）

数仓是为了技术上的复用，包括数据、ETL脚本，比如数据采集、ETL，让不同的任务可以共用集市层甚至是ods层的数据。
而数据中台，其实主要做的还是数仓的这些事情，还是采集、存储、计算、应用。只不过跟业务的联系更紧密了，所以数据中台可以说是业务的复用，比如没数据中台之前，你要排查一个字段，可能要打开数据字典挨个找，现在有了中台，你有了血缘分析的功能，可以打开页面点几下就行了。当然，元数据管理很早就有了，数据中台只不过为了“一站式解决所有问题”，把很多原有的数据相关功能纳入进去罢了。数据中台就是数仓功能的大杂烩，为了名字好听或者更好推广起了个中台的名字

传统的数据仓库，基本上就是数据etl开发、指标设计、数据仓库建模、数据集市建模、数据分析的流程。阿里提出数据中台以后，在阿里的整个中台体系中，核心的公共数据层仍然是数据仓库的维度建模体系，那数据中台和以前的数据仓库有什么区别呢？
以阿里的话说，提供了更加智能的数据萃取，通过数据内容对用户、商品进行标签置标、行为分析、营销预测。从我的个人理解里，这都属于大数据分析的范畴。

数据仓库是利用数据平台提供的计算和存储能力，在一套方法论指导下建设的一整套的数据表
数据中台包含了数据平台和数据仓库的所有内容，将其打包，并且以更优雅以及更产品化的方式对外提供服务和价值。数据中台建设目标是要打通企业各个业务系统，打破数据孤岛现象，将数据统一接入大数据平台，对数据进行管理，提供跨系统的数据共享和复用服务。
那除此之外呢？有啥区别？没有区别！
整个过程仍然逃不脱数据采集接入、数据处理、数据存储、数据管控和数据服务，这也是我们常说的数据生命周期5步。
至于数据业务化和业务数据化都是扯淡，拗名词而已。包括数据湖和华为的数字底座。
如果是技术服务方，是需要这些看起来高大上的新名词让用户甘心情愿地掏腰包，甲方领导需要这些新名词彰显自己的政绩。
如果你是甲方客户，请记住一点：你建数据体系是建能力，不是建“名词”！
不管是叫数据湖也好，叫数据底座也好，叫数据中台也好，叫湖仓一体也好，这都是名词，即便是叫“王二狗野蛮杀妻不成反遭灭门单人逃脱十万火急惨案记管理平台”都行。
你需要建设的是能力。你的企业因为业务的发展，有很多业务系统，产生了大量的数据。如果说你想利用这些数据，首先就要把这些数据物理或者逻辑的集中起来，这就需要数据采集接入能力。
数据接入进来以后，有结构化的，有物联网的，有文档图片的，有大块二进制文件，传统的单一数据库并不能存下，你就需要有一个混合式的存储架构，这是存储能力。
你想为经营报表提供数据，你想为研究部门提供数据，但原始数据有问题，没办法直接使用，你需要清洗、计算、处理、级联，这就是数据计算能力。
数据收上来以后，你发现数据太乱了，业务系统数据库中只有英文代码，不知道存的什么数据，那你就需要元数据管理能力；公司的设备在不同的系统里面叫法和编号都不一样，你就需要主数据管理能力……这些都是数据管控能力。
现在你也有很多数据内容了，怎么样快速交付给业务部门使用，怎么样让其它业务系统调用你的数据，你就需要有高效、敏捷的数据服务能力。
至于你说你需要智能化推荐，你就可以在数据处理中增加智能化用户画像的能力，在数据服务中增加用户画像推荐的能力。
所以说，企业需要的数据能力，不是满天乱飞的名词。
现有的数据中台，在原有单纯数据仓库的基础上，增加了数据治理的内容、大数据智能化分析的内容。但在大型国企、制造企业用的最多的还是数据共享和指标统计，智能标签、行为分析在互联网行业还有土壤，在传统国企中很难找到落地的场景。因为传统国企中的业务都比较稳定，并不像互联网公司那样会根据利润增长点去创新出花呗、借呗、聚划算这种新的业务线出来。

数据湖

• 来源复杂，作为集中存放地
  比如你现在需要分析一个30年前的软盘里的东西
• 多系统交互，作为集散中心。以空间换时间

数据湖可以说是数仓的拓展，数据来源、种类更加多元，数仓是仓库，而数据湖把木材厂甚至是树林都纳入进来。这样客户就有了更多的可能性。
比如说银行审计业务中，信贷系统中早期录入的很多资料不准确，有很多早期条目的录入依据都是手写的证件甚至是口述，比如居住地址，现在从数据湖中可以直接取到它暂住证的原始图片，这样一对比，审计工作就很容易开展了。

数据湖物理实现上是一个数据存储平台，用来集中化存储企业内海量的、多来源，多种类的数据，并支持对数据进行快速加工和分析，目前Hadoop是最常用的部署数据湖的技术，但并不意味着数据湖就是指Hadoop集群。为了应对不同业务需求的特点，MPP数据库+Hadoop集群+传统数据仓库这种“混搭”架构的数据湖也越来越多出现在企业信息化建设规划中。

olap

olap分为以下两大类：
1 固化查询：指对一些固化下来的取数、看数的需求，通过数据产品的形式提供给用户，从而提高数据分析和运营的效率。这类需求的SQL有固定的模式。固定报表查询，需要查询的固定报表数据，入库mysql/HBASE（日新、日活、pv、留存、核心业务转化、关键路径转化、关键事件报表，gmv日报周报月报等）
2 即席查询：指用户通过手写SQL来完成一些临时的数据分析需求。由kylin（麒麟）presto或impala提供即席查询支撑SAS、SPSS等软件。数据挖掘更多的倚重统计学、机器学习算法之类的，分析
Tableau，finereport是BI工具，报表及可视化

区别

• 基础能力上的区别
  数据平台：提供的是计算和存储能力
  数据仓库：利用数据平台提供的计算和存储能力，在一套方法论的指导下建设的一整套的数据表
  数据中台：包含了数据平台和数据仓库的所有内容，将其打包，并且以更加整合以及更加产品化的方式对外提供服务和价值
  数据湖：一个存储企业各种各样原始数据的大型仓库，包括结构化和非结构化数据，其中湖里的数据可供存取、处理、分析和传输
• 业务能力上的区别
  数据平台：为业务提供数据主要方式是提供数据集
  数据仓库：相对具体的功能概念是存储和管理一个或多个主题数据的集合，为业务提供服务的方式主要是分析报表
  数据中台：企业级的逻辑概念，体现企业数据产生价值的能力，为业务提供服务的主要方式是数据API
  数据湖：数据仓库的数据来源
  总的来说，数据中台距离业务更近，数据复用能力更强，能为业务提供速度更快的服务，数据中台在数据仓库和数据平台的基础上，将数据生产为一个个数据API服务，以更高效的方式提供给业务。数据中台可以建立在数据仓库和数据平台之上，是加速企业从数据到业务价值的过程的中间层。

前置知识-分析、事实、维度、度量、指标、指标体系

1.概念

参考：
https://www.zhihu.com/question/32282069/answer/2282178551

1.1.分析

是从复杂现象中找出简单规律的过程，是化繁从简的过程。一般，就是多变少。比如，最常见的，求平均值、分组求topN。

1.2.事实

就是事件的意思。表示的是系统中一个真实产生的事件信息。将业务过程抽象出来的供分析的一条记录，比如订单、贷款记录、一天的行程。
比如去电商买东西，就是个业务过程，这个过程包含很多事件，我们从业务过程中根据需求抽象事实，比如从电商买东西中抽象出下订单。

1.3.既然化繁从简，那必然就需要抽象。

这个抽象可以是一个数值，比如一群人，只关心年龄，年龄可以进行各种计算。也可以是一个表示程度的，比如长相、肤色、钻石分级中的净度、色度，这些无法用数值表示，就没法进行计算。这个对事实的抽象， 就是度量。

1.4.仅仅一个度量无法满足数据分析的需求，需要进一步分类

比如全国结过婚的人数，这个人数就是度量，但显然，这个度量，在进行区域结婚率统计时，没有意义，所以需要按照省份、性别进行分组。度量是数值数据，维度是类别数据。

1.5.一个数据指标一般由一种或多种维度加上一种度量组成

如上，山东省结婚男性数目，就是一个指标。
比如：公司希望App新用户比上个月增长一倍，分析一下哪些用户群体最有增长潜力。
可以这样展开分析：网站用户的指标有哪些–》哪些度量与用户数相关–》找到影响新用户的度量。
然后针对这些度量–》拆分不同的维度，比如来自站内活动／站内流量／百度引流／知乎推广／网页广告等。
这是先从度量角度看，再拆分维度逐步分析。
也可以直接从用户数出发，直接拆分维度，比如用户性别／用户年龄／城市／职业等维度展开，发现不同维度中的奥秘。找到新用户这个度量下，哪个维度的影响比较大，就可以有的放矢了。

1.6.实际应用中的几个要点

• 度量可以转化成维度
  比如订单金额，本来可以看作是一种度量，因为订单金额从0到10000都有可能，但为了区分或刻画用户的消费能力，就可以按照订单金额大小将订单分成几类，比如0-30元，30-60元，30-90元等，从而将订单按照订单金额分成高／中／低（甚至更多）分类，那么这些不同类型的订单数，比如高单价订单数就成了一个新指标，其中高客单价就是一种新的维度，是由订单金额转化而来的。

• 维度可以产生不同的组合
  比如上海男性就是城市维度和性别维度的组合，类似的组合千变万化，从而形成了许多的指标，当然，其中很多都没有太大意义。

• 一般的数据分析可以这样理解
  结合实际业务，将自己对问题的看法转化具体到维度和度量，将维度和度量转化成可视化的图表，然后通过不同的维度和度量进行观察，找到规律，做出调整，直到发现数据中异常的地方，找到突破口。

2.指标和指标体系

提起指标这个词，每个人似乎都可以说出几个指标，像经常在工作中会听到的日活、月活、注册率、转化率、交易量等 事实上指标就是用来量化事物的一个工具，帮助我们去将一些抽象的事件得出一个轮廓上的描述。
例如我们可以从指标上判断一个产品的好坏，用户粘性等等，例如我们通过日活能去判断出我们整个产品的用户量，从而能反应出我们这个产品的一个健康程度，也就是否处于增长过程中。

2.1.为什么搭建指标体系

一个好的数据指标体系可以助力业务快速的解构业务、理解业务、发现业务问题，快速定位原因，并且找到最合适的解决方案。当我们的业务出现数据异常时，因为数据很多，往往会一遍遍地从这些数据中去寻找可以定位原因的相关指标，这不仅会浪费很多时间，还会使人心疲力竭。
因此学习搭建一个好的数据指标体系是数据助力业务决策的灵魂。

大到用于监控和评估商业进程的状态，小到衡量某个功能模块的情况，或者是自己的活动效果，都需要指标。指标体系的构建，是为了让业务目标可度量、可描述、可拆解，所以我们的指标是基于业务目标抽取和评估的数据维度，这些数据维度可以用来帮助达到业务目标。从而进行业务情况的监控、找到当前业务问题、评估业务可改进的地方，找出下一步工作的方向。其实小到个人，大到国家都有各种各样的指标，就连数字中国最关键的也是各种指标指数的定义和修正机制的建设！

指标用于追踪和评估商业进程的状态，确保项目务在正确的轨道上运营，同时验证方法论，不断地学习。指标监控体系最大的价值就是帮助大家高效利用时间，把时间花在解决问题上，而不是寻找问题上，从而提高团队整体的人效。
指标也是目标，没有目标就不知道做什么，搭建指标体系是为了更好地发现用户的问题，并且去解决。所以我们需要站在用户的场景去考虑整体的内容。

这边给大家看一个故事，估计大家都会比较有体感：大家有没有在半夜收到过老板的信息，问为什么业务上的核心指标GMV下降了？
然后这里边我们产品同学小六就会赶紧把电脑打开，但是他所有能获取的信息就只有一个Dashboard，里边只有一个GMV核心指标，环比同比同时下降，这个时候他怎么回答老板的问题？结果基本靠猜，是不是竞对做了一些活动？是不是某个主播停播了？另外一种可能性的情况是小六同学手里边有一百多张报表，这一百多张报表里边，有四百多个指标，然后每一个指标都在下降，那在这种情况下，也没有办法回答老板的问题，为什么这个核心指标下降，到底是DAU下降了，还是用户满意度下降了，还是转化效率下降了等等？
另外一种情况是老板同样提了这样一个问题，然后另外一个产品同学小快不紧不慢的拿出了一张这样的一个报表体系，他说：“老板，我认为GMV下降会跟整个业务流程都有相关性，我们从业务角度进行了这样的一个拆解，发现在流量入口，和最后的人均消费来看的话，其实并没有下降，主要下降来源其实来源于列表页转化效率的下降。再往下拆解，发现高价的商品的曝光占比和低价的曝光占比并不太平衡。高价商品的一个曝光占比比较高，但是它的转化效率却是低的，所以从这个角度来讲，我认为可能在列表页来里面的不同价格的商品的分发策略或者曝光策略需要进行优化，然后通过A/B test去看一下我们这个策略调整的效果是什么样子的”。我们看到数据指标体系可以帮助我们 整体理解业务、全面了解问题、快速定位原因、迅速落地方案，我们说的指标体系不止是指标，还有指标管理和指标监控

2.2.如何建设指标体系

需要回答以下几个问题：如何评价数据指标体系
一个好的数据指标体系是要需要回答两个问题：它是不是有助于业务发展，以及说这个指标体系拆解是不是可具备、可落地、可实操的可能性。
如何建设数据指标体系，这就需要我们的建设方法论了
如何维护和管理指标，指标的维护和管理是有套路的，最简单的指标管理方法——指标字典，我们在此基础上可以做指标管理系统OSM 实现了业务目标结构化，UJM 实现了业务目标流程化。
数据指标体系其实只是数据赋能业务的万里长征的第一步。未来如果希望更加泛化地去支持到更多的业务场景，其实是需要去做一些产品化的沉淀的，把一些固化下来的指标体系或者分析框架沉淀下来，去赋能更多的业务人员，可以使用相对应的数据产品，帮助他们去做相对应的业务决策。进一步提升他们决策的效率，同时降低使用数据的一个门槛。

2.3.指标建设过程中遇到的问题

指标没有重点、没有思路，构建完成后也只是一组数据，各有用处，合起来却起不到作用；
指标空洞，粗看有模型又有分类，细看流程中却没有几个具体的指标，无法落地指标缺乏数据，导致业务上线了又开始添加指标、增加维度，最后报表变得臃肿，数据参差不齐，影响工作推进

3.指标建设方法论

下面是常见的指标体系建设方法，我们比较常用的是OSM+UJM 模型，当然这也不是绝对的，主要还是得看我们的业务场景和业务目标

3.1.人货场指标体系

目前阶段互联网业务比较流行的一种通用抽象场景“人、货、场”，实际就是我们日常所说的用户、产品、场景，在通俗点讲就是谁在什么场景下使用了什么产品，不同的商业模式会有不同的组合模式。
以滴滴实际场景为例：哪些场景（此处场景定义为终端，如Native，微信，支付宝）的什么人（乘客）在平台上使用了哪些货（平台业务线，如快车/专车等），进而为评估用户增长的价值和效果。

“人”的视角

从“人”的视角，我们比较关心的是什么乘客在什么时间打的车，排了多长时间，等了多长时间上车，周期内第几次打车，打车花了多少钱，是否有投诉和取消行为，具体到数据指标主要看发单用户数、完单用户数、客单价、周期内完单订单数、取消订单数、评价订单数等

“货"的视角

从“货”的视角，我们比较关心的就是成交了多少，交易额多少，花了多少，到具体数据指标主要会看GMV、成交率、取消率指标，在进一步会细分到城市、区域，一级品类、二级品类。数据的效果通过目标对比，横向对比、历史比较等方式进行分析确定。

“场”的视角

从“场”的视角，我们比较关心的就是哪个渠道用户点击量大曝光率大，带来了多少新用户，完成多少交易订单，客单价是多少；或者是哪个活动拉新或促活效果怎么样转化率多少，结合场景数据实际情况制定对应策略。

以上分别从“人”、“货”、“场”三个角度进行了数据指标和分析维度的提炼，下面我们把三类指标结合指标分级方法进行分解关联。

OSM+UJM 模型

数仓的搭建

流程

数仓分层

作用

• 用空间换时间，计算逻辑、计算结果复用。提取公共逻辑。降低sql复杂度，比如bds中的宽表，减少join通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据；不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大。
• 通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。
• 数据仓库之父 Bill Inmon对数据仓库做了定义——面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。从定义上来看，数据仓库的关键词为面向主题、集成、稳定、反映历史变化、支持管理决策，而这些关键词的实现就体现在分层架构内。
• 一个好的分层架构，有以下好处：
  • 清晰数据结构：每一个数据分层都有对应的作用域，在使用数据的时候能更方便的定位和理解。
  • 数据血缘追踪：提供给业务人员或下游系统的数据服务时都是目标数据，目标数据的数据来源一般都来自于多张表数据。若出现目标数据异常时，清晰的血缘关系可以快速定位问题所在。而且，血缘管理也是元数据管理重要的一部分。
  • 减少重复开发：数据的逐层加工原则，下层包含了上层数据加工所需要的全量数据，这样的加工方式避免了每个数据开发人员都重新从源系统抽取数据进行加工。
  • 数据关系条理化：源系统间存在复杂的数据关系，比如客户信息同时存在于核心系统、信贷系统、理财系统、资金系统，取数时该如何决策呢？数据仓库会对相同主题的数据进行统一建模，把复杂的数据关系梳理成条理清晰的数据模型，使用时就可避免上述问题了。
  • 屏蔽原始数据的影响：数据的逐层加工原则，上层的数据都由下一层的数据加工获取，不允许跳级取数。而原始数据位于数仓的最底层，离应用层数据还有多层的数据加工，所以加工应用层数据的过程中就会把原始数据的变更消除掉，保持应用层的稳定性。

数仓分几层好？分层的依据是什么？

分层是以解决当前业务的数据支撑为目的，为业务发展提供稳定、准确的数据支撑，为未来抽象出共性的框架并能够赋能给其他业务线，并能够按照已有的模型为新业务发展提供方向，也就是数据驱动和赋能。
一般4层，也有3层，分层跟业务紧密相连，比如buffer层，如果数据源格式繁杂，可以专门设一个buffer层来进行数据格式转换，同时还可以保留最原始的数据文件。又比如某业务的目的不是为了跑模型和报表，则不太需要ads（mds）层，只需要跑到主题层即可。

• ODS贴源层，这里存放的数据与原系统保持一致，将采集公司所有的系统产生的数据以及外部数据（包括合作数据以及爬虫获得的数据），将所采集的数据汇总到一起

• DW 数仓（DWD（数据明细层）、DWS（汇总层，主题域））、

• DWD: （data warehouse detail）明细层，以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细事实表。可将某些重要属性字段做适当冗余，也即宽表化处理。
  明细粒度 ==> 汇总粒度

• DWS层（数据汇总层）宽表，面向主题的汇总，维度相对来说比较少，DWS是根据DWB层数据按各个维度ID进行粗粒度汇总聚合，如按交易来源，交易类型进行汇合。
  DWS层按产品的属性维度进行统计，得到统计宽表，产品属性维度包括：地区，机构分公司，产品，学科组合分组，来源渠道，咨询中心
  通常根据业务需求，划分成流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。

• DWS（Data WareHouse Service）：存储宽表数据，此层数据是针对某个业务领域的聚合数据，应用层的数据通常来源与此层，为什么叫宽表，主要是为了应用层的需要在这一层将业务相关的所有数据统一汇集起来进行存储，方便业务层获取。此层数据通常来源与DWD和DWM层的数据。

• 公共维度层（DIM）维表、主要由维度表（维表）构成。维度是逻辑概念，是衡量和观察业务的角度。

• APP应用层 ：应用层(ADS)：应用层主要是各个业务方或者部门基于DWD和DWS建立的数据集市(Data Market, DM)

数仓如何确定主题域？CDM？主题是什么划分：按照业务或业务过程划分（举例说明）

按照业务或业务过程划分（举例说明）
主题域：面向业务过程，将业务活动事件进行抽象的集合，如下单、支付、退款都是业务过程，针对公共明细层（DWD）进行主题划分。

主题域通常是联系较为紧密的数据主题的集合。可以根据业务的关注点，将这些数据主题划分到不同的主题域

主题是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念，每一个主题基本对应一个宏观的分析领域。如财务分析就是一个分析领域

主题与分层的关系
主题和分层没有必然联系，一般主题是从DWD层聚合到DWS层，事实表位于DWD层，结果聚合表位于DWS层。但是有些情况下，在某个主题内，DWS层的表也会作为这个主题下的事实表，用于聚合衍生指标。

在一个主题内，数据流肯定是单向的，即从事实表到结果聚合表。

主题域的确定必须由最终用户和数据仓库的设计人员共同完成的

客户、内部人员、机构、地域、订单保单承保、理赔、金额财务

数仓搭建过程中的问题

缓慢变化维的场景、实现方式、例子，拉链表的场景、实现方式、例子？

维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。这种随时间发生变化的维度我们一般称之为缓慢变化维，slowly changing dimensions 缓慢变化维度常见的缓慢变化维处理方式有三种：

全量更新：直接覆盖：不记录历史数据，薪数据覆盖旧数据
增量更新：更新每天的数据；
新加一行数据（纵向扩展）：使用代理主键+生效失效时间或者是代理主键+生效失效标识（保存多条记录，直接新添一条记录，同时保留原有记录，并用单独的专用字段保存，有个标志每次+1，或时间戳）
拉链表：新加两个字段（横向扩展）：new_. old_ 或者时间版本号 ，每次更新只更新这两个值，但是这样职能保留最近两次的变化（添加历史列，用不同的字段保存变化痕迹，因为只保存两次变化记录，使用与变化不超过两次的维度）
（T+1增量更新，导数如何实现按天分区更新拉链表）

拉链表有分区吗？拉链表分区是怎么控制的？

（我说的是每天全量刷新，他接着问如果你们数据量特别大呢？是不是需要全量刷写？怎么解决的？）

动态分区，并增量更新，把有变化的分区数据拿出来修改后并插回去

方式2（使用end_day作为分区键）：

方式4（使用start_day和end_day作为联合分区键，end_day为父分区）：
https://blog.csdn.net/qq_22473611/article/details/102901625

维度退化，以及其作用

把事务维度所有的描述性项目进行剔出后，形成维度为空。诸如这种事务编号、固有的操作型票据编号，应该自然的放入事实表中，而不用连接到维度表。
例如：订单号，发票号与提货单编号
为了提高数据明细层的易用性，DWD->DWS层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。

数据飘移

模型和建模

模型，在数仓中就是表结构
建模：建表和表之间关系

1. 三范式模型

数仓用的很少，但业务系统关系型数据库中用的多。OLTP
业务最终都会体现到数据库中，
特点是高并发的随机CRUD，一次一般只会操作一条

数仓不会有高并发的随机CRUD，特点是大数据量、低并发、批量、大多数是查询。OLAP。
因为2者特点不同，建表时的方法论也不同，OLAP因为频繁的插入、修改，所以每条数据尽量的小，尽量避免数据冗余，所以要把维度尽量的提取出来，规范化。比如订单表，如果用三范式理论，那么某手机订单中的商品名称就要用外键，而不能直接用名称，否则，商品名称修改时，订单表中每条都要改。订单表改了，退货表中的也要改，否则会有一致性的问题。

而OLAP中，会带有商品名称，这样计算的时候方便。

ER建模为什么不适用数仓建模？

第一范式（列不可分）：每一列都是不可分割的原子数据项，如果列可分割，用sql查某一列时，会返回很多冗余数据。

（像下面的表格就能分割，所以它连第一范式都算不上）
分割后的样子（本表就符合了第一范式）

第二范式（消除部分依赖）：在1NF基础上，非码属性必须完全依赖于主码，

（在1NF基础上消除非主属性对主码的部分函数依赖）
在上面那张表中主码为：学号+课程名称，但是姓名、系名、系主任都部分依赖于主码，比如系主任，不仅仅由学号+课程名称决定，也由系名决定。这不符合第二范式，所以进行拆分如下

第一张表主码为：学号、课程名称
第二张表主码为：学号
它们都是完全依赖的，因此符合第二范式。

第三范式（消除传递依赖）：在2NF的基础上，任何的非主属性不依赖于其他非主属性

（在第二范式基础上消除传递依赖）
注意看第二范式的学生表：存在系主任依赖于系名 （系名—> 系主任），系主任并不是由学号直接决定，而是学号 决定 系名，系名 决定 系主任。此时如果要添加一个新系和系主任，根本添加不了，因为没有主键。所以不符合第三范式，继续进行拆分

2. 维度建模

将数据划分为事实表和维度表

2.1.星型

不完全星型模型

事实表中，不是所有维度都按维度主键信息存储（维度退化）

• 地域维度信息：年月日周等时间维度信息，这些维度信息，基本不会发生任何改变，并且在大部分主题分析场景中，都需要使用，直接在事实表中存储维度值
• 页面信息：页面类别信息，频道信息，业务活动信息，会员等级信息等，可能发生缓慢变化的维度信息，事实表中遵循经典理论存储维度主键，具体维度值则在主题分析计算时临时关联

2.2.雪花型

2.3.星座型

基本上是很多数据仓库的常态，因为很多数据仓库都是多个事实表的。所以星座不星座只反映是否有多个事实表，他们之间是否共享一些维度表。
所以星座模型并不和前两个模型冲突。

3.维度建模的选择

首先就是星座不星座这个只跟数据和需求有关系，跟设计没关系，不用选择。
星型还是雪花，取决于性能优先，还是避免冗余、灵活更优先。
目前实际企业开发中，不会绝对选择一种，根据情况灵活组合，甚至并存（一层维度和多层维度都保存）。但是整体来看，更倾向于维度更少的星型模型。尤其是hadoop体系，减少join就是减少shuffle，性能差距很大。（关系型数据可以依靠强大的主键索引）

1. 数据结构上，雪花型更符合逻辑
2. ETL
3. 性能

4.怎么建模

https://zhuanlan.zhihu.com/p/392145761
你们主题如何建模，如何设计，表设计，维度设计，出现问题，如何解决？

1、选择业务过程
2、声明粒度
3、确认维度
4、确认用于度量的事实

项目相关

业务

项目做了什么

我们的教育大数据分析平台项目就是将大数据技术应用于教育行业,为企业经营提供数据支撑

• 用于哪个行业？行业有什么痛点是需要项目解决的
  教育行业，信息的共享和利用不充分，导致了学校多年信息化应用积累了大量的数据，但信息孤岛的壁垒一直没有打破，如果无法对这些数据进行进一步挖掘，分析，加工，整理，就不能给学校教育，教学，研发，总务等各方面的管理决策提供科学，有效的数据支撑。

解决了什么问题

一是数据量太大,现有Mysql数据库无法满足业务统计性能,效率需要。
二是系统多，数据分散。无法打通营销,咨询，报名，教学等业务环节的数据贯通
三是统计分析难度高,工作量大。缺乏规范存储，业务部门有需求时，需要程序员，DBA突击查数据，做报表，尤其是年底各部门排队等DBA协助出数据。

数据集市建设和成果，给了那些系统，哪些业务场景，什么样的数据，具体说明？

公司是有不同的部门（业务线），它们关心的东西不一样。各个部门（业务线）是只关系数仓数据中的某一个数据子集

数仓可以划分出很多的数据子集，这种模式称之为：数据集市

数据集市层的建设。主要是宽表和报表指标等信息。供哪些系统使用等

宽表：销售人员画像、客户画像、风控管理系统、理赔反欺诈模型、车险分析质量集市

报表指标：财务报表、理赔系统

宽表设计中影响到产出怎么解决？

指标分析你们主要是用的什么

用户画像（静态、动态标签，统计、规则、预测标签，衰退系数、标签权重）

推荐系统（协同过滤，基于用户、商品，SVD，各种距离算法等）

工作中如果做一个指标需要依赖于别人开发设计好的一张宽表，这种场景你们是怎么处理的？

数据质量管理你们是怎么做的

• 从4个方面来讲：准确性，一致性，唯一性，完整性 、
  准确(不准确的或无效的数据，金额不相等，身份证电话号码不正确)
  完整（数据记录丢失或不可用；数据属性不完整、空字段、脏数据）
  唯一（重复、重复数据、冗余数据）
  一致（源系统）
• 事前：定规则。表结构，业务规则，主键，空值处理等规则
  数据源、采集、传输、存储过程都会导致质量问题，KPI评估与考核。有变化及时通知下游，
  数据质量KPI评估与考核
• 事中：监控ETL任务。
  ETL任务管理和监控
  数据监控：监控指标、业务规则、质量规则，count条数，关键字段比较，定期复盘，每月做一次全量对比
• 事后：修正，改进
  补漏，查重

元数据管理：元数据的理解？元数据管理系统？ 元数据管理做了些什么?元数据管理怎么做的？

表的血缘分析： 表的上下游依赖关系
表，字段信息管理 show create table xxx ；desc

• 数据源元数据
  例如：数据源的 IP、端口、数据库类型；数据获取的方式；数据存储的结构；原数据各列的定义及 key 指对应的值。
• ETL 元数据（ETL抽取规则方法，清洗规则）
  根据 ETL 目的的不同，可以分为两类：数据清洗元数据；数据处理元数据。
  数据清洗元数据
  数据清洗，主要目的是为了解决掉脏数据及规范数据格式；
  因此此处元数据主要为：各表各列的"正确"数据规则；默认数据类型的"正确"规则。
  数据处理元数据
  数据处理，例如常见的表输入表输出；非结构化数据结构化；特殊字段的拆分等。
  源数据到数仓、数据集市层的各类规则。比如内容、清理、数据刷新规则。
• 数据仓库元数据
  数据仓库结构的描述，包括仓库模式、视图、维、层次结构及数据集市的位置和内容；
  业务系统、数据仓库和数据集市的体系结构和模式等。

CDH整合Apache Atlas 元数据和血缘管理（数据治理）

数据资产管理

主数据管理：数仓建设规范&数据标准

数仓层级规范
表明规范：dim_、tmp_、DW_
字段规范

建表（表结构）：
名称、编码、类型、长度、业务含义、数据来源、质量规则、安全级别、域值范围等
表名需要见名知意，通过表名就可以知道它是哪个业务域，干嘛用的，什么粒度的数据。

常规表

常规表是我们需要固化的表，是正式使用的表，是目前一段时间内需要去维护去完善的表。规范：分层前缀[dwd|dws|ads|bi]业务域主题域XXX粒度 业务域、主题域我们都可以用词根的方式枚举清楚，不断完善，粒度也是同样的，主要的是时间粒度、日、月、年、周等，使用词根定义好简称。

中间表

中间表一般出现在Job中，是Job中临时存储的中间数据的表，中间表的作用域只限于当前Job执行过程中，Job一旦执行完成，该中间表的使命就完成了，是可以删除的（按照自己公司的场景自由选择，以前公司会保留几天的中间表数据，用来排查问题）。规范：mid_tablename [0~9|dim] table_name是我们任务中目标表的名字，通常来说一个任务只有一个目标表。这里加上表名，是为了防止自由发挥的时候表名冲突，而末尾大家可以选择自由发挥，起一些有意义的名字，或者简单粗暴，使用数字代替，各有优劣吧，谨慎选择。通常会遇到需要补全维度的表，这里我喜欢使用dim结尾。

中间表在创建时，请加上 ,如果要保留历史的中间表，可以加上日期或者时间戳

临时表

临时表是临时测试的表，是临时使用一次的表，就是暂时保存下数据看看，后续一般不再使用的表，是可以随时删除的表。规范：tmp_xxx 只要加上tmp开头即可，其他名字随意， 注意tmp开头的表不要用来实际使用，只是测试验证而已。

维度表

维度表是基于底层数据，抽象出来的描述类的表。维度表可以自动从底层表抽象出来，也可以手工来维护。规范：dim_xxx 维度表，统一以dim开头，后面加上，对该指标的描述，可以自由发挥。

手工表

手工表是手工维护的表，手工初始化一次之后，一般不会自动改变，后面变更，也是手工来维护。一般来说，手工的数据粒度是偏细的，所以，暂时我们统一放在dwd层，后面如果有目标值或者其他类型手工数据，再根据实际情况分层。规范：dwd _ 业务域manual xxx 手工表，增加特殊的主题域，manual，表示手工维护表
指标

指标的命名也参考词根，避免出现同一个指标，10个人有10个命名方法。

具体操作结合公司实际情况，规范及早制定。

技术

基本情况

你们的原始数据一共有多张数据表？
ODS三千张表，DWD：几百张，DWS：几十张，ADS:根据系统需求来
哪些业务系统？
一共有多少个需求？
业务上用到哪些表？
你们集群是什么规模？每台服务器什么配置？
你们工作中实际的工作流程是怎么样的？

用到了什么技术

调优

讲项目

概述

架构做了些有亮点设计
业务上带来很大价值

建设流程

理现状：了解业务现状、数据现状、IT现状、现有的组织架构
定架构：确认业务架构、技术架构、应用架构、组织架构
建资产：建立贴近数据层、统一数仓层、标签数据层、应用数据层
用数据：对数据进行输出、应用
数据运营：持续运营、持续迭代

中台建设需要多部门合作，由管理层从上往下推进，由技术和业务人员去执行和落地，在实施数据中台时，最困难的地方就是业务和技术人员的沟通，确定好模型和需求。

背景介绍

主要是将分层，每层干什么，并说下主题是什么划分的
数据治理，数据服务

亮点

• 下游系统要求 时间限制，几点前
  过程分析：1/2/3/4、
  最终方案：调度和架构上：准实时: ，hive–>kudu,

• 中台数据不能满足应用的所有需求，是否需要扩展表和字段来满足需求
  过程分析： 应用与中台的权衡。中台尽量通用，轻量级，不建议厚重，某字段至少多个应用使用才公共字段，通用字段，下沉，做到明细通过，如果是某个系统特定场景使用则不做
  最终方案：中台模型的调整