数据产品的工作比较杂，从数据仓库建模，指标体系建立，到数据产品工具的设计，再到偶尔一些数据分析报告的撰写，甚至一些机器学习的预测模型都要有所了解。大公司可能每个职能都有专门的岗位来负责，小公司的话可能真的要你一条龙了。
其实数据产品从头到尾做的事情就是帮公司收集数据、存储数据、呈现数据、预测数据，拆分到具体的工作中，将会在下面介绍。
收集和存储数据：数据仓库
数据仓库是存放收集来的数据的地方，做数据分析现在一般尽量不在业务数据上直接取数，因为对业务数据库的压力太大，影响线上业务的稳定。
1. 数据收集的时间间隔
数据仓库里的数据按照数据收集的时间间隔大致分为两类：
- 一类是可以进行离线处理的数据，一般包括内部业务数据库及外部数据（比如：爬虫或第三方API）；
- 一类是需要实时处理的数据，比如：内部业务日志数据。
对于第一类一般的处理多数要求在“天”级别，比如说：一天从业务数据库更新一次数据就足够了，一般采用MapReduce等批处理框架来处理数据，批处理框架在进行大量数据的计算的时候有计算资源比较廉价等优势。
而第二类实时数据处理，需要采用一些流处理框架，例如：Storm、Spark等，来处理数据，当业务发展到一定阶段，业务人员对数据的实时性要求会越来越高，也就对大数据技术团队提出了更高的要求，当然实时处理数据所需要付出的代价也是更高的。
我们要分辨清楚，哪些数据采用批处理就可以了，哪些数据是有实时处理的价值的，并不是说所有数据都实时处理就是更好，毕竟集群资源是有限的，要合理利用计算资源。
2. 数据的分层存储
另外数据仓库的数据存储是分层级的，这个架构一方面跟数据拉取方式有关，一方面也是为了对数据进行层级的抽象处理。
一般来说数据仓库会至少分为ODS、MID、DW三个层级，当然层级的名称每个公司可能不同，这里主要是在作用上进行区分解释。
- ODS层存储的是业务数据库在一个时间范围内新增或更新的数据，它的存储是线性增长的，有数据发生变化，ODS才会存储数据。
- MID层是经由ODS层数据计算得出的最新的完整版数据，相当于是业务数据库的一个拷贝，只不过是截止到某一个时间的。
- DW层是对MID层进行业务模型的抽象之后的合并层，将一些冗余的库表简化，做成比较利于数据抽取的库表。
因为MID层和DW层存储的都是完整的数据，业务数据库数据会不断增长，导致这两个层级里的数据每个切片的数据都是在增长，相当于是指数增长。
3. 数据的切片存储
数据库的存储是分时间戳的，相当于是把数据按照快照的方式存了n个版本，当你想追溯在某天某时间的数据的时候，就可以通过定位特定的时间戳，追溯到相关的数据。
这种设计避免了业务库数据会不断覆盖的问题，相当于是在数据分析的时候加了一个时间维度，提升了一个维度，看问题解决问题的角度也就被升华了。
4. 数据仓库建模
MID层向DW层抽象的过程，需要数据产品对业务库表进行建模。首先要清楚了解，你所要进行抽象的业务系统是什么样的（感觉数据产品好累，还要去了解别人的系统是怎么玩的╮(╯_╰)╭）。
比如：你所要负责的是A业务系统的DW设计，那么首先你要把A业务系统的系统逻辑搞清楚，然后它所涉及的库表都了解清楚，包括业务本身的库表以及它所依赖的中后台系统的库表，以及各个数据库之间的关系是怎样，比如：是一对一还是一对多，当前库表是否是最细粒度的数据。
一般来说建模要做到模块互相独立，粒度统一。因为考虑到后期做指标和取数的方便，在不同粒度上都有表是比较好的。
比如：一个电商分期业务，可能在订单粒度上才能取到放款等数据，但是品类等维度又只能在商品粒度上取到（考虑到购物车，一个订单可能对应多个商品），这时候就需要两个粒度都建立对应的表才能满足不同的取数需求。
作为数据产品，一项基础工作即是为需求方取数据，一般来说简单的取数数据产品是要兼顾的，复杂的取数才会升级到研发来取，毕竟研发们都很忙嘛，小事我们自己也可以搞定的。
一、SQL思路3分钟入门
SQL可以实现的功能很多，建表、删表、插入数据、查询数据…这里主要介绍查询数据的SQL一般写法，SQL语言的主要逻辑也是在查询语句这一块。
传统MySQL类数据库或大数据中，用到的Hive数据库是按行索引的，可以理解为一条一条的记录，而且大数据用到的HSQL其实跟传统SQL语句基本是一致的。
我们常见的对数据的处理主要是这么几种：根据条件筛选数据，将记录字段横向合并，将记录纵向合并，而这对应的就是SQL语句中的查询/子查询、各种JOIN、UNION ALL。那种看似很长很复杂的SQL代码，其实也就是这三种操作的结合体。
如下图所示：可以理解为数据库查询就是将多份数据查出来，互相关联合并，生成一张新的表单，然后可以在新的表单的基础上进行查询或者再跟其他数据关联合并。
- 子查询：通过条件从一张或多张表中选取出数据，你可以理解多张表的查询，其实就是像图中所示加了一些join和union all的连接操作。如果只是从一张表中查询，那么就只用关心这张表的记录结构，是否有重复记录等。
- JOIN：相当于是对两份数据进行取并集、交集或其他集合方式的操作，是对两张表的字段进行了横向拼接，需要指定拼接的连接关系是用的哪个字段。比如：同一个用户，在一张表里记录了他的年龄，在另一张表里记录了他的性别，那么通过join操作就可以把这两个字段放到同一张新的表中，然后可以在这张新的表的基础上再进行其他操作。
- UNION ALL：相当于是把记录纵向叠加，比如：因为数据量比较大，业务库进行了拆表操作，将1-6月份数据放在表A，将7-12月份数据放在表B。因为是同样的记录，字段都是一致的，通过union all就可以做成一张新的表，同时包含A和B的数据在里面。
这里我都没有使用具体的SQL举例，因为展开来将可能会有很大的篇幅。想要进一步深入的同学，可以去查看相关的SQL教程，按照上面介绍的思路去学习，就不会感到迷茫了。
2. HSQL vs SQL
数据工作中，既要用SQL语句去业务库里查询对比数据，又要会使用HSQL在自己的平台（一般是Hue中的Hive）中查询。两种语言除了个别函数不通用，基本是一致的。
这里举一些例子说明：
- Hive中不支持not in操作，一般使用not exists代替，或者left outer join。
- Hive的切片机制导致取数需要加上条件使用的是哪天的数据。
- Hive的分层机制（同样上一篇有解释）导致在不同层级进行取数，逻辑是大不相同的。ODS层同一条id记录可能有大量不同时间更新的“重复数据”，要注意进行按一定顺序的去重处理。
- Hive中某些层级的数据中对时间的存储可能为unix timestamp格式，表现为一长串数字而不是常见的时间格式，需要在使用中进行转化。
- Hive中可以使用多种数据计算框架，比如：MapReduce、Spark等，在不同情况下选用可以获得更好的效率。
一、指标系统介绍
从直观上来理解，报表系统中的每张报表是通过一些SQL语句计算出来的，系统只要每天按照每张报表的SQL定时去跑数据就可以了。
但是随着时间的推移，报表数量越来越多，每天的定时SQL任务跑不动了。但是会发现其实很多报表用到了类似的指标，可能维度不同或者可能完全相同。
这时候就需要升华一下方案，将报表的计算，细化到指标的计算上。
上述问题的解决需要通过一套完善的指标管理服务来实现，指标服务相当于存储了某个指标各种维度下的SQL查询结果。如下图所示，对于指标1，指标服务需要存储其在维度1和维度2等维度下的所有拆分值，即存储的是“维度1-维度2-指标1的值”这样的索引结构。
有些数据团队会把这些指标值存储为数据仓库中的一个层级，相当于是对DW层明细数据的统计值计算，但是在实际应用中，对指标值的调用需要满足很强的即时性，存在数据仓库中可能达不到这样的性能要求，于是改为存储在HBase这种Key-Value存储方式的数据库中。
按照这样的存储方式好处是什么呢？
当你想要看指标1在“维度1=A&维度2=a”等各种组合条件下的值的时候，可以方便取出来，如果指标1是可以简单加和的，那么你还可以查看各种维度组合加和的数据。比如：不选择维度1和维度2的条件，直接看指标1的总计值，也是可以通过加和做到的。
这样的处理方式还为用户自助创建报表提供了可能，用户可以选择想看的指标在任意维度下的数据，还可以任意拼接指标形成自己的专属报表。
而且，这样做，一个指标不管被多少个报表用到，只用计算一遍数据即可。具体报表呈现的时候，实际只是将各种统计值进行组合，不需要运行SQL实时拉取计算数据，效率也就提高了很多。
二、指标系统的SQL实现
指标系统实际就是写一个稍微复杂的包含多个group by的SQL，其实看到上面的图，大家也可以联想到，其实就是自己在运行SQL的时候得到的一个包含多个索引的group by结果。
思路即使将指标拆分到最小粒度，再在报表中根据需要组合各个维度下的值。
三、指标系统的优缺点
上面解决方案听起来很完美，实际操作中还是有不少问题存在的。
- 对于计算时需要去重的指标（比如：一个用户多个订单这种事实表，要计算用户的数量），你得到的只是在当前维度组合下的指标。并不能简单实现只取部分指标的场景，或不选择维度的场景，大家可以自己思考下为什么。
- 因为指标系统拆为了尽可能增大指标的可重复使用性，拆分了尽可能多的维度，有时候甚至维度的组合行数已经达到了10万+的级别。这就造成在报表系统中组合不同维度的数据有时候，实时处理压力很大。当然也是有办法进行优化的，这里就不深入介绍了。
- 因为指标是一层数据抽象，当指标数据出现问题的时候，排查问题就相当于多了一层。类似的，修复数据也要多修复一层。
- 另外，如果要给现有指标体系增加维度，旧数据的处理也是一件比较麻烦的事情，因为需要重跑之前的历史数据。
四、业务的指标体系建立
指标的原理讲完了，那么在实际操作中，我们需要做哪些指标出来呢？
其实指标需求主要来自业务方运营人员等，但是不同运营部门可能关心的侧重点不同，而且会有遗漏情况。
首先我们要把不同部门的需求收集完，然后根据需求指标类型进行分类。在分类中要cover到大家的需求，还要尽可能穷举其他可能的指标。这部分也是依赖自己对于业务系统的了解及数据库的了解，其实跟数据仓库的搭建是一体的事情。
-
白话数据产品（四）——报表系统
一、报表系统原理
报表的数据呈现相当于是对指标数据进行维度合并和计算。
如上图所示，当我们只想在报表中看指标1在维度1下面的数据的时候，报表系统会将维度2中a和b的数据进行合并。同理如果只看不含任何维度的指标1的数据，那么就是再次将维度1中的A和B数据进行合并。
大家可以发现这种合并只是做了加和计算，所以像前一篇提到的，如果这里需要改变维度的是去重（Distinct）后的数据，那么就不能进行这种灵活操作了。修改维度相当于是得到了不精确的去重数据。
二、报表系统功能
1. 前台交互
新建报表会涉及到指标的选择、维度的选择。另外需要对展示进行设置，比如：指标的顺序，默认选中的维度等。为了让创建者对报表有一个预期，在性能足够好的条件下可以在创建的时候就显示某一天的数据预览。
查看报表的话，会涉及到报表的所属菜单管理，比如系统菜单、自定义菜单，以及报表的分享和关注。另外还需要对报表进行管理，比如：编辑报表、权限管理等。
2. 权限管理
权限管理是报表系统比较重要的一部分，因为涉及到数据安全以及不同部门的全责明确。
权限分为功能权限、指标权限、维度权限等。功能权限涉及比较广，比如：菜单管理权限、报表编辑权限等，核心是指标权限和维度权限。
指标权限和维度权限可以考虑以部门为基础，设置基础权限，这样免去了每次新入职员工的权限开通的麻烦，也方便对一批人进行统一操作，然后新增权限走审批。比较复杂的是一些敏感指标的权限审批可能要流转到比如风控等部门审批人，这就要求在指标权限管理上需要不断去维护更新这些关系。
反正这块真的是重中之重了，不要怕繁琐，数据安全是最大的问题。
3. 管理后台
管理后台包括功能模块管理、指标管理、维度管理等。
- 功能模块管理视每个系统的功能而定，较为低优先级，开发时间来不及前期版本都可以先手动调整。
- 指标管理维护指标的名称、分组、指标逻辑维护等，后期还可以加入衍生指标的创建等高级功能。
- 维度管理维护维度的名称、枚举值映射等。
三、报表的展现形式
一般来说报表分为表格型和图表型，表格型比较单一，图表型因为可以根据不同场景设计不同的UI效果，比较多元化。
表格型报表看起来比较枯燥，但是适合数据的多维展示，方便用户对数据进行再次加工处理。表格型报表不仅包括报表系统中的表格，还有向外输出的一些数据，比如：通过钉钉、微信等方式输出到群组中的数据。
图表型报表对数据变化趋势的展现比较直观，对于一些关键指标，推荐使用图表的方式进行展示。大家常听到的一类图表型报表是Dashboard，炫酷的UI效果+实时的数据更新，经常会被老板及运营人员放在电脑的第二屏时刻关注。
白话数据产品（五）——DMP（上）
一、用户画像系统介绍
1. 概念
用户画像即是给用户贴上各种各样的标签，比如：“年龄”=23岁的用户，“性别”=男的用户，又或者“是否成功购物过”=是的用户，“是否喜欢流行音乐”=是的用户。
2. 存储
可以把用户画像的记录理解为每条记录是对应不同的用户id，字段包括这个用户的不同属性，比如：“年龄”、“性别”，或者不同行为；比如：“是否成功购物过”、“是否成功借款过”。
如下图所示：
在实际运用中，根据各自公司业务的复杂程度，可以划分很多张表来存储用户画像。
另外，用户画像的数据是要不断更新的，可以根据需求不同对画像标签做不同的更新频次处理。如果只是用来做离线用户分析、定期用户营销，数据更新做到天级别一般都是可以接受的。
但是如果用在比如电商的推荐系统，那就需要更实时的数据更新，不然你的推荐很可能是无效的。
3. 分类
根据自身公司的业务情况对用户画像进行多级分类，比如：一级分为属性、行为等，二级可以在行为上进一步细分为访客相关、购买相关等。
另外除了上面提到的属性、业务行为的画像，还可以做一些抽象后的画像。比如：让业务人员在实际运营操作过程中给用户打标记，像风控部门会在用户行为审核上做一些标记，也可以记录在用户画像中。另外，大数据挖掘团队在对用户数据进行建模后得出的一些分析结果也可以存储下来。
二、标签的使用
首先，标签内部可以进行计算，比如“年龄”=23。相当于是构造了一个集合。
其次，标签与标签之间可以进行集合间运算，交并集操作等。
通过上面的操作就可以将自己想要的用户选择出来。
三、用户画像应用
1. 精准营销
大家应该有接触过广点通等推广系统，你在朋友圈和公众号里看到的广告就属于这类。为什么会给你的朋友圈推广告A而不是广告B，会在什么时间点出现等，都是基于用户画像的精准营销。
再比如：你在京东上看过某个商品，会发现在浏览其他网站的时候百度推广的广告位里呈现的就是你刚才浏览过的商品。
精准营销就需要运营方在做运营推广的时候，手动选择或自动选择你所需要营销的用户群体，而这个群体是营销平台事先进行数据分类的。
公司内部比较常见的一个应用场景是短信及APPpush发送，比如：你有好几天没有登录APP了，发个短信或者push提醒你下，最近又有什么新活动欢迎你来参加。
当一轮营销完成后，可以基于用户画像对营销后用户发生的行为进行再次分析、再次营销等，打造一个营销的闭环。
2. 推荐系统
最经典的是网易云音乐的音乐推荐系统，其实很早之前豆瓣FM也做过这种推荐系统。也有人写文章解析过云音乐的推荐算法，比如：你对曲风的喜爱程度、对关键歌曲的喜爱程度等。
其实这就是一个对用户画像数据建模的结果，根据用户各个标签中的值，通过模型来预测用户在一件事情的偏向程度。
由此延展开来，可以根据实际需求建立各种各样的模型来预测你想要观察的用户表现。你可以把这些模型通过界面或API的方式，提供给运营人员或运营系统使用。
3. 画像报告
在DMP这类的系统中提供对于整体或不同维度下用户的画像报告展示，比如：选择筛选条件为已注册用户，观察用户的地域、性别、年龄、操作系统等分布。
有了这个系统，之前手工输出的用户分析报告中的基础部分就可以被解放，报告可以重点进行更加定制化的分析。
总结
用户画像系统是以用户为中心，给用户打上不同的标签，也就意味着你可以根据需要 直接或通过建模 找到你想要找到的用户群体。之后就可以对挑选出的用户群体进行各种分析、运营、推广了。