数据通过埋点收集上来(先前有介绍埋点技术、埋点通用的事件模型)，需要进行数据处理。
数据处理的概念太过大，本文将介绍：
(1)数据采集后数据流的处理过程；
(2)数据处理中的关键知识点：数据仓库
一、数据处理过程
数据从各种异构的数据源中，处理、汇总，最终展示为报表、仪表盘、动态数据分析查询等等。
step1.异构数据源
(1)通过数据采集到的服务端、客户端用户行为日志；
(2)用户的历史信息，定性信息(e.g.性别，职业的用户画像数据)，定量信息(e.g.近30天的某个兴趣倾向程度)；
(3)第三方等获取的信息；
step2.以上这信息大都需要二次加工、清洗，生成结构化的数据；
(1)脏数据的清洗、整合，如延迟数据的按照发生日归纳；
(2)生成用户基础数据、行为数据的基础表，以提高数据的易用性；
(3)生成用户&行为结构化业务应用表，这部分数据直接服务于业务，贡献于报表展示、数据查询/分析/挖掘等；
轻描淡写的2个步骤，却是数据存储、合理化、最大化利用的关键。
二、数据仓库(Data Warehouse)
而刚刚描述中数据获取、数据存储、提供给使用方都是数据仓库系统的部分，其实体是我们常见的各种数据库表，如常见的hive，spark，Oracle等。
1.数据仓库分层
为什么要做分层呢？
a.更清晰的管理、追踪数据(清洗的数据结构、明确的血缘关系)；
b.减少重复计算，通过建立通用的中间表，减少重复计算
c.分解数据处理过程，将复杂的数据->业务应用，拆解成多个步骤，每一层只处理单一的步骤，便于维护、定位问题；
d.更高效的访问数据，避免用户直接访问基础数据；
数据分层具体是指？
缓冲层(Buffer)：用于存储每天的增量数据和变更数据，直接从kafka接收源数据。
操作数据层(ODS)：该层级的数据，最接近数据源的原始面貌(内容和粒度与原始数据一致)，通常是数据源直接经过ETL后，存储于此。从原始数据到ODS层，不建议做复杂的数据清洗，以免破坏原始数据，引起不必要的排查成本。建议仅进行(a)将json记录的日志，映射到各字段中;（b）作弊数据的清洗；(c)数据转码：将编码映射成具有真实含义的值（d）数据标准化，e.g.把所有的日期都格式化成YYYY-MM-DD的格式；(e)异常值修复； e.g.视频播放表：（包含用户id、视频id、播主、播放时间等）。该原数据日志为服务端上报的json格式，经历字段解析、作弊数据清洗、异常播放时长的数据后，产生该表。
明细数据层(DWD):基于业务过程建模，即对ODS层做一些业务层面的数据清洗和规范化的操作;
汇总数据层(DWS):依据业务需求对ODS层的数据进行了汇总；
应用数据层(ADS)：基于业务需要进行的统计数据，e.g.各类型视频的播放统计。
维度表(DIM)：存放基础信息，如用户属性表-性别、年龄等等。
除了固定为分层外，当然还有临时表(TEM)。
各层级数据表的关系：如下
阿里/华为的数据仓库数据分级：操作数据层（ODS，Operational Data Store）、明细数据层(DWD，Data Warehouse Detail)、汇总数据层(DWS, Data Warehouse Summary)和应用数据层(ADS，Application Data Store)，维度表(DIM，)； 操作数据层、明细数据层、汇总数据层都是公共数据层。
2.数据仓库每张表的搭建，主要依赖于这个表在整个数据仓库中的作用和相关意义。
（1）首先要清楚这个表为了解决什么问题而存在的?
如果是ODS层的表，是否将原数据的有意义字段均清洗过来？
如果是DWD层的表，是否清晰、明确的记录了业务层面的明细数据？
如果是DWS层的表，是否能够有效、便利的服务于业务方向统计需求？
如果是ADS层的表，是否能够得到业务需要的统计数据？
如果是DIM层的表，是否全面记录了后续分析或统计需要用的各个维度？
（2）什么角色使用，表是否足够易用？是否内容冗余？是否安全？
业务线的同学是否能够通过几条简单的SQL语句，拿到数据结果？
可以通过单张表格统计到数据还是需要多表关联获取？
单张表是不是内容冗余，是否会影响查询效率？
多表关联时，是否会有业务理解上的坑，e.g.多表间的字段是一对一，一对多，还是多对多，如何让使用者清晰的理解？
表中是否涉及敏感的字段，比如金额等，使用群体是否有足够的权限获取这些信息？
以上都是我们设计数据表时需要考虑的。
3.元数据管理
元数据及应用也是数据仓库的重要组成部分。它是描述数据的数据（data about data)，描述数据的属性信息；可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据。
元数据记录了哪些信息？
(a)数据的表结构：字段信息、分区信息、索引信息等；
(b)数据的使用&权限：空间存储、读写记录、修改记录、权限归属、审核记录等其他信息；
(c)数据的血缘关系信息：血缘信息简单的说就是数据的上下游关系，数据从哪里来到哪里去？
在数据排查是可以明确的知道数据在哪个环节出了问题，从而快速定位问题。
也可以通过血缘关系，建立起生产这些数据的任务之间的依赖关系，进而辅助调度系统的工作调度，或者用来判断一个失败或错误的任务可能对哪些下游数据造成影响等等。
(d)数据的业务属性信息：记录这张表的业务用途，各个字段的具体统计口径、业务描述、历史变迁记录、变迁原因等。
这部分数据多是业务方手动填写，但却是表使用过程中必须的信息，建议可以设计在建表/修改表的过程中，强迫建表人员填写/维护相关信息。
4.离线数据仓库&实时数据仓库
根据数据实时性，数据仓库可以分为离线数据仓库、实时数据仓库。离线数据仓库主要记录t+1以上的数据，以天、周、月数据计算为主。实时数据仓库是随着人们对实时数据展示、分析、算法的需求而出现的。
学习过程中参考：http://www.mdjs.info/2018/04/07/datatalk/usage-of-ods/#more
