读书笔记丨《数据产品经理修炼手册:从零基础到大数据产品实践》丨DAY4
日期:2022年7月24日
内容:第四章数据仓库理论与应用(p77-p104)
4.1 了解大数据基础Hadoop
一、Hadoop及三驾马车
01.什么是hadoop？
二.HDFS:数据的存储
[那么有效、快速地处理数据呢？]——>MapReduce/Spark
三.MapReduce/Spark:数据的处理
三、Pig/Hive数据的封装
四、补充
01.现在的发展：现在的Hadoop已经从上面提到的Hadoop三驾马车逐渐发展为60多个相关组件构成的庞大生态家族，其中在各大发行版中就包含30多个组件，包含了数据框架、数据存储和执行引擎等。
02.现今流行的，两个“大数据处理框架”Hadoop 和Spark：
1.Spark、Spark MLib、Spark GraphX和Spark Streaming组成了Spark 生态圈，其余部分组成了Hadoop生态圈组。
五、其他基础工具介绍：
六、其他常用工具介绍：
4.2 大数据平台层级结构
一、初步了解大数据平台架构
3.数据应用层，主要用于处理消费数据仓库的数据，后面介绍的大数据分析平台和行为分析平台等都是数据应用层的典型示例。
二、走近大数据技术架构
part1：ODS层（原始数据层）
01基础了解
1.定义：Operational Data Store，翻译成中文为‘操作型数据存储’，是面向主题的、集成的、可变的、反映当前数据值的、详细的数据的集合，用来满足企业综合的、集成的和操作型的处理需求。
2.ODS的数据来源：主要部分来自，客户端用户操作日志，它是分析App和产品优化的基础；另一部分来源于业务的数据库，例如订单的交易情况。
3.ODS层的表通常包括两类：一类用于存储当前需要加载的数据；另一类用于存储处理完后的历史数据。
历史数据一般保存3～6个月后需要清除，以节省空间。但不同的项目要区别对待，如果源系统的数据量不大，可以保留更长的时间，甚至全量保存。
02进阶了解——为什么需要ODS层？
（1）在业务系统和数据仓库之间形成一个隔离层
原因：
1.数据仓库的数据来源，一般比较复杂（这些数据存放在不同的地理位置、不同的数据库、不同的应用之中），因此，直接从业务系统中对数据进行抽取并不是一件容易的事。
2.ODS层属于业务层范畴,所以用于存放从业务系统中，直接抽取出来的数据。
3.这些数据从数据结构、数据之间的逻辑关系上，都与业务系统基本保持一致性。
4.ODS层在抽取过程中，主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题，从而极大地降低了数据转化的复杂性。
（2）转移一部分业务系统细节查询的功能。
原因：
1.合理分担运行压力。在数据仓库建立之前，大量的报表、分析是由业务系统直接支持的，在一些比较复杂的报表生成过程中，对业务系统的运行产生了相当大的压力。
2.而ODS层的数据在粒度、组织方式等方面都保持了与业务系统的一致性，那么原来由业务系统产生的报表、详细数据的查询，自然能够从ODS层中进行，从而降低了业务系统的查询压力。
（3）完成数据仓库中不能完成的一些功能。
原因：
1.数据处理，必然会牺牲细节内容。一般来说，在带有ODS层的数据仓库体系结构中，数据仓库所存储的数据都是汇总过的数据和运营指标，并不存储每笔交易产生的详细数据，但是在某些特殊的应用中，可能需要对交易详细数据进行查询，例如跟踪埋点错误的问题，这时就需要把详细数据查询的功能转移到ODS层完成，而且ODS层的数据模型按照面向主题的方式存储，可以方便地支持多维分析等查询功能。
即数据仓库从宏观角度满足企业的决策支持要求，而ODS层则从微观角度反映细节交易数据或者低粒度的数据查询要求。
part2：数据仓库
01基础了解
1.定义：数据仓库（Data Warehouse，DW）是为了方便企业快速做各种业务决策提供数据支撑而构建的集成化数据环境。 有一句话能很好地体现数据仓库的这一点，数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因。
数据仓库主要有以下三个特点：
（1）数据仓库是面向主题的，它会按照一定的主题进行组织。主题是指业务方使用数据仓库决策时所关心的重点方向，一般会根据业务线情况划分。
（2）数据仓库是集成的。数据仓库中的数据可能来源于多个数据源，数据仓库会将需要的数据从中抽取出来，然后进一步转化、清洗，再集成到数据仓库中。
（3）数据仓库是不可更新的。数据仓库主要是为业务提供分析决策的数据，因此，对数据的主要操作都是查询。
2.数据仓库的数据，如何才能为业务高效快速分析？：
（1）效率足够高。数据仓库的分析数据一般分为日、周、月、季、年等，可以看出，以日为周期的数据要求的效率最高。
（2）数据质量。数据仓库处理流程通常分为多个步骤，包括数据清洗、转换、装载等，如果数据质量控制不好，导致出现脏数据，就会影响整个数据仓库的质量，如果基于错误的数据做分析，就可能导致做出错误的决策。
（3）可扩展性。可扩展性主要体现在数据建模的合理性，便于以后因为业务规模发生变化而不用重复造轮子。
3.根据数据仓库处理的数据层次不同，数据仓库主要分为基础层、主题层、数据集市这三层。
1.基础层
#基础层的主要作用：是对ODS层，数据进行轻度汇总，产出轻度汇总明细、维度表、码表、事实集等一些基础数据。
#数据模型是抽象描述现实世界的一种工具和方法，可以对数据进行模型处理。 首先，生成业务模型，主要解决业务方面的分层； 然后完成领域模型，基于业务模型的基础进行抽象处理； 接着，将领域模型的实体与实体的关系进行数据库层次的逻辑化，也就是所谓的逻辑建模； 最后，生成物理模型，用来完成对不同关系型数据库的物理化以及性能等具体技术问题。
##数据模型的层次划分：
因此，在整个数据仓库的基础层模型设计中，要在了解业务的基础上，掌握过硬的技术，能够构建一个既合理又高效的模型，需要相当丰富的行业经验。数据产品经理在这方面只需略知皮毛，至于如何针对我们的业务进行抽象、处理、生成各个阶段的模型，还是交给更专业的数据仓库工程师来做吧。
2.主题层
主题层为数据的高度聚合层，按照一定的维度和业务逻辑，对一类数据进行聚合，主要生成画像表和主题表。主题层的数据来源是基础层和ODS层。
主题层的特点：
- 从数据粒度来说，这层的数据是轻度汇总级的数据，已经不存在明细数据了；
- 从数据的时间跨度来说，主题层通常是基础层的一部分，主要的目的是满足用户分析某个主题的需求；
- 从分析的角度来说，用户通常只需要分析近几年（如近三年）的数据即可；
- 从数据的广度来说，主题层仍然覆盖了所有业务数据。
例如，在共享单车的数据仓库设计中，通常根据业务将主题层分为用户主题、车辆主题、支付主题、行程主题等，为了平衡业务前台的快速变化与数据仓库稳定性的需求，在设计主题层的时候，通常要与业务中台保持一致。
3.数据集市
数据集市（Data Mart）也叫数据市场，主要功能是将主题层和基础层的数据按各业务需求进行聚合，生成宽表和Cube，并直接推送给数据分析和业务部门使用，例如直接推送表数据至MySQL数据库。
数据集市由很多非常宽的表组成，比如GMV（网站成交金额）的表，除了包含订单和金额等必需的字段，还包含可能使用的SKU（库存量单位）产品信息、用户基本信息等，是数据仓库的核心组成部分。
数据集市是数据仓库的一部分，主要面向各业务部门使用，并且仅面向某个特定的主题。
为了解决灵活性和性能之间的矛盾，数据集市可以被理解为一种小型的主题或业务级别的数据仓库。数据集市会根据业务的主题情况，存储为特定用户预先计算好的数据，从而满足性能方面的要求。因此，数据集市可以在一定程度上缓解访问的速率瓶颈。
数据集市会根据不同的业务主题，划分来满足业务信息需求，合格的就有什么特点？：
- （1）数据集市表是为了解决特定业务需求的，更具有面向主题性。
- （2）在更多情况下，数据集市支持离线数据，在一般情况下，业务经常使用的是T+1数据，即今天看昨天的数据。
- （3）数据来源于多个方面，比如业务订单数据、前端用户使用数据以及外部来源数据等。
- （4）查询时间尽量短，为分析和查询尽快响应。
数据集市中数据的结构一般是星型结构或者雪花结构，而星型结构通常由事实表和维度表构成。
（1）事实表。事实表用于记录数据集市表中的详细数据。在共享单车企业中，用于记录用户骑行的数据是典型的最密集的数据；在银行中，与账目核对和自动柜员机有关的数据是典型的最密集的数据；对于零售业而言，销售和库存数据是最密集的数据。事实表会首先把多种类型的数据连接在一起。例如，一个订单、一次骑行等都会以主键的方式存储在表中，然后与维度表的主键关联。因此，事实表是高度索引化的，表中经常会出现几十条索引，甚至有时事实表的每列都建了索引，这样在查询时速度会进一步提升。
（2）维度表。维度表是围绕事实表建立的。维度表里的数据主要用来存储维度数据，主要是一些非密集型数据，包括客户端的版本、操作系统、车型等。
如何设计数据集市呢？其实，这更应该是数据仓库工程师的任务，数据产品经理仅仅了解就可以了。
part3：数据应用层
大数据的分析应用主要分为以下三种形式:【描述-预测-指导】
01、第一种是描述性分析应用。
主要用来描述所关注的业务的数据表现，主要关注事情表面发生了什么，在数据分析之后，把数据可视化展现出来，让用户可以了解业务的发展状况。
02、第二种是预测性分析应用。
在描述性数据的基础上，根据历史数据情况，在一定的算法和模型的指导下，进一步预测业务的数据趋势。例如，美国历年的总统大选预测结果、天气预报预测天气等都属于预测性分析。
03、第三种是指导性分析应用。
基于现有的数据和对未来的预测情况，可以用来指导完成一些业务决策和建议。例如为公司制订战略和运营决策，真正通过数据驱动决策，充分发挥大数据的价值。
4.3 数据埋点
数据埋点，是一种常用的数据采集方法。埋点是数据采集的来源，采集的数据是后续建立数据产品的基础。
4.3.0 什么是埋点？
埋点：又称为事件追踪（Event Tracking），指的是针对特定用户行为或事件进行捕获，处理和发送的相关技术及其实施过程。
功能方面：埋点是用来收集用户行为数据。
4.3.1 埋点方式
前端的埋点方式主要分为代码埋点、可视化埋点、无埋点三种。
通过植入一段代码到某个页面或某个按钮，从而监听用户行为并进行收集上报。
1.代码埋点
- 代码埋点，主要由App研发工程师手工在程序中写代码实现，通过触发某个动作后程序自动发送数据。
- 优点：具有很强的灵活性，可以控制发送的时机和发送方式等。
- 缺点：人力成本较高，需要研发工程师手工开发程序，有时候还要依赖App发版来生效。
2.可视化埋点
- 可视化埋点，以前端可视化的方式记录前端设置页面元素与对其操作的关系（比如鼠标移动角度和轨迹），然后以后端截屏的方式统计数据。
- 优点：简单、方便，能够快速地埋点。
- 缺点：比较受限，上报的行为信息有限。
3.无埋点
- 无埋点，绑定页面的各个控件，当事件触发时就会调用相关的接口上报数据。
- 优点：不需要埋点，方便、快捷、省事。
- 缺点：传输数据量比较大，需要消耗一定的数据存储资源。
4.补充[前后端埋点的优缺点比较]:前端埋点和后端埋点，哪个更科学？ | 人人都是产品经理 (woshipm.com)
数据埋点有客户端前端埋点和服务器后端埋点。客户往往要求一起前后端埋点
后端埋点:
- 只要有网络请求就可以记录被实时收集，不存在延时上报的问题。
- 没有网络，就无法进行后端埋点。
- 用户需要请求服务器的关键业务量最好均使用服务器后端埋点。 如在线播放、游戏安装等。还有例如要根据埋点数据统计中奖用户信息，显然服务器后端数据更合理
前端埋点：
- 适用于 处于运营初级阶段，产品功能相对简单；需要分析与后端没有交互的前端行为的企业
- 像点击、浏览、曝光这些行为便可以用前端埋点，主要是发生在用户与界面的交互 需要前端埋点
- 若运营人员工作需要判断前端界面设计是否合理，是必须采用前端埋点方案的
- 由于前端埋点和后端埋点的埋点方式不同，统计的数据难免有差异，不要纠结于两者的数据为什么对不上，而更应该结合两者互相验证。
- 根据行业领先企业实践来看，后端代码埋点才是距精细化运营最近的数据采集方式；
4.3.2 埋点事件
在记录埋点信息时，主要的埋点事件分为点击事件、曝光事件和页面停留时长三类。
1.点击事件
- 用户每点击页面上的一个按钮一下都会记录一次数据。
- 如图4-7所示的美团主页资源位的“酒店住宿”按钮，当用户点击一次“酒店住宿”按钮时，便会统计一次点击事件。
2.曝光事件
- 当用户成功地进入一个页面时记录一次数据，当刷新一次页面时也会记录一次数据，如果通过手机Home键切换出去，则不会记录，因为已经脱离了App，此处记录也没有太大的分析价值，记录上来可能污染数据。
- 如图4-8所示，如果用户进入酒店住宿页面，那么便会上报一次酒店住宿的曝光事件。
3.页面停留时长
- 页面停留时长主要用来记录用户在一个页面的停留时间，它可以通过记录用户进入页面的时间t1和离开页面的时间t2计算，计算公式可以简单地表示为：用户停留时间=离开页面时间t2-进入页面时间t1。
- 还以酒店住宿页面为例，当用户进入页面的时候记录一个时间t1，当逛完离开后记录一个时间t2，t2-t1就是用户在酒店住宿页面的停留时长。
4.4 指标字典
4.4.1 指标字典的基本概念
- 指标字典，是业务数据标准化的基础。指标字典的建立，是搭建数据平台的基础。
- 目的是对指标进行统一管理，方便共享，达成对业务指标的共识，并且统一修改和维护。
- 指标字典可以更新在Excel或者Wiki中。如果有足够多的资源，那么开发指标管理模块可以放在数据管理系统中，再配合血缘关系，就更方便追踪数据流转了。
设计指标字典的主要目的有以下四个：
（1）规范维度和量度命名，命名规则要尽量做到明确、通用、易懂。
（2）对维度或量度统一计算口径，避免歧义。
（3）涵盖尽可能多的关注的核心维度和量度，以此为基础推动数据建设，确保指标字典里覆盖的维度都可区分、指标都可统计。
（4）基于指标字典，将核心维度和量度注入元数据中心，接入指标提取工具，后续实现不需要写SQL语句即可完成自助查询及分析需求。
1.指标
- 定义：衡量目标的方法。
- 构成要素：维度+汇总方式+量度。
- （1）维度回答从哪些角度去衡量的问题。
- （2）汇总方式回答用哪些方法去衡量的问题。
- （3）量度回答目标是什么的问题。
2.量度
- 定义：量度是对一个物理量的测定，通常以数字+计量单位表示。比如，金额、份额、次数、率。
- 我们做一个相关思考：请看问题：你有没有“2”？第一反应：“2”是什么？“2”是指你有没有2元钱，你有没有2次出国经历，还是你有没有2张电影票？回答：数据=数字+计量单位。
3.维度
- 定义：维度是看待事物的视角与方向。
- 我们做一个相关思考：提问：怎么衡量一个人？请看问题：你认为哥哥我是个什么样的人？脱口而出：从性别的角度看，你是个男人；从颜值的角度看，你是个很帅的人；从高考成绩的角度看，你是个考了600分的人；从高考中数学成绩的角度看，你是个考了150分的人。回答：从不同的角度去衡量一个人。根据不同的角度，衡量一个人的指标是不一样的。
4.4.2 指标定义的规范丨怎么定义一个指标字典是合格的呢，有没有什么规范可以遵守呢？
指标的一义性：一个指标一经录入，它的命名和所有下钻维度的口径都已确定（默认口径），这称为指标的一义性。
一个在某些维度上口径不确定的“指标”是不能被使用的，在业务场景中是毫无意义的。
指标一般分为基础指标、普通指标和计算指标三类。
1.基础指标
例如，“团购交易额”作为一个基于单纯实体的属性的简单计算，它没有更上游的指标，即它的父指标是它自身。我们称这样的指标为基础指标。
2.普通指标
所谓普通指标，即在单一父指标的基础上通过一些维度上的取值限定可以定义的指标。
例如，对于团购中PC端首次购买用户数，限制条件为首次购买用户中下单平台=PC。
3.计算指标
可以在若干个注册指标之上通过四则运算、排序、累计或汇总定义出的指标称为计算指标。
量度和维度都考虑好了，在构建一个指标字典时我们应该考虑哪些要素呢？表4-3为建立指标字典的要素。
指标字典，通常包含指标维度和指标量度两个部分
4.5 数据管理系统
4.5.1 数据质量的重要性——可读性
- 数据质量：通常指数据的准确性——包括数据的一致性、数据的完整性和数据的最小性。
- 在大数据时代下，数据的来源越来越多，数据量也越来越大，准确性不再是衡量数据质量的唯一标准，数据的可读性成为大数据时代下影响数据质量的更关键的因素。
- 为了追求业务分析数据的效率，数据质量中的数据可读性就变得越来越重要，人们更加关心数据分析的效率及数据在各系统中获取的速率，数据的可读性便成了数据质量指标中至关重要的一环
- 建立指标字典就是保障数据可读性的基础。如果数据的可读性非常差，就会浪费很多的时间来分析数据，更严重的是在大数据平台中，难以满足各种业务应用场景下的需求与决策支持。
4.5.2 数据管理系统的质量检测
数据管理系统，侧重于从时效性和一致性两大质量方向，保证数据的可读性。
1.数据仓库的数据时效性检查
明确每天的每一个层级、每一个数据表的最早和最晚生成时间，发现影响当天数据生成延误的数据表，并能够通过数据管理系统回答以下问题：
- 当天MySQL表和Hive表中的核心指标是何时生成的？
- 有哪些表的产出时间比预期时间延迟了？
- 任务延迟的原因是由哪几张表造成的？
- 瓶颈在哪里？优化哪几层？哪几张表可以提高核心指标等的生成时间？
2.数据仓库的数据一致性检查
通过数据一致性检查，在数据质量视图的展现下，我们可以快速了解存在依赖关系的数据表的分维度数据变化情况。
为了对数据一致性进行检查。首先，需要监测数据库中每一张表的维度和指标数据。
然后，建立逻辑比较关系，把每个数据表的每一个指标之间建立联系。
因此，大数据管理系统项目，需要做的事情主要分为以下几步：
- 第一步，建立数据依赖引擎，实现依赖图谱。依赖图谱用于构建数据仓库表之间的分层级依赖关系，然后存入MySQL表并能支持可视化展现。
- 第二步，计算数据准备情况。各个表、各个分区的数据准备就绪时间按天、小时级进行汇总。根据Hive 仓库的Meta信息可以获取Hive表各个分区的创建时间，根据创建时间确定数据的实效性，用来分析展现每天、每小时的状态和瓶颈。如果需要对MySQL进行验证则通过SQL语句查询的方式获取对应时间在MySQL中是否存在。
- 第三步，建立数据计算引擎。根据定义的小时级指标、天级别指标规则，结合数据表各个分区的准备就绪时间，调用Spark SQL计算核心指标。
- 第四步，建立数据比较引擎。根据表和表之间核心指标的关系、表和表之间的规则进行比较验证。例如，A==B，A+B==C，B/A ＜ 0.95等逻辑判断。
4.5.3 数据管理系统的功能
数据管理系统的功能主要分为数据流管理、任务管理、数据管理三大功能。
数据流管理
数据流管理，也可以叫血缘分析。单从字面上来看，它属于一种数据关系的分析，用来解释数据之间相互影响的一种描述。
数据流管理，对于当前大数据背景下的数据治理具有十分重要的意义，它能让你快速了解数据组成结构，并制定有效的管理方式。
例如，有一天，我们发现大数据分析平台某个业务指标的数据没有产出，就要去查看到底哪里出了问题，是数据集市里的表、主题层的表还是基础层的表出了问题。而在更多的时候，数据集市的表会依赖多张表，那么这个排查问题的过程就会变得很麻烦，而且很浪费时间。
有一个简单的思路就是，通过业务场景，在数据管理系统中设计解析每一个计算过程的链路关系，自动绘制出图表，动态获取执行情况，并做出预警。对于日常的监控，可以将每一个元数据的引用情况做出明暗度显示，绘制出数据星云图。
数据血缘关系会首先通过指标对应的库表关系，找出它所属的表，再根据计算关系找到计算过程中与它有关联的表，最终把整个链路上的相关表展现出来。这样就清晰地展现出了它从数据源头开始，一层一层的链路关系，并且可以用颜色区分正常、延迟、未处理等各种状况，清楚地知道任务异常情况，并在任务延迟情况下触发报警机制，以短信方式提醒负责人排查问题，确保数据正常产出。
如图4-12所示，血缘分析可以清晰地帮助我们了解所维护的数据的使用与被使用情况，犹如资产一般，便于维护定位与统一管理。一个管理者如果掌握了数据资产的使用与被使用情况，就可以更加清晰地了解管理与维护的重点，并做出合理的风险预警，基于业务重点做一些资源的调整与再分配。
任务管理
任务管理会对每天的任务执行情况进行管理，展现每张表的任务完成时间、任务延时情况以及延时的原因等，一旦任务出现问题，可以快速联系到数据表的负责人。同时，能够方便查看每张表的依赖关系、完成时长的历史情况以及表的字段信息，让整个大数据分析平台变得清晰易懂，如图4-13所示。
为了对数据流程进行优化，减少任务延时情况，需要分负责人和表名称两个维度对数据的延时情况进行统计分析，可以查看每个负责人的延时次数、延时时间及占比情况，为了激励每个负责人减少延时次数，建议以排行榜的方式进行排名展现，如图4-15所示。
数据管理
数据管理功能会展现数据仓库表的信息，包括所属数据库、存储类型、负责人、产出状态、数据库地址、标签、备注、所属业务组等，并可进行查看和编辑操作。
点击表名、业务组可跳转到血缘关系页面，对应表所在的血缘图或该业务组的血缘图。数据管理功能的作用是可以通过表名、标签、产出状态、业务组等快速检索相关表，了解表信息，并对表进行相关操作，便于表信息的维护，数据管理功能页面如图4-16所示。