数据产品经理修炼手册——从零基础到大数据产品实践的读后感大全

　　《数据产品经理修炼手册——从零基础到大数据产品实践》是一本由梁旭鹏著作，电子工业出版社出版的平装图书，本书定价：79.00元，页数：252，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《数据产品经理修炼手册——从零基础到大数据产品实践》精选点评：

　　●强力推荐

　　●浅显，价格略贵

　　●一半是用不到的sql语句，另一半是已经知道的知识，不过人家作者说了适合零到三岁的产品看

　　●数据产品经理

　　●【2/21】适合数据产品产品入门、数据分析从业者转型的一本书。通过在有自建数据平台公司中的实践经验，基本讲清楚了数据产品日常会干那些事、要具备哪些知识能力（与普通产品&数据分析师做了对比），对于相关是技术层面（如数据的采集、处理、存储、调用）仅粗略的讲了框架，而在如何设计数据平台/中台、数据平台如何应用到实际业务……讲的更多一些。总的来说对于没入行可以提供比较清晰的全局意识、对于要准备入行的能提供更多参考信息。

　　●作为入门数据产品是一本非常实用的书，但是最好理论可以和实践结合，这样将对数据产品理解更深刻使用更顺

　　●前四章主要是介绍作为数据产品人员应该拥有的思维和具备的软硬实力。可以看出，数据产品是一个对人要求非常全面的岗位。在思维能力方面，要求拥有数据思维、用户思维、产品思维和工程思维；在技术水平方面，需要掌握数据分析和产品原型等工具。后四章介绍了常见的几种数据产品。总体来说讲了很多东西，但是基本上都是浅尝辄止，适合有技术背景的人阅读。好的书籍应该是在人的学习区，而这本书的很多内容，在舒适区和恐慌区之间来回。

　　●内容比较全面，适合对新人刚入门时看，对整个数据产品体系有个粗浅了解。原始数据采集、存储、应用等各个环节都有聊到，同时也有讲埋点、AB测、BI分析等工具。经验丰富的pm可能会觉得内容不够深入，不过个人觉得这本书的目标用户本来也不是大佬们。

　　●数据产品经理作为一个新兴的概念，我和作者的认知其实也不太一样。这本书主要论述了数据产品经理的一些基本技能，在应用方面主要还是涉及toC产品相关运营分析依赖的大数据分析平台建设。对于在医疗领域对接基本是toB产品与服务的我来说价值有限。其他同学一定先看看目录，看看是否和自己想要的契合。

　　●为数不多的写数据产品经理的书，很难得。看之前其实还是蛮期待的，想着通过看这本书之前能学到一些比较solid的方法论。但是看之后的确是有些失望了，没有太多的干货内容，还是文科性的百度知识比较多。唯一觉得有价值的是数据仓库的那一章，的确是讲了不少数据仓库相关的构造流程，人员配置，构造方法等知识。也冲着这个多给了一颗星。至于其他章节，很多是快速滑过去的，有些失望。

　　《数据产品经理修炼手册——从零基础到大数据产品实践》读后感(一)：支持

　　数据产品本是个对技能知识和应用都有更高要求的岗位，这本书从深度和广度上都给0-3年的产品经理做了很好的引导。在这本书中找到了自己想了解的作为数据产品应涉猎的技能，也有数据产品当前火热的几大行业应用，给了很好的方向，支持！期望数据产品行业能给产品人提供新的期待。很好～～～～～～～～～～～～

　　《数据产品经理修炼手册——从零基础到大数据产品实践》读后感(二)：太浅了，看得浪费时间

　　前面看了50页，完全不知道在讲啥！什么都讲，也太浅了！！ 一点营养都没有！！！完全不想再继续看了，真的写得超级浅！！！不知道是不是为了凑字数。

　　前面看了50页，完全不知道在讲啥！什么都讲，也太浅了！！ 一点营养都没有！！！完全不想再继续看了，真的写得超级浅！！！不知道是不是为了凑字数。

　　《数据产品经理修炼手册——从零基础到大数据产品实践》读后感(三)：摘抄

　　- 数据产品- 数据、数据模型、分析决策逻辑 - 提炼数据需求、找出问题本质、推动解决问题 - 掌握业务常用的思路和处理能力，能够在业务中发现痛点，并通过数据产品解决或者辅助解决问题 - 任务管理工具：tower - 数据产品经理的思维方式 - 归纳和演绎思维 - 用户思维、产品思维、工程思维 - SMART原则：specific 具体 measurable 可衡量 attainable 可达成 relevant相关性 time_bound 明确的截止日期 - 与程序员进行沟通：任务拆解法 - 需求评审会收尾利器：todo事项列表 优先级 - 工具：

　　《数据产品经理修炼手册——从零基础到大数据产品实践》读后感(四)：数据产品经理修炼手册

　　第1章 初识数据产品经理

　　数据产品可以分为三类：

　　（1）企业内部使用的数据产品。如自建BI数据分析平台和推荐系统等，这里之所以提到推荐系统，是因为它与用户画像、搜索排序类似的算法一样，本质上是根据用户数据和相应的数据模型建立的一套评分标签体制，也属于数据产品的范畴。

　　（2）企业针对公司推出的商业型数据产品。如Google Analytics、GrowingIO、神策数据和BDP商业数据平台等，它们主要以平台行为为其他公司提供商业化服务。

　　（3）每个用户均可使用的数据产品。如猫眼的实时票房和淘宝指数等，这类产品主要面向普通用户，而且大部分提供免费服务。

　　数据产品把数据、数据模型以及分析决策逻辑尽可能多的形成一个产品形态，以更直观智能的方式，发挥数据的价值，辅助用户更快地做出更合理的决策。

　　数据产品是建立在大数据场景下通过数据挖掘并且体现数据价值后的产品化，最后再融合进业务产品流程中做辅助业务和驱动业务发展。

　　数据、信息、知识

　　数据就是数值，是一种客观存在，是通过观察、实验和计算得出的结果，并随着社会的发展而不断扩大和变化。特别是在现在的移动互联网时代，数据不再是仅仅限于字面上的数字，图片和视频都是数据，我们开车或者骑行中的轨迹也是数据，甚至身体的健康状态信息等也都属于数据的范畴。

　　1948年，数学家香农在题为《通信的数学理论》的论文中指出：“信息是用来消除随机不定性的东西”。信息是被组织起来的数据，是为了特定的目的，对数据进行有关联的组织和处理，赋予数据以具体意义，从而可以用来回答5W2H中的Who（谁）、What（什么）、Where（哪里）、When（什么时候）的问题。

　　知识是通过数据和信息处理以后，被验证过的，而且是绝对正确的。可见，知识是数据和信息之上的，是基于信息之间的联系，总结出来的规律和方法论。知识具有系统性、规律性和可预测性，主要用于回答Why（为什么）和How（怎么做）的问题，而得到的知识能够使我们更加清晰地了解世界和生活，还能够不断改变我们周围的世界。这一切所有的基础就是数据。

数据、信息和知识的层次关系和重要性

　　第2章 数据产品经理基础知识 第3章 数据分析思维与实践

　　数据产品经理和数据分析师的区别

　　数据产品经理会把数据分析师的一部分日常工作转换为数据产品，例如用户留存分析展现、用户行为分析及用户画像等，还会实现一些偏向于设计展现数据的大数据分析平台工具等产品，把数据作为一种产品形态输出，更重数据，偏产品设计，需要能够输出给用户可用的数据产品工具。在思维方式上，数据产品经理注重的是用户思维、逻辑思维和产品思维。

　　数据分析师则主要通过理解业务，通过数据模型或者数据评估方案发现问题或者给出结论，并对产品和运营提出建议，利用数据得出影响产品策略的建议。数据分析师会把数据加工成可以利用的成果，交付数据结论或者报告，或者在大数据分析平台上以报表可视化的方式展现，输出给用户的是一个结论或者是对趋势的判定，业务方会直接使用数据分析师给的结论。在思维方式上，数据分析师更偏重于分析思维。

　　数据分析师和数据产品经理是相互协作的，数据分析师将一些常规化的分析内容、分析报告等固定化为一个模板，然后交付给数据产品经理，数据产品经理会根据用户需求，对模板进行重新梳理，并整理出产品原型和产品方案，交付给研发工程师实现一个可用的数据产品工具让更多的人使用，从而解放了数据分析师的一部分工作，让大家都变得更高效。

　　数据产品经理需要掌握的数据分析技能，仅仅是要求能够掌握常用的分析方法及技能，不必达到数据分析师的标准。数据分析的能力，不仅是数据产品经理要具备的技能，而且以后也将会成为任何一个职业必备的技能之一。

　　第4章 数据仓库理论与应用

　　了解大数据基础Hadoop

　　Hadoop是一个分布式系统基础架构，现在被广泛地应用于大数据平台的开发，对处理海量数据有着其他技术无可匹敌的优势。HDFS（Hadoop Distributed File System）、MapReduce与HBase被誉为分布式计算的三驾马车。Hadoop基本架构的底层是HDFS，上面运行的是MapReduce、Tez、Spark，再往上封装的是Pig和Hive，Hadoop的三大核心设计。

Hadoop体系架构

　　现在的Hadoop已经从上面提到的Hadoop三驾马车逐渐发展为60多个相关组件构成的庞大生态家族，其中在各大发行版中就包含30多个组件，包含了数据框架、数据存储和执行引擎等。

　　目前最流行的两个大数据处理框架是Hadoop 和Spark。

　　ark、Spark MLib、Spark GraphX和Spark Streaming组成了Spark 生态圈，其余部分组成了Hadoop生态圈组。这两个框架之间的关系并不是互斥的，它们之间既有合作、补充，同时又存在竞争。例如，Spark提供的实时内存计算，会比Hadoop中的MapReduce速度更快。但是，由于Hadoop更加广泛地应用于存储，Spark也会依赖HDFS存储数据。虽然Spark可以基于其他系统搭建实现，但也正是因为它与Hadoop之间的这种互相补充的关系，所以Spark和Hadoop经常搭配在一起使用。

Hadoop生态圈

　　除了Hadoop体系架构那些基础工具外，数据产品经理还需要对以下几个基础工具做一些了解。

　　（1）Spark。Spark是一个开源的集群计算环境，上文也讲了，Spark与Hadoop之间既相互补充，又相互竞争。Spark启用了内存分布数据集，在处理某些工作负载方面表现得更加优越，交互也会更加友好。

　　（2）Kafka。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理各大网站或者App中用户的动作流数据。用户行为数据是后续进行业务分析和优化的重要数据资产，这些数据通常以处理日志和日志聚合的方式解决。

　　Kafka集群上的消息是有时效性的，可以对发布上来的消息设置一个过期时间，不管有没有被消费，超过过期时间的消息都会被清空。例如，如果过期时间设置为一周，那么消息发布上来一周内，它们都是可以被消费的，如果过了过期时间，这条消息就会被丢弃以释放更多空间。

　　（3）Storm。Storm主要应用于分布式数据处理，包括实时分析、在线机器学习、信息流处理、连续性的计算、ETL等。Storm还可以应用于实时处理，被称为实时版的Hadoop，每秒可以处理百万级的消息，并且Storm可以保证每个消息都能够得到处理，具有运维简单、高度容错、无数据丢失、多语言的特点。

　　（4）HBase。HBase是一个构建于HDFS上的分布式、面向列的存储系统。以Key-Value对的方式存储数据并对存取操作做了优化，能够飞快地根据Key获取绑定的数据。例如，从几PB的数据中找身份证号只需要零点几秒。

　　（5）HUE。HUE 是Cloudera 的大数据Web可视化工具，主要用来简化用户和Hadoop集群的交互。可以在Web页面把数据从HDFS等系统导入Hive中，可以直接通过HUE以HiveQL的方式对数据查询展现。同时，还可以保存SQL语句，并查看和删除历史SQL语句，对于查询后的数据，可以选择表格、柱状图、折线图、饼状图、地图等多种可视化图形展现，操作十分简单，如果想继续分析，可以使用下载功能下载保存为Excel。

　　同时，任务的执行进度、执行状态、执行时间等执行情况，都会以Web可视化的方式展现给用户，同时还能够查看错误日志以及系统日志等。如果小规模的公司没有自己的大数据管理平台，那么它们还可以通过HUE查看元数据信息、任务调度执行情况等，方便对数据资产及调度进行管理查找等操作。

　　（6）Oozie。Oozie 是一个工作流调度系统，统一管理工作流的调度顺序、安排任务的执行时间等，用来管理Hadoop的任务。Oozie集成了Hadoop的MapReduce、Pig、Hive等协议以及Java、Shell脚本等任务，底层仍然是一个MapReduce程序。

　　（7）ZooKeeper。ZooKeeper是Hadoop和HBase的重要组件，是一个分布式开放的应用程序协调服务，主要为应用提供配置维护、域名服务、分布式同步、组服务等一致性服务。

　　（8）YARN。Hadoop生态有很多工具，为了保证这些工具有序地运行在同一个集群上，需要有一个调度系统进行协调指挥，YARN就是基于此背景诞生的资源统一管理平台。 除了上面介绍的基础工具之外，以下是一些常用工具。

　　（1）Elasticsearch。Elasticsearch是基于Lucene的搜索服务器，提供了一个基于多用户的分布式全文搜索引擎，基于RESTful Web接口。Elasticsearch作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。Elasticsearch主要应用于云计算中，能够实现实时搜索，具有稳定、可靠、快速、安装和使用方便的特点。

　　（2）Memcached。Memcached是一个开源的、高性能、分布式内存对象缓存系统，基于内存的Key-Value存储，解决了大数据量缓存的问题，主要应用于减轻数据库负载。它通过在内存中缓存数据查询结果，减少数据库访问次数来提高动态网址应用的速度。同时，因为它足够简洁而强大，便于快速开发，所以得到了广泛的应用。

　　（3）Redis。Redis是开源的可以基于内存同时也可以持久化的日志型Key-Value数据库，它使用ANSI C语言编写，支持网络，并提供多种语言的API。与Memcached类似，为了保证查询速度和效率，数据都是缓存在内存中的，区别的是Redis多了一步持久性操作，会定期把更新的数据写入磁盘或者文件中，并且在此基础上实现主从模式的数据同步。正是因为Redis的这一点，它可以很好地弥补Memcached这类单纯基于Key-Value存储的不足，在一些应用场景中，可以配合关系型数据库一起使用，同时对关系型数据库起到了很好的补充作用。

　　根据大数据平台架构中流入和流出的过程，可以把其分为三层——原始数据层、数据仓库、数据应用层。原始数据层，也叫ODS（Operational Data Store）层，一般由基础日志数据、业务线上库和其他来源数据获得。数据仓库的数据来自对ODS层的数据经过ETL（抽取Extra，转化Transfer，装载Load）处理。ETL是大数据平台的流水线，也可以认为是平台的血液，它维系着平台中数据的新陈代谢，而大数据平台日常的管理和维护工作的大部分精力就是保持ETL的正常与稳定。

大数据平台架构

　　数据仓库的主要功能是以ODS层数据为基础，通过逻辑加工产出数据仓库主题表。数据仓库又细分为基础层、主题层和数据集市。

　　ODS层的特性较着重于查询，变动性大。数据仓库通常为企业层级，用来解决及时性、临时性的问题，数据集市则较偏向解决特定业务的问题，部分采用维度模型。

　　数据应用层主要用于处理消费数据仓库的数据。

　　ODS层

　　ODS全称为Operational Data Store，翻译成中文为操作型数据存储，是面向主题的、集成的、可变的、反映当前数据值的、详细的数据的集合，用来满足企业综合的、集成的和操作型的处理需求。

　　对于ODS层而言，客户端用户操作日志是一个主要的数据来源，它是分析App和产品优化的基础；另一部分来源于业务的数据库，例如订单的交易情况。ODS层的表通常包括两类，一类用于存储当前需要加载的数据，另一类用于存储处理完后的历史数据。历史数据一般保存3～6个月后需要清除，以节省空间。

　　ODS层是当前的、不断变化的数据，而数据仓库保留的是历史的、不再变化的数据，所以一般来说会落后ODS层一天或一天以上的数据。ODS层按分钟级别捕捉生产系统的数据变化，然后可以每天将归档后的数据加载到数据仓库中，归档的标记为这条记录是否已完成。

　　数据仓库

　　数据仓库（Data Warehouse，DW）是为了方便企业快速做各种业务决策提供数据支撑而构建的集成化数据环境。

　　数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何数据，数据来源于外部，并且开放给外部应用。

　　数据仓库主要有以下三个特点：

　　（1）数据仓库是面向主题的，它会按照一定的主题进行组织。（2）数据仓库是集成的，数据仓库中的数据可能来源于多个数据源，数据仓库会将需要的数据从中抽取出来，然后进一步转化、清洗，再集成到数据仓库中。（3）数据仓库是不可更新的，数据仓库主要是为业务提供分析决策的数据，因此，对数据的主要操作都是查询。

　　数据仓库主要分为基础层、主题层、数据集市层。

　　基础层的主要作用是对ODS层的数据进行轻度汇总，产出轻度汇总明细、维度表、码表、事实集等一些基础数据。

　　主题层为数据的高度聚合层，按照一定的维度和业务逻辑，对一类数据进行聚合，主要生成画像表和主题表。主题层的数据来源是基础层和ODS层。例如，在共享单车的数据仓库设计中，通常根据业务将主题层分为用户主题、车辆主题、支付主题、行程主题等，为了平衡业务前台的快速变化与数据仓库稳定性的需求，在设计主题层的时候，通常要与业务中台保持一致。 数据集市（Data Mart）也叫数据市场，主要功能是将主题层和基础层的数据按各业务需求进行聚合，生成宽表和Cube，并直接推送给数据分析和业务部门使用，例如直接推送表数据至MySQL数据库。数据集市由很多非常宽的表组成，比如GMV（网站成交金额）的表，除了包含订单和金额等必需的字段，还包含可能使用的SKU（库存量单位）产品信息、用户基本信息等，是数据仓库的核心组成部分。

　　数据集市是数据仓库的一部分，主要面向各业务部门使用，并且仅面向某个特定的主题。为了解决灵活性和性能之间的矛盾，数据集市可以被理解为一种小型的主题或业务级别的数据仓库。数据集市中数据的结构一般是星型结构或者雪花结构，而星型结构通常由事实表和维度表构成。

　　（1）事实表。事实表用于记录数据集市表中的详细数据。在共享单车企业中，用于记录用户骑行的数据是典型的最密集的数据；在银行中，与账目核对和自动柜员机有关的数据是典型的最密集的数据；对于零售业而言，销售和库存数据是最密集的数据。事实表会首先把多种类型的数据连接在一起。例如，一个订单、一次骑行等都会以主键的方式存储在表中，然后与维度表的主键关联。因此，事实表是高度索引化的，表中经常会出现几十条索引，甚至有时事实表的每列都建了索引，这样在查询时速度会进一步提升。

　　（2）维度表。维度表是围绕事实表建立的。维度表里的数据主要用来存储维度数据，主要是一些非密集型数据，包括客户端的版本、操作系统、车型等。

　　大数据的分析应用主要分为三种形式：描述性分析应用、预测性分析应用、指导性分析应用。

　　数据埋点

　　埋点方式

　　前端的埋点方式主要分为代码埋点、可视化埋点、无埋点三种。

　　代码埋点主要由App研发工程师手工在程序中写代码实现，通过触发某个动作后程序自动发送数据。优点：具有很强的灵活性，可以控制发送的时机和发送方式等。缺点：人力成本较高，需要研发工程师手工开发程序，有时候还要依赖App发版来生效。

　　可视化埋点以前端可视化的方式记录前端设置页面元素与对其操作的关系，然后以后端截屏的方式统计数据。优点：简单、方便，能够快速地埋点。缺点：比较受限，上报的行为信息有限。

　　无埋点绑定页面的各个控件，当事件触发时就会调用相关的接口上报数据。优点：不需要埋点，方便、快捷、省事。缺点：传输数据量比较大，需要消耗一定的数据存储资源。

　　服务器后端埋点，它能够收集不在App内发生的行为，只要有网络请求就可以记录下来，它能够实时收集，不存在延时上报的问题，但是没有网络就很难收集到数据，这也是服务器后端埋点的一个弊端。

　　因此，很多公司都会结合客户端前端埋点和服务器后端埋点两种方式一起埋点，服务器后端数据实时性强、很准确，用户需要请求服务器的关键业务量最好均使用服务器后端埋点，如在线播放、游戏安装等。例如，要根据埋点数据统计中奖用户信息，显然服务器后端数据更合理，客户端前端数据可能会漏掉部分中奖用户，导致用户投诉；客户端前端数据很全，记录了用户绝大多数的操作行为，其他非关键业务量或者不需要请求服务器的行为可以使用客户端前端埋点。服务器后端埋点和客户端前端埋点各有优劣，应该两种数据都同时存在，可以相互印证，当一方数据发生重大问题时可以通过另一方发现。同时，数据也能互补，如一方数据采集突然有问题了，可以用另一方数据替代。但是，由于前端埋点和后端埋点的埋点方式不同，统计的数据难免有差异，不要纠结于两者的数据为什么对不上，而更应该结合两者互相验证。

　　埋点事件分为点击事件、曝光事件和页面停留时长三类。

　　指标字典

　　指标字典，是业务数据标准化的基础，目的是对指标进行统一管理，方便共享，达成对业务指标的共识，并且统一修改和维护。指标字典可以更新在Excel或者Wiki中。如果有足够多的资源，那么开发指标管理模块可以放在数据管理系统中，再配合血缘关系，就更方便追踪数据流转了。

　　指标、量度和维度的相关概念。

　　1.指标

　　定义：衡量目标的方法。

　　构成要素：维度+汇总方式+量度。

　　（1）维度回答从哪些角度去衡量的问题。

　　（2）汇总方式回答用哪些方法去衡量的问题。

　　（3）量度回答目标是什么的问题。

　　2.量度

　　定义：量度是对一个物理量的测定，通常以数字+计量单位表示。比如，金额、份额、次数、率。

　　3.维度

　　定义：维度是看待事物的视角与方向。

　　指标一般分为基础指标、普通指标和计算指标三类。

　　1.基础指标

　　例如，“团购交易额”作为一个基于单纯实体的属性的简单计算，它没有更上游的指标，即它的父指标是它自身。我们称这样的指标为基础指标。

　　2.普通指标

　　所谓普通指标，即在单一父指标的基础上通过一些维度上的取值限定可以定义的指标。

　　例如，对于团购中PC端首次购买用户数，限制条件为首次购买用户中下单平台=PC。

　　3.计算指标

　　可以在若干个注册指标之上通过四则运算、排序、累计或汇总定义出的指标称为计算指标。

建立指标字典的要素建立指标字典的要素

　　指标字典通常包含指标维度和指标量度两个部分。

指标字典的维度指标字典的量度指标字典的量度

　　一个好的指标字典分析框架就像剥洋葱一样，先从单维度、粗维度分析，再细拆维度，自外而内地看问题，透过现象发现事物本质。

数据质量中心的架构图

　　大数据管理系统项目需要做的事情主要分为以下几步：

　　第一步，建立数据依赖引擎，实现依赖图谱。依赖图谱用于构建数据仓库表之间的分层级依赖关系，然后存入MySQL表并能支持可视化展现。

　　第二步，计算数据准备情况。各个表、各个分区的数据准备就绪时间按天、小时级进行汇总。根据Hive 仓库的Meta信息可以获取Hive表各个分区的创建时间，根据创建时间确定数据的实效性，用来分析展现每天、每小时的状态和瓶颈。如果需要对MySQL进行验证则通过SQL语句查询的方式获取对应时间在MySQL中是否存在。

　　第三步，建立数据计算引擎。根据定义的小时级指标、天级别指标规则，结合数据表各个分区的准备就绪时间，调用Spark SQL计算核心指标。

　　第四步，建立数据比较引擎。根据表和表之间核心指标的关系、表和表之间的规则进行比较验证。例如，A==B，A+B==C，B/A ＜ 0.95等逻辑判断。

　　数据管理系统的功能主要分为数据流管理、任务管理、数据管理三大功能。

　　数据流管理，也可以叫血缘分析。单从字面上来看，它属于一种数据关系的分析，用来解释数据之间相互影响的一种描述。数据流管理，对于当前大数据背景下的数据治理具有十分重要的意义，它能让你快速了解数据组成结构，并制定有效的管理方式。

　　例如，有一天，我们发现大数据分析平台某个业务指标的数据没有产出，就要去查看到底哪里出了问题，是数据集市里的表、主题层的表还是基础层的表出了问题。而在更多的时候，数据集市的表会依赖多张表，那么这个排查问题的过程就会变得很麻烦，而且很浪费时间。有一个简单的思路就是，通过业务场景，在数据管理系统中设计解析每一个计算过程的链路关系，自动绘制出图表，动态获取执行情况，并做出预警。对于日常的监控，可以将每一个元数据的引用情况做出明暗度显示，绘制出数据星云图。

　　数据血缘关系会首先通过指标对应的库表关系，找出它所属的表，再根据计算关系找到计算过程中与它有关联的表，最终把整个链路上的相关表展现出来。这样就清晰地展现出了它从数据源头开始，一层一层的链路关系，并且可以用颜色区分正常、延迟、未处理等各种状况，清楚地知道任务异常情况，并在任务延迟情况下触发报警机制，以短信方式提醒负责人排查问题，确保数据正常产出。

血缘管理示例

　　任务管理会对每天的任务执行情况进行管理，展现每张表的任务完成时间、任务延时情况以及延时的原因等，一旦任务出现问题，可以快速联系到数据表的负责人。同时，能够方便查看每张表的依赖关系、完成时长的历史情况以及表的字段信息，让整个大数据分析平台变得清晰易懂。

数据任务管理

　　数据仓库中每张表的完成时长每天都是不一样的，因此在数据关系系统中，有必要把表的每天完成时长记录下来，然后展现在系统中，方便查看近一段时间内的完成时长趋势，分析延时规律和问题。

　　为了对数据流程进行优化，减少任务延时情况，需要分负责人和表名称两个维度对数据的延时情况进行统计分析，可以查看每个负责人的延时次数、延时时间及占比情况，为了激励每个负责人减少延时次数，建议以排行榜的方式进行排名展现。

　　数据管理功能会展现数据仓库表的信息，包括所属数据库、存储类型、负责人、产出状态、数据库地址、标签、备注、所属业务组等，并可进行查看和编辑操作。点击表名、业务组可跳转到血缘关系页面，对应表所在的血缘图或该业务组的血缘图。数据管理功能的作用是可以通过表名、标签、产出状态、业务组等快速检索相关表，了解表信息，并对表进行相关操作，便于表信息的维护。

　　大数据分析平台应用实战

　　按照大数据分析平台的版本迭代路线，讲一下大数据分析平台建设的四个阶段：可拓展的报表分析平台（V1.0版本）、自助式分析平台（V2.0版本）、智能化分析平台（V3.0版本）、业务场景分析平台（V4.0版本）。

可扩展的报表架构

　　第6章 用户行为分析平台实践

　　用户行为分析平台主要有事件分析、留存分析、转化分析、用户分群、用户行为细查、用户行为路径分析等功能，通过精准数据分析可以提升企业营销、产品、运营的转化率，使企业经营更科学、更智能。

　　事件

　　事件是追踪或记录的用户行为或业务过程。事件是通过埋点记录，通过SDK（Software Development Kit，软件开发工具包）上传的用户行为或者业务过程记录。例如，一个视频内容类产品可能包含以下事件：①播放视频。②播放暂停。③继续播放。④分享。⑤评论。

　　一个事件内可能包含数个事件属性（Param），记录详细描述事件的各种维度信息。例如，“播放视频”事件可能包含以下事件属性：①enter_from（视频的展现来源）。②is_auto_play（是否自动播放）。③play-form（视频播放的形态，主要区分详情页、列表页和全屏）。

　　公共属性

　　我们将所有事件都具有的一些维度抽象出来称为“公共属性”。例如，用户年龄、用户性别、操作系统、App版本等。

　　根据公共属性改变频率，我们又将它们分为用户属性和设备属性。

　　（1）用户属性（User Profile）。用户属性指描述用户自身状态的属性，这些属性一般不会或极少发生变化。例如，年龄、性别等。数据仓库将这些属性存在用户属性表中，该表仅储存各用户属性最新的状态。

　　（2）设备属性（Device Profile）。设备属性从广义上来说指除了用户属性之外的一切公共属性。几乎每个事件都有这些属性，且经常随时间发生变化。例如，操作系统、软件版本、软件渠道等。数据仓库将这些属性随各个事件存在事件表中，以记录设备属性变化前后的所有状态。

　　第7章 AB实验平台实践

AB实验平台设计重点

　　第8章 大数据产品在各个领域中的应用