数据处理是数据产品经理最为重要的一环，相比最后 报表展示、分析报告、数据驱动，这一环往往耗时长、体现价值低，却牵一发而动全身。我们经常会听到，同一个功能数据分析结果截然相反，追溯原因发现在数据处理过程中，存在错误等。
本篇文章将以数据产品的角度来看数据采集后数据流的处理过程；并讲解一丢丢偏技术、但与数据产品产出息息相关的数据仓库。
一. 数据处理过程
数据产品经理的工作中一大部分都是将不可估测的数据转化为可见的报表、有结论意义的分析报告——也就是将数据从各种异构的数据源中、汇总，最终展示为报表、仪表盘、动态数据分析查询、结论性的分析报告等等。
1. 有哪些异构数据源呢？
- 服务端、客户端用户行为日志
- 用户的历史信息，定性信息(e.g.性别，职业的用户画像数据)，定量信息(e.g.近30天的某个兴趣倾向程度)
- 第三方等获取的信息，e.g.爬虫数据、人工整理的数据等等
2. 这信息大都需要二次加工、清洗，生成结构化的数据
- 脏数据的清洗、整合，e.g.延迟数据的按照发生日归纳；
- 生成基础性的表，以提高数据的易用性，e.g.用户基础数据、行为数据的基础表；
- 生成可以直接应用于报表、分析的用户&行为结构化业务应用表；
轻描淡写的2个步骤，却是影响报表展示、分析结论的关键点，也是数据产品经理最需要细心处理的地方。
二. 数据仓库(Data Warehouse)
数据处理过程往往比较模糊，但“异构数据源->结构化的数据表->报表/分析报告”的过程中，我们常见的各种数据库表就是数据仓库的实体，如常见的hive，spark，Oracle等。那在数据产品经理日常数据处理中应该注意哪些数据仓库知识点呢？
数据仓库是这么定义的：数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合。
这个定义中有一个定义比较容易含混，那就是“面向主题”。面向主题是指数据仓库围绕一些主题,排除对于决策无用的数据,提供特定主体的简明视图。近年提出的“面向专题”的分析和这个概念混淆的厉害，只能用用户熟悉的业务才能作出解释。
面向主题
面向主题跟面向应用相对应。面向应用是指实现某种功能，数据集合也是其单一功能的数据集。而面向主题是指为了实现某个主题而产生的一个或多个的面向应用的数据集合的整合。
举个例子，支付是一个面向应用的主体，而交易是一个面向主题的主体。因为交易是从下单，到支付等的一系列的过程的串联，支付只是其中的一环。
集成
数据仓库的一个重要的功能是把不同的数据源的数据汇总到一起。
集成是指把不同类型的数据源的数据进行整合，按照统一的形式进行集成。比如性别在一个数据源用男/女 另一个用1/2,那么在数据仓库中我们需要对其进行统一。
相对稳定
数据一般有一定的生命周期，历史的数据一般不会再改变，我们可以采用增量的策略进行数据的传输和计算。比如看订单的支付成功的相关信息，那么一旦订单支付成功之后，这个订单的支付成功相关的信息就不会在变更，所以此类的数据可以按天增量计算。
反映历史变化
由于在数据仓库中可以存储历史的信息，那么就可以根据这些历史信息进行数据的分析来反映历史的变化。而操作型数据库一般只会某些时间段的数据。
从数据仓库的概念中也可以看出来数据仓库做的事情确实跟数据库不一样。归纳起来如下
数据粒度不同。数据库存储的是操作型数据，是细节性的数据，事当前的数据，反应的是最后修改的结果。数据仓库是分析型的集成或者汇总的数据，面向主题，并且保存数据的所有历史状态。
数据生命周期不同。数据库存的数据的生命周期比较短，不会保存很久的数据。数据仓库则需要历史数据来反映趋势的变化和数据分析。
建模方法不同。数据库采用范式建模，不能有冗余。数据仓库的建模方法有DW范式建模（跟数据库的范式建模也不同）和DM维度建模等，可以存在冗余。
时间敏感度不同。数据库的数据要求及时性非常高。数据仓库可以容忍数据的一定的延迟。
目标不同。数据库主要面向业务处理的，而数据仓库则面向分析用户。
1. 数据仓库分层
为什么要做分层呢？
- 更清晰的管理、追踪数据(清洗的数据结构、明确的血缘关系)：有助于我们去查找数据处理的整条链路；
- 通过建立通用的中间表，减少重复计算：一张通用的中间表，能够有效提供能够直接贡献于下游业务数据表，以避免每次都从原数据中产出业务数据表；
- 清晰的数据仓库分层，将能够有助于我们分解数据处理过程：将复杂的数据->业务应用，拆解成多个步骤，每一层只处理单一的步骤；
数据分层具体是指？每一层应该注意什么呢？
操作数据层(ODS，Operational Data Store)：该层级的数据，最接近数据源的原始面貌(内容和粒度与原始数据一致)，通常是数据源直接经过ETL后，存储于此。从原始数据到ODS层，不建议做复杂的数据清洗，以免破坏原始数据，引起不必要的排查成本。
建议仅进行——
- 将json记录的日志，映射到各字段中;
- 作弊数据的清洗；
- 数据转码：将编码映射成具有真实含义的值
- 数据标准化，e.g.把所有的日期都格式化成YYYY-MM-DD的格式；
- 异常值修复，e.g.视频播放表：（包含用户id、视频id、播主、播放时间等）。
如果一个表划分为ODS层，那么一定要确认是否将原数据的有意义字段均清洗过来。
明细数据层(DWD，Data Warehouse Detail)：对ODS层做一些业务层面的数据清洗和规范化的操作，e.g.用户播放视频的日志级表;
如果一个表划分为DWD层，是否清晰、明确的记录了业务层面的明细数据？
汇总数据层(DWS, Data Warehouse Summary)：依据业务需求对ODS/DWD层的数据进行了汇总，e.g.带有用户画像信息的播放视频；
如果是DWS层的表，是否能够有效、便利的服务于业务方向统计需求？
应用数据层(ADS，Application Data Store)：业务需要进行的统计数据结果，e.g.各类型用户的视频播放统计。
如果是ADS层的表，是否能够得到业务需要的统计数据？
维度表(DIM)：存放基础信息，如用户属性表-性别、年龄等等。
如果是DIM层的表，是否全面记录了后续分析或统计需要用的各个维度？
除了固定为分层外，当然还有临时表(TEM)。
阿里/华为的数据仓库数据分级：操作数据层（ODS）、明细数据层(DWD)、汇总数据层(DWS)和应用数据层(ADS)，维度表(DIM)； 操作数据层、明细数据层、汇总数据层都是公共数据层。
此外，涉及表时，需要充分考虑这张表后续是哪个角色的同学使用，表是否足够易用？是否内容冗余？是否安全？
- 业务线的同学是否能够通过几条简单的SQL语句，拿到数据结果？
- 可以通过单张表格统计到数据还是需要多表关联获取？
- 单张表是不是内容冗余，是否会影响查询效率？
- 多表关联时，是否会有业务理解上的坑，e.g.多表间的字段是一对一，一对多，还是多对多，如何让使用者清晰的理解？
- 表中是否涉及敏感的字段，比如金额等，使用群体是否有足够的权限获取这些信息？
2. 元数据管理
元数据及应用也是数据仓库的重要组成部分，它是描述数据的数据（data about data)，描述数据的属性信息，可以帮助我们非常方便地找到他们所关心的数据。
元数据记录了哪些信息？
- 数据的表结构：字段信息、分区信息、索引信息等；
- 数据的使用&权限：空间存储、读写记录、修改记录、权限归属、审核记录等其他信息；
- 数据的血缘关系信息：血缘信息简单的说就是数据的上下游关系，数据从哪里来到哪里去？我们通过血缘关系，可以了解到建立起生产这些数据的任务之间的依赖关系，进而辅助调度系统的工作调度，或者用来判断一个失败或错误的任务可能对哪些下游数据造成影响等等；而在数据排查过程中也可以帮助我们定位问题。
- 数据的业务属性信息：记录这张表的业务用途，各个字段的具体统计口径、业务描述、历史变迁记录、变迁原因等。
这部分数据多是我们手动填写，但却能大大提升数据使用过程中的便利性。
3. 离线数据仓库&实时数据仓库
此外，根据数据实时性，数据仓库可以分为离线数据仓库、实时数据仓库。
- 离线数据仓库主要记录t-1以上的数据，以天、周、月数据计算为主；
- 实时数据仓库是随着人们对实时数据展示、分析、算法的需求而出现的。
4. 总结
数据处理过程是数据产品经理 产出报表、分析报告耗时最久的部分，了解数据仓库的概念&关键点，有助于我们清晰、有效的处理数据，提高工作效率，将更多的时间用于业务洞察。
数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持（Decision Support）。其实数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因。因此数据仓库的基本架构主要包含的是数据流入流出的过程，可以分为三层——源数据、数据仓库、数据应用：