小米拥有3亿多的miui用户、20多个日活过千万的app、丰富的生态链产品，所有的这些服务每时每刻都会产生大量的用户数据，这些数据构成了小米宝贵的数据资产。面对海量的数据，该如何整理、管理和应用以产生更大价值？前几天和小米大数据组的两位核心开发做了一些沟通，在此记录一下自己的理解。
谈起数据，其典型的生命周期是采集、加工和应用，小米也是同样的思路，不过使用了一个非常有画面感的名字来总结这个过程，即小米的数据金字塔。整个金字塔的结构如下图：
我们顺着金字塔的结构，由底向上依次分析一下各个层级所代表的业务含义，同时理清楚小米的数据治理思路。
ODS层
ODS是Operational Data Store的简写，大量的原始数据均归为这一层。原始数据主要包含两种，一种是日志数据，一种是由线上数据库如MySQL批量导出的数据。
日志型数据统一使用Thrift来描述和序列化，用户需要在定义数据时指明数据字段的含义。所有的Thrift定义均在一个叫做“数据工场”的平台统一管理，数据工场负责生成Thrift定义对应的Java类并部署到Nexus，各个业务线依赖这些Java类进行数据记录，并通过类似Flume的数据采集系统将数据打到HDFS以持久化存储。
对于选用Thrift这种格式进行存储，在实践中也会发现一些局限性，主要有两点：1. 数据本身不带Schema信息，这导致我们对已有的数据进行Schema发现时较为困难 2. 需要使用生成代码来进行数据序列化和反序列化，这导致我们较难写一些通用的代码去处理所有的数据，而且总是要关心是不是需要加载新的生成类。
MySQL数据通过Sqoop每日定时导出到HDFS，一般以文本的形式进行存储。
ODS层最大的特点在于数据定义和数据格式的统一。将所有的数据定义集中管理为后续的数据字典、数据地图打造了良好的基础，同时使得整个公司不同业务线数据的整合变得更为自然；而统一格式则极大的减少了后续ETL所需要的工作量。
DWM层
ODS再上一层称为DWM层，是Data Warehouse Medium的简称。从原始的数据采集到最终的数据分析，中间一般还会经历一系列中间任务（包括Hive SQL，Spark任务，MR任务等），这些任务共同组成一个Pipeline。Pipeline具体要完成的任务非常多，例如脱敏、统一格式、与其他数据表的集成、转为更易于分析的维度模型等等。原始数据表经过Pipeline的处理会形成一系列的中间表，这些中间表统一归为DWM层。
任务调度器是DWM的底层依赖，常见的调度器实现包括Azkaban、Airflow等。Pipeline中的任务以DAG图的形式存在于调度器中。通过分析调度器的数据，我们可以得到一个中间表的生成路径，或者称之为血缘。有了血缘数据之后可以做一些非常有用的功能，例如可以得到一张表的被依赖情况，被依赖数越多从侧面说明这张表的数据越重要；另外通过血缘数据我们可以做到任务通知的功能，例如表的数据没有按时生成，或者表的结构发生了变化，我们可以及时通知到依赖这张表的任务。
DWM层的一个难点是需要对业务数据有极深的理解，只有在深入理解的基础上，才可以设计出简洁高效的数据模型。另外值得一提的是，无论是ODS层的原始数据表还是DWM层的中间表均在Hive中有定义，数据分析师可以使用Hive/Spark等方式直接访问。
DWS层
DWM之上称之为DWS层，是Data Warehouse Summary的简称，DWS以宽表的形式存储加工完成的数据。宽表分为公司级和业务级。公司级的宽表会存储一些全公司通用的数据，典型的例如用户画像数据。业务宽表的内容则随着业务变化而有所不同。
DWS层的数据会被数据分析师们直接使用，因而其对质量的要求会更高。为了保证数据质量，会有监控任务去定时检查宽表中每天新生成的数据，并与前一天的数据进行对比以判断数据是否有异常，举个例子，当某一天的新增用户数异常下降时（变化幅度大于某个阈值），很有可能是发生了数据丢失。除了数据质量本身，DWS层表模型的变更也较为慎重，需要由业务方发起请求，再由大数据团队经过分析实现后才能更改。
另外一个需要重点关注的是隐私问题。小米对用户的隐私极为关注，内部有专门的隐私委员会负责用户隐私的保护。ODS、DWM和DWS中的每一张表都需要设定具体的隐私级别，具体分为A、B、C三级，对A、B级的数据访问需要事先申请权限。一些更为隐私的数据则存储在独立搭建的隐私集群中，在存储层即加密。
ADS层
最后是ADS层，是Application Data Store的简称。这一层的主要功能是将DWS层的数据以更好的服务的形式提供给用户。ADS层提供的典型服务包括用户画像、Kylin OLAP分析、ID Mapping、BI可视化、行为序列分析等。
先说用户画像，画像的数据延迟为T+1，每日更新后的数据以宽表的形式存储在HDFS上。用户对画像数据一般有三种类型的访问需求：点查询，人群统计和人群提取。
点查询是指给定一个具体的ID，可以快速得到此用户对应的画像数据。HDFS不支持快速的随机访问，因此为了支持点查询，会将画像数据冗余存储一份到HBase中。
人群统计是指快速得到某个人群的统计信息，方便用户在做人群提取之前先对目标人群有一个直观印象，为了这一功能会将数据冗余一份存储到ES中以进行索引。
人群提取是指给定某些具体条件后，将符合条件的用户全部筛选出来。人群提取使用Spark任务来完成，一般耗时会在十分钟级别。
ADS层提供的另一个重要功能是Kylin OLAP分析。对于DWS层的数据表，选择合适的Dimensions和Metrics在Kylin中预先构建OLAP Cube，可以使用户可以亚秒之内完成数据分析，极大的提升用户体验和效率。对于ADS层提供的其他功能，这里不再详细介绍。
总结
小米的数据金字塔和传统的数据仓库架构非常相似，但个人感觉其表达性更好，让人更易理解和记忆。整个金字塔包含了非常多的内容，例如数据字典、数据血缘、维度模型、用户画像等等，通过对金字塔的分析我们可以较为清楚的理解小米数据从采集到分析的整个生命周期。
