你了解你的数据吗（开篇）
转自http://www.mdjs.info/2018/03/05/data-warehouse/concept-of-dw/
0x00 前言
你了解你的数据吗？
前几天突然来了点灵感，想梳理一下自己对数据的理解，因此便有了这篇博客或者说这系列博客来聊聊数据。
数据从业者有很多，比如说数据开发工程师、数据仓库工程师、数据分析师、数据挖掘工程师、数据产品经理等等，不同岗位的童鞋对数据的理解有很大的不一样，而且侧重点也不同。那么，是否有一些数据相关的基础知识是所有数据从业者都值得了解的？不同的岗位对数据的理解又有多大的不同？数据开发工程师是否有必要去了解数据分析师是如何看待数据的？
本系列博客会尝试去学习、挖掘和总结这些内容，在数据的海洋中一起装x一起飞。
0x01 数据？数据！
开篇先上几个问题：
- 你知道自己的系统数据接入量是多少吗？
- 你知道数据的分布情况吗？
- 你知道自己常用的数据有什么隐藏的坑吗？
如果你对前面说的问题有不太了解的，那么我们就可以在以后的内容中一起愉快地交流和探讨。如果前面说的问题你的回答都是 “Yes”，那么我还是会尝试用新的问题来留住你。比如说：
- 既然你知道系统的数据接入量，那你知道每天的数据量波动吗？波动量在多大范围内是正常情况？
- 你知道的数据分布情况是什么样子的？除了性别、年龄和城市的分布，还有什么分布？
- 在偌大的数据仓库中，哪些数据被使用最多，哪些数据又无人问津，这些你了解吗？
- 在最常用的那批数据中，有哪些核心的维度？有相同维度的两个表之间的数据口径是否也一样？
假设你对上面的问题有稍许困惑或者感兴趣，我们正式开始对数据的认知之旅。
0x02 概览
现在，我们粗略地将数据从业者分为数据集群运维、数据开发工程师、数据仓库工程师、数据分析师、数据挖掘工程师和数据产品经理，这一小节先起一个引子来大致说明不同岗位对数据的了解是不同的，后文会详细地说明细节内容。
首先要说明的是，在工作中数据相关的职位都是有很多重合的，很难一刀切区分不同岗位的职责，比如说数据开发工程师本身就是一个很大的概念，他可以做数据接入、数据清洗、数据仓库开发、数据挖掘算法开发等等，再比如说数据分析师，很多数据分析师既要做数据分析，又要做一些提数的需求，有时候还要自己做各种处理。
公司的数据团队越大，相应的岗位职责就会越细分，反之亦然。在这里我们姑且用数据开发工程师和数据仓库工程师做对比来说明不同职责的同学对数据理解的侧重点有什么不同。我们假设数据开发工程师侧重于数据的接入、存储和基本的数据处理，数据仓库工程师侧重于数据模型的设计和开发（比如维度建模）。
数据开发工程师对数据最基本的了解是需要知道数据的接入状态，比如说每天总共接入多少数据，整体数据量是多大，接入的业务有多少，每个业务的接入量多大，多大波动范围是正常？然后还要对数据的存储周期有一个把握，比如说有多少表的存储周期是30天，有多少是90天？集群每日新增的存储量是多大，多久后集群存储会撑爆？
数据仓库工程师对上面的内容也要有一定的感知力，但是会有所区别，比如说，数据仓库工程师会更关注自己仓库建模中用到业务的数据状态。然后还需要知道终点业务的数据分布，比如说用户表中的年龄分布、性别分布、地域分布等。除此之外还应关注数据口径问题，比如说有很多份用户资料表，每张表的性别取值是否都是：男、女、未知，还是说会有用数值类型：1男、2女、0未知。
然后数据开发工程师对数据异常的侧重点可能会在今天的数据是否延迟落地，总量是否波动很大，数据可用率是否正常。
数据仓库工程师对数据异常的侧重点则可能是，今天落地的数据中性别为 0 的数据量是否激增（这可能会造成数据倾斜），某一个关键维度取值是否都为空。
上面的例子可能都会在一个数据质量监控系统中一起解决，但是我们在这里不讨论系统的设计，而是先有整体的意识和思路。
0x03 关于内容
那么，后续博客的内容会是什么样子的呢？目前来看，我认为会有两个角度：
- 抛开岗位的区分度，从基本到高级来阐释对数据的了解。比如说数据分布，最基本的程度只需要知道每天的接入量；深一点地话需要了解到其中重点维度的分布，比如说男女各多少；再深一点可能要需要知道重点维度的数据值分布，比如说年龄分布，怎样来合理划分年龄段，不同年龄段的比例。
- 每个岗位会关注的一些侧重点。这点笔者认为不太好区分，因为很多岗位重合度比较高，但是笔者会尝试去总结，同时希望大家一起来探讨这个问题。
0xFF 总结
本篇主要是抛出一些问题，后续会逐步展开地细说数据从业者对数据理解。其实最开始我想用“数据敏感度”、“数据感知力”这类标题，但是感觉这种概念比较难定义，因此用了比较口语化的标题。
笔者认为，在数据从业者的职业生涯中，不应只有编程、算法和系统，还应有一套数据相关的方法论，这套方法论会来解决某一领域的问题，即使你们的系统从Hadoop换到了Spark，数据模型从基本的策略匹配换到了深度学习，这些方法论也依旧会伴你整个职业生涯。因此这系列博客会尝试去学习、挖掘和总结一套这样的方法论，与君共勉。
你了解你的数据吗（练气篇）
原文链接： www.mdjs.info
0x00 前言
数据一道，可深可浅，可大可小。同为数据人，新手和老鸟亦有很大差别。本篇是了解数据的入门篇，包含两部门内容：
- 数据接入，你的掌控力如何？主要聊一聊数据接入人员对自己接入数据的了解的程度。
- 数据的坑，你总结了多少规律？在数据接入和基本的数据处理中，会遇到很多数据异常，这些异常你是否已经总结出了规律并纳入到了自己的知识体系。
0x01 数据接入量，你知道多少？
如果你只是闷着头，来一个需求就接一个，而对于自己接入的数据一无所知，那就值得尽早做好打算了，因为不管是面试、汇报工作、亦或是老大们的好奇心，他们可能随时会向你发出这样的诘难：咱们集群总共多大的存储啊？现在有多大的数据量啊？总共接了多少个业务啊？日增量是多少啊，有多少条数据啊？按照这样的速度，集群还能撑多久？
面对上面的问题，你是否懵逼？如果有点懵，可以看一下下面的图，这是笔者认为需要了解的基本的数据内容。
了解数据接入的情况，应该算是最基本的要求，它意味着我们对自己负责的事情有了最基本的掌控力。对不同的人来讲，区别仅在于掌控的程度不同而已。
0x02 数据的坑，你总结了多少规律？
数据的坑无处不在，不管是接入、清洗亦或是模型计算，都会有遇到坑的地方。对于这些坑，你是否已经总结出了应对的套路？这个话题范围可能有点大，我们暂时将其缩小至数据的接入和基本的数据清洗过程。
现阶段，我将数据的坑，分为三部分：一为数据缺失，分为丢数据和字段缺失。二为业务层面的数据异常，比如数据中出现了不符合业务逻辑的取值。三为工程层面的数据异常，主要侧重数据ETL会遇到的异常。详细的一点的可以看下图。
注意，上面提到的都是数据异常，但是并没有说明数据异常的原因，而且也没有引入数据处理中工程上的坑。因为这两点和数据本身的理解上不是强耦合的，再加上不同数据处理流的特性会增加总结的难度，因此暂不讨论。
0xFF 总结
本篇是了解数据的一个基础篇，主要聊一聊数据接入和数据的坑这两个主题，没有讨论过多细化的内容。只为抛砖引玉，梳理大致的思路。
你了解你的数据吗（筑基篇）：核心维度分布和数据口径
发表于 2018-01-17
| 分类于 数据仓库
0x00 前言
刚入行做数据开发的时候经常听企业导师讲，你要有数据的意识，不能只知道闷着头来一个需求接一个，要从业务的角度来理解数据，这样你的职业线才能更长。
本篇不会分享和业务强相关的数据 Sense，但是会引入一些各种业务都会涉及的最基本内容：
- 数据核心维度分布：核心业务维度分布，主要是指像年龄、地域、性别之类的维度分布。
- 数据口径：数据口径可以理解为同名字段在不同表中的取值范围。
0x01 数据核心维度分布
核心维度分布主要是指数据中那些比较重要的列的内容分布，比如说用户最基本的年龄、性别和城市信息，这是最常用的数据分布，再引申一点的话会涉及到一些业务内容，比如说各省份的人的订单情况、不同时间段男女活跃信息对比，等等。如果有用户画像表的话还应包括各种画像中的维度分布。
因此，我们来做一个大概的划分的话，那就是三部分内容：1.基础资料；2.业务行为；3.用户画像。这三部分能帮助我们来理解用户是什么样子的？更好的懂业务，能促进更深入地理解数据。
上图是我画的一个大致的图，具体的内容应该是自己根据业务来详细的划分和填充。这些数据内容，你了解吗？不了解的话，就赶快整理一下吧。
0x02 数据口径
关于数据口径，很难给它一个准确权威的定义，我们不妨举几个例子来说明：
- 假设性别字段在表A中的取值是0、1、2（未知、男、女），在表B中取值是0、1、2（男、女、未知），这可能是从不同业务方接入的数据，现在需要将两份数据合并，来算整体的男女比例，如果你不知道两个表的数据口径，会出现什么样的结果？
- 假设你有很多数据都有ip这一个字段，ip为空的时候默认值是0，如果新接入一份数据，它的ip为空的默认值是null或者是-1，你之前的程序能很好地处理完成吗？
- 然后数据粒度的问题，同样的年龄字段，在表A中是具体的年龄数值，在表B中是0-20、20-30这样的数值，你直接使用会是什么情况？
上面就是我想表达的关于数据口径的一些例子，下面整理了一份大致的思维导图可供参考。
关于数据口径的问题，如何避免和解决这些问题可能就是一行代码或者是提前约定好规则就能搞定的，但是我们要先有这种意识，有了这样的意识，我们在接入和处理数据的时候就能提前预知问题或者出现问题了能快速定位和解决。
0xFF 总结
本篇的内容是希望数据小伙伴能从相对贴近数据或者说是贴近业务的层面上来理解数据。
数据的核心维度分布能让你对自己的数据有更全局观地把控，数据口径的问题能让你从更微观地角度来理解数据，以便更好地去处理数据。
你了解你的数据吗（结丹篇）：数据质量监控
发表于 2018-01-21
| 分类于 数据仓库
0x00 前言
结丹篇是《你了解你的数据吗》第四篇，本篇主要聊的内容主要和数据质量监控有关，之前在《数据质量监控》专门分享过相关内容，那篇文章主要从一个宏观的整体来看待质量监控，内容包括架构、设计和实现多个方面，但是对于数据质量监控本身的内容并没有一个比较体系化的梳理，本篇就来做这件事。
0x01 数据质量监控
我们将要分享的数据质量监控，不是单指数据异常，而是对数据各个角度的描述。
同比和环比
为了后面更好描述我们的想法，这里需要先引入两个概念：
同比：“同比 ”是同期之比的意思，一般指本年某月的累计指标与上年相同月份的累计指标之间的对比。
环比：是报告期（例如某月（年）对应上月（年），上月（年）对应前月（年）的逐期之比。以一期为一环,取环环相比的形像比喻。
在我们实际的数据质量监控中用到的同比和环比会是这样子的：
- 同比：本月1号某业务接入的总数据量和上个月1号某业务接入总数据量的。
- 环比：本月2号某业务数据接入量和本月1号某业务数据接入量之比。
监控内容
在数据质量监控中，我们将要监控的内容分为三个层次：
- 集群整体状况：这在练气篇中也有所提及，比如集群总容量、接入业务量等。
- 业务层面：对单个业务进行监控，具体来讲可能是对一张表来监控，比如说会监控它的数据量趋势、某日是否掉0、数据落地延迟、数据同比和环比等。
- 维度层面：这里想表达的内容是对核心业务的核心维度做监控，比如说用户的网页点击行为表，我们会对表中的ip字段进行监控，每天有多少为空；再或者对用户资料表进行监控，监控是否会有重复数据。
做一个大致梳理的话会是下面这张图：
0xFF 总结
数据质量监控的内容当然不会只有这么少，比如说像hdfs、es、mysql这些不同的存储引擎会有不同的特性，特定业务场景也会对数据质量有不同的要求，这些我们都不在做展开，在这里只是做一个抛砖引玉的介绍，期待大家一起来完善。
最后再聊一下为什么在《你了解你的数据吗》系列中混入了数据质量监控的内容。其实笔者理解，所谓数据质量监控，宽泛地讲应该是数据监控，数据监控的目的在于让人或者系统来更好地理解数据和管理数据，我们以这样一种体系化地方式来组织和呈现数据的内容其实是一种知识体系的汇总，其目的都是让人更好地去了解你的数据。
你了解你的数据吗（元婴篇）：血缘分析
发表于 2018-01-28
| 分类于 数据仓库
0x00 前言
本篇是《你了解你的数据吗》的第五篇，在前面的几篇文章中，我们聊到了数据接入量、数据的坑、数据核心维度分布、数据口径和数据质量监控。本篇将引入一个新的概念：数据血缘分析 ，或者叫血统分析。
0x01 血缘分析
那么什么是数据血缘分析呢？在这里我们不给出它的严谨的定义，仅从感觉上来解释一下这个东西。
数据血缘，我们可以大致理解为是一个表的生成过程。它依赖了哪些表，怎么生成的。同时加上它依赖的表又是怎么生成的。
觉个栗子
下面举个栗子来解释一下。
现在假设你是一只数据开发工程师，为了满足一次业务需求，，然后为了生成这张表，可能是处于程序逻辑清晰或者性能优化的考虑，你会使用很多份数据表，也会通过 MR、Spark 或者 Hive 来生产很多中间表。
如下图，是你将花费时间来实现的整个数据流。
- 其中 Table X 是最终给到业务侧的表。
- 蓝色的 Table A-E，是原始数据。
- 黄色的 Table F-I 是你计算出来的中间表。这些表都是你自己写程序要处理的表。
- 然后你为了懒省事，嗯，应该说本着不重复开发的原则，你还要用到同事小伙伴处理的表，Table J 就是别人处理过的结果表。
过了一段时间后，业务侧的感觉你提供的数据中有个字段总是不太对劲，其实就是怀疑你的数据出问题！需要你来追踪一下这个字段的来源。
首先你从 Table X 中找到了异常的字段，然后定位到了它来源于 Table I，再从 Table I 定位到了它来源于 Table G， 再从 Table G 追溯到了 Table D，最终发现是某几天的来源数据有异常。
或者说，你从 Table X 定位到了异常的字段原来来自于其它小伙伴处理的表 Table J，然后继续向前回溯，找到了这张表在处理过程中的某一个步出现了问题。
上面的过程是数据血缘分析的过程。
0x02 数据血缘分析有什么用？？？
咋一看，其实感觉数据血缘分析并没有什么用，其实就我个人感觉来看，其实的确没什么用，特别是在你的业务规模比较小并且数据合作不频繁的情况下，基本不需要数据血缘分析。但是当遇到了下面一些场景的时候，数据血缘绝对能帮你提高很高的效率。
- 问题定位。上面的例子，假设你用到了别人的数据，数据血缘分析能快速帮你定位到问题。
- 理解数据。如果你想用其它的数据源，首先要能理解它，不然数据口径能给你带来很大的麻烦。
- 修改某份数据的时候能评估影响的范围大小。比如说现在你的小伙伴要调整自己开发的 Table J，这时候如果他不知道有谁在依赖这张表，冒然修改的话会带来毁灭性的伤害，但是有数据血缘分析的时候，至少能知道谁在使用这份数据。
其实总的说来，数据血缘能帮你更好地理解自己的数据！
0x03 关于实现
实现的话不打算在这里多聊，因为数据血缘一般是和元数据管理紧紧绑定起来的，在设计元数据管理系统的时候应该要考虑到数据血缘的内容。关于元数据系统的设计可以参考这篇博客《别人家的元数据系统是怎么设计的》。
这里随便提一句，数据血缘的管理可以考虑使用图数据来实现，用图数据的好处是更容易展现表之间的关系。比如说下面两个需求点，用关系型数据库写 Sql 的话会很麻烦，但是用图数据库的话逻辑就十分简单。
- 找到一张表依赖的所有的表和生成路径。
- 找到依赖于某张表的所有表，和它们的生成路径。
补充： 有朋友会问，数据的关系从哪来？这个其实途径很多，最简单的方式可以从所有的 Hive Sql 中解析出来关系对，也可以从其它的代码或者调度系统中解析。具体实现可以根据业务场景来实现。
0xFF 总结
居士个人理解，数据血缘关系是理解数据的一个十分重要的点，它能让你快速清晰地理解你所关注的数据的生成路径。
然后关于本文，闲扯的比较多，而且不是特别严谨。居士希望能帮助没怎么听过数据血缘的童鞋熟悉一下这个概念，至于深入的挖掘点，可以再多交流。
数据仓库概念总结
发表于 2018-03-05
| 分类于 数据仓库
0x00 前言
整理一些数据仓库中的常用概念。大部分概念不是照搬书上的准确定义，会加入很多自己的理解。
0x01 概念
数据仓库（Data Warehouse）
数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。
个人理解，数据仓库不单单是一个概念，其实算是对数据管理和使用的一种方法论，它包括了如何合理地收集数据、如何规范的管理数据、如何优雅地使用数据，以及任务调度、数据血统分析等一系列内容。 在大数据时代这些概念依旧没有过时，相反，它更加重要。
利用数据仓库的方式存放的资料，具有一旦存入，便不会随时间发生变动的特性，此外，存入的资料必定包含时间属性，通常一个数据仓库中会含有大量的历史性资料，并且它可利用特定的分析方式，从其中发掘出特定的资讯。
联机分析处理（OLAP, Online Analytical Process）
OLAP（Online Analytical Process），联机分析处理，以多维度的方式分析数据，而且能够弹性地提供 上卷（Roll-up）、下钻（Drill-down） 和透视分析（Pivot）等操作，它是呈现集成性决策信息的方法，多用于决策支持系统、商务智能或数据仓库。其主要的功能在于方便大规模数据分析及统计计算，可对决策提供参考和支持。与之相区别的是联机交易处理（OLTP），联机交易处理，更侧重于基本的、日常的事务处理，包括数据的增删改查。
OLAP需要以大量历史数据为基础，再配合上时间点的差异，对多维度及汇整型的信息进行复杂的分析。
OLAP的概念，在实际应用中存在广义和狭义两种不同的理解方式。广义上的理解与字面上的意思相同，泛指一切不会对数据进行更新的分析处理。但更多的情况下OLAP被理解为其狭义上的含义，即与多维分析相关，基于立方体（Cube）计算而进行的分析。
商务智能（BI, Business Intelligence）
BI（Business Intelligence），即商务智能，指用现代数据仓库技术、在线分析技术、数据挖掘和数据展现技术进行数据分析以实现商业价值。
大致上来讲，BI就是利用各种技术来辅助于商业决策，它需要以数据仓库的数据为基础，通过Olap系统来做分析，必要时还需要一些数据挖掘的方法来挖掘更深层次的价值。
管理元数据的系统。网上没找到定义，个人对它的理解如下：
一个管理元数据信息的系统
能够提供方便的元数据的操作和查询操作
详细的内容请参照这篇博客别人家的元数据系统是怎么设计的
数据分层
其实数据分层的意思就是对数据按照一定的层级来存储，这样做的好处很多，在下面列了几个，详细的请参考这篇博客：如何优雅地设计数据分层
- 清晰数据结构：每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
- 数据血缘追踪：简单来讲可以这样理解，我们最终给业务诚信的是一能直接使用的张业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。
- 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
- 把复杂问题简单化。讲一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
- 屏蔽原始数据的异常。
- 屏蔽业务的影响，不必改一次业务就需要重新接入数据。
维度建模
维度建模是一种数据仓库的建模方法，这样讲吧，它的作用就是帮你更好的组织和使用数据。 详细的讲解请看这篇博客：详解维度建模
维度模型是数据仓库领域大师Ralph Kimall所倡导，他的《The DataWarehouse Toolkit-The Complete Guide to Dimensona Modeling，中文名《数据仓库工具箱》，是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。
典型的代表是我们比较熟知的星形模型，以及在一些特殊场景下适用的雪花模型。
ETL 在数据开发的工作中主要是数据清洗，它包括数据的接入，初步的清洗，数据导入Hive或者Mysql中等一系列操作，目前比较火的大数据技术在很大程度上就是解决了大数据量下的数据清洗工作。
另外，很多写sql的任务也可以理解是数据清洗，比如使用sql对原始数据做一部分的业务处理、过滤掉一些特殊记录等，因此ETL的范围相对来讲比较广，很多数据开发的工作都可以归结到ETL中。
ETL，是英文 Extract-Transform-Load 的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。ETL一词较常用在数据仓库，但其对象并不限于数据仓库。
ETL是构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗,最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。
