数仓笔记

发表于 | 分类于 | 次

数仓笔记

1.维表和宽表的考查（主要考察维表的使用及维度退化手法）

维表数据一般根据ods层数据加工生成，在设计宽表的时候，可以适当的用一些维度退化手法，将维度退化到事实表中，减少事实表和维表的关联

2.数仓表命名规范

每个公司都会有点差别

ODS

ods.库名_表名_df/di/da/dz

CDM(dwd/dws)

dwd.主题_内容_df

3.拉链表的使用场景

1.数据量比较大

2.表中的部分字段会被更新

3.需要查看某一个时间点或者时间段的历史快照信息

​ 查看某一个订单在历史某一个时间点的状态
​ 某一个用户在过去某一段时间，下单次数

4.更新的比例和频率不是很大
如果表中信息变化不是很大，每天都保留一份全量，那么每次全量中会保存很多不变的信息，对存储是极大的浪费

4.一亿条数据查的很慢,怎么查快一点

5.有什么维表

时间维表，用户维表，医院维表等

6.数据源都有哪些

业务库数据源:mysql,oracle,mongo

日志数据：ng日志，埋点日志

爬虫数据

7.你们最大的表是什么表,数据量多少

ng日志表，三端(app,web,h5)中app端日志量最大，清洗入库后的数据一天大概xxxxW

8.数仓架构体系

9.数据平台是怎样的，用到了阿里的那一套吗？

没用到阿里那一套，数据平台为自研产品

10.你了解的调度系统有那些？，你们公司用的是哪种调度系统

airflow，azkaban，ooize，我们公司使用的是airflow

11.你们公司数仓底层是怎么抽数据的？

业务数据用的是datax

日志数据用的是logstash

12.为什么datax抽数据要比sqoop 快？

13.埋点数据你们是怎样接入的

logstash–>kafka–>logstash–>hdfs

14.如果你们业务库的表有更新，你们数仓怎么处理的？

根据表数据量及表特性，选择用全量表，增量表，追加表和拉链表处理

15.能独立搭建数仓吗

16.搭建过CDH 集群吗

17.说一下你们公司的大数据平台架构？你有参与吗？

18.介绍一下你自己的项目和所用的技术

19.对目前的流和批处理的认识？就是谈谈自己的感受

20.你了解那些OLAP 引擎，MPP 知道一些吗？clickHouse 了解一些吗？你自己做过测试性能吗？

Kylin、druid、presto

MPP架构

  • 任务并行执行;
  • 数据分布式存储(本地化);
  • 分布式计算;
  • 私有资源;
  • 横向扩展;
  • Shared Nothing架构。

什么是ClickHouse

ClickHouse是一个快速的开源OLAP数据库管理系统, 它是面向列的，并允许使用SQL查询实时生成分析报告。
也是一个新的开源列式数据库。

ClickHouse 亮点

  1. 急速处理
  2. 硬件效率高
  3. 线性可扩展
  4. 容错
  5. 功能丰富
  6. 高度可靠

21.Kylin 有了解吗？介绍一下原理

Kylin的出现就是为了解决大数据系统中TB级别数据的数据分析需求，它提供Hadoop/Spark之上的SQL查询接口及多维分析(OLAP)能力以支持超大规模数据，它能在亚秒内查询巨大的Hive表。其核心是预计算，计算结果存在HBase中.

基本原理

Kylin的核心思想是预计算。

理论基础是：以空间换时间。即多维分析可能用到的度量进行预计算，将计算好的结果保存成Cube并存储到HBase中，供查询时直接访问。

大致流程：将数据源(比如Hive)中的数据按照指定的维度和指标，由计算引擎Mapreduce离线计算出所有可能的查询结果(即Cube)存储到HBase中。HBase中每行记录的Rowkey由各维度的值拼接而成，度量会保存在column family中。为了减少存储代价，这里会对维度和度量进行编码。查询阶段，利用HBase列存储的特性就可以保证Kylin有良好的快速响应和高并发。

22.datax 源码有改造过吗

没有

23.你们数仓的APP 层是怎么对外提供服务的？

1.直接存入mysql业务库，业务方直接读取

2.数据存入mysql，以接口的形式提供数据

3.数据存入kylin，需求方通过jdbc读取数据

24.数据接入进来，你们是怎样规划的，有考虑数据的膨胀问题吗

25.简述拉链表，流水表以及快照表的含义和特点

拉链表：

（1）记录一个事物从开始，一直到当前状态的所有变化的信息；
（2）拉链表每次上报的都是历史记录的最终状态，是记录在当前时刻的历史总量；
（3）当前记录存的是当前时间之前的所有历史记录的最后变化量（总量）；
（4）封链时间可以是2999，3000，9999等等比较大的年份；拉链表到期数据要报0；

流水表：对于表的每一个修改都会记录，可以用于反映实际记录的变更
　区别于拉链表：　
拉链表通常是对账户信息的历史变动进行处理保留的结果，流水表是每天的交易形成的历史；
流水表用于统计业务相关情况，拉链表用于统计账户及客户的情况

快照表：
按天分区，每一天的数据都是截止到那一天mysql的全量数据

26.全量表(df),增量表(di),追加表(da)，拉链表(dz)的区别及使用场景

全量表

  1. 全量表，有无变化，都要报
  2. 每次上报的数据都是所有的数据（变化的 + 没有变化的）

增量表：新增数据，增量数据是上次导出之后的新数据。

  • 记录每次增加的量，而不是总量；
  • 增量表，只报变化量，无变化不用报
  • 每天一个分区
  • 业务库表中需要有主键及创建时间，修改时间

27.你们公司的数仓分层，每一层是怎么处理数据的

ODS层

  • 存放未经过处理的原始数据至数据仓库系统，结构上与源系统保持一致，是数据仓库的数据准备区

数据公共层CDM：

  • 公共维度层（DIM）：基于维度建模理念思想，建立整个企业的一致性维度。降低数 据计算口径和算法不统一风险。
  • 公共汇总粒度事实层（DWS）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。
  • 明细粒度事实层（DWD）：以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。

ADS层

数据应用层ADS（Application Data Service）：存放数据产品个性化的统计指标数据。根据CDM与ODS层加工生成。

28.什么是事实表，什么是维表

​ 事实表（Fact Table）是指存储有事实记录的表，如系统日志、销售记录等；事实表的记录在不断地动态增长，所以它的体积通常远大于其他表。
​ 维度表（Dimension Table）或维表，有时也称查找表（Lookup Table），是与事实表相对应的一种表；它保存了维度的属性值，可以跟事实表做关联；相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。常见的维度表有：日期表（存储与日期对应的周、月、季度等的属性）、地点表（包含国家、省／州、城市等属性）等。

29.星型模型和雪花模型

  • 星形模型中有一张事实表，以及零个或多个维度表，事实表与维度表通过主键外键相关联，维度表之间没有关联，当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故将该模型称为星型模型。
  • 当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。

30.数据建模一般有哪几种方式，你们公司是用哪种方式进行数据建模的

ER模型

维度模型

Data Vault模型

Anchor模型

我司用的是维度建模

31.有没有实际工作中碰到的sql调优的例子，举例说明

见博客hive调优

32.你觉得数据仓库应该如何搭建，数据规范和标准如何落地

33.如何保证你们公司的数据质量

如何提升数据质量

1.事前定义数据的监控规则

  • 提炼规则：梳理对应指标、确定对象（多表、单表、字段）、通过影响程度确定资产等级、质量规则制定

2.事中监控和控制数据生产过程

  • 质量监控和工作流无缝对接
  • 支持定时调度
  • 强弱规则控制ETL流程
  • 对脏数据进行清洗

3.事后分析和问题跟踪

  • 邮件短信报警并及时跟踪处理
  • 稽核报告查询
  • 数据质量报告的概览、历史趋势、异常查询、数据质量表覆盖率
  • 异常评估、严重程度、影响范围、问题分类

34.对元数据的理解，元数据管理的意义及应用场景有哪些

  • 元数据主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及 ETL 的任务运行状态。在数据仓库系统中，元数据可以帮助数据仓库管理员和开发人员非常方便地找到他们所关心的数据，用于指导其进行数据管理和开发工作，可以极大的提升工作的效率。
  • 元数据有重要的应用价值，是数据管理、数据内容、数据应用的基础，在数据管理方面为集团数据提供在计算、存储、成本、质量、安全、模型等治理领域上的数据支持。例如在计算上可以利用元数据查找超长运行节点，对这些节点进行专项治理，保障基线产出时间。在数据内容方面为集团数据进行数据域、数据主题、业务属性等的提取和分析提供数据素材。例如可以利用元数据构建知识图谱，给数据打标签，清楚地知道现在有哪些数据。在数据应用方面打通产品及应用链路，保障产品数据准确、及时产出。例如打通DP和应用数据，明确数据产等级，更有效地保障产品数据。
  • 数据的真正价值在于数据驱动决策，通过数据指导运营。通过数据驱动的方法，我们能够判断趋势 ，从而展开有效行动，帮助自己发现问题，推动创新或解决方案的产生。这就是数据化运营。同样，对于元数据，可以用于指导数据相关人员进行日常工作，实现数据化“运营”。 比如对于数据使用者，可以通过元数据让其快速找到所需要的数据；对于ETL 工程师，可以通过元数据指导其进行模型设计、任务优化和任务下线等各种日常ETL 工作；对于运维工程师，可以通过元数据指导其进行整个集群的存储、计算和系统优化等运维工作。

35.如何判别模型的好坏，模型设计的原则有哪些

基本原则：

  • 高内聚和低耦合

    一个逻辑或者物理模型由哪些记录和字段组成，应该遵循最基本的软件设计方法论的高内聚和低耦合原则，主要从数据业务特性和访问特性两个角度来考虑：将业务相近或者相关，粒度相同的数据设计为一个逻辑或者物理模型，将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储

  • 核心模型与扩展模型分离
    建立核心模型与扩展模型体系，核心模型包括的字段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要，不能让扩展模型的字段过度侵入核心模型，以免破坏核心模型架构简洁性与可维护性

  • 公共处理逻辑下沉及单一
    越是底层共用的处理逻辑越应该放在数据调度依赖的底层进行封装与实现，不要让共用的处理逻辑暴露给应用层实现，不要让公共逻辑多处同时存在

  • 成本与性能平衡
    适当的数据冗余可换取查询和刷新性能，不宜过度数据冗余和数据复制

  • 数据可回滚
    处理逻辑不变，在不同时间多次运行数据结果确定不变

  • 一致性
    具有相同含义的字段在不同的表中的命名必须相同，必须使用规范定义中的名称

  • 命名清晰,可理解
    表命名需清晰，一致，表名需易于消费者理解和使用

36.对于数据中台的理解，和数据仓库，数据湖的区别

数据仓库(Data Warehouse)是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化的（Time Variant）数据集合，用于支持管理决策和信息的全局共享。

数据湖（Data Lake）是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。

数据中台是一个承接技术，引领业务，构建规范定义的、全域可连接萃取的、智慧的数据处理平台，建设目标是为了高效满足前台数据分析和应用的需求。数据中台距离业务更近，能更快速的相应业务和应用开发的需求，可追溯，更精准。

数据湖、数据仓库更多地是面向不同对象的不同形态的数据资产，而数据中台更多强调的是服务于前台，实现逻辑、标签、算法、模型的复用沉淀。

数据中台像一个“数据工厂”，涵盖了数据湖、数据仓库等存储组件，随着数据中台的发展，未来很有可能数据湖和数据仓库的概念会被弱化。

37.对于数据仓库的理解，数据仓库主要为解决什么问题

（1）数据仓库能够为业务部门提供准确、及时的的报表。

（2）数据仓库可以赋予管理人员更强大的分析能力。

（3）数据仓库是进行数据挖掘、知识发现的基础。

38.数据仓库模型的理解，数据仓库分层设计的好处是什么

  • 清晰数据结构：每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
  • 数据血缘追踪：简单来讲可以这样理解，我们最终给业务呈现的是一张能直接使用的张业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。
  • 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
  • 把复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。

39.数仓主题划分的标准和依据

关于主题：

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

关于主题域：

主题域通常是联系较为紧密的数据主题的集合。可以根据业务的关注点，将这些数据主题划分到不同的主题域(也说是对某个主题进行分析后确定的主题的边界。)

关于主题域的划分：

主题域的确定必须由最终用户和数据仓库的设计人员共同完成的， 而在划分主题域时，大家的切入点不同可能会造成一些争论、重构等的现象，考虑的点可能会是下方的某些方面：

  1. 按照业务或业务过程划分：比如一个靠销售广告位置的门户网站主题域可能会有广告域，客户域等，而广告域可能就会有广告的库存，销售分析、内部投放分析等主题；
  2. 根据需求方划分：比如需求方为财务部，就可以设定对应的财务主题域，而财务主题域里面可能就会有员工工资分析，投资回报比分析等主题；
  3. 按照功能或应用划分：比如微信中的朋友圈数据域、群聊数据域等，而朋友圈数据域可能就会有用户动态信息主题、广告主题等；
  4. 按照部门划分：比如可能会有运营域、技术域等，运营域中可能会有工资支出分析、活动宣传效果分析等主题；

40.缓慢变化维如何处理，几种方式

缓慢变化维：

数据仓库的重要特点之一是反映历史变化，所以如何处理维度的变化是维度设计的重要工作之一。缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流逝发生缓慢的变化，与数据增长较为快速的事实表相比，维度变化相对缓慢。

在一些情况下，保留历史数据没有什么分析价值，而在另一些情况下,保留历史数据是非常重要的，在kimball理论中，有三种处理缓慢变化维的方式

1.重写纬度值

采用此种方式，不保留历史数据，始终取最新数据

2.插入新的维度行

插人新的维度行。采用此种方式，保留历史数据，

维度值变化前的事实和过去的维度值关联，维度值变化后的事实和当前的维度值关联

3.添加维度列

采用第二种处理方式不能将变化前后记录的事实归一为变化前的维度或者归一为变化后的维度。比如根据业务需求，需要将4月份的交易金额全部统计到类目2上，采用第二种处理方式无法实现。针对此问题，采用第三种处理方式，保留历史数据，可以使用任何一个属性列