沉下心来认真做一次近几年工作的总结，谈谈如何从零开始搭建一个用户数据平台。
做一件事情之前，先问问自己3个W，WHY、WHAT、HOW。
- 为什么我们需要用户数据？
- 为什么需要这样一个用户数据平台？
- 如何搭建一个大数据场景下的用户数据平台？
大数据场景下，用户数据具有极大的分析价值，一条用户数据可以归纳成为由多个用户标签组成的数据集合，并用唯一的ID进行标识。用户数据中蕴含的信息是极其分散的，而要将用户数据真正投入业务使用，中间需要有非常多的步骤。
因此，我们定义用户数据平台是一个包括用户数据挖掘、数据管理、数据服务等模块的统一的用户数据解决方案。
一个用户数据平台应该具有如下能力：
- 丰富的用户数据：这一点毋庸置疑是最基础的，多维度的用户标签数据是数据应用的基础；用户标签体系因应用而已，根据行业的不同，会有不同的设计。例如视频行业，可以去挖掘更多用户在观影方向的偏好，旅游行业，用户的户外兴趣会是更有帮助的数据。
- 合格的监控管理系统：对外，需要给用户一个入口，来了解、申请和使用你的数据；对内，需要有完善的监控管理机制
- 数据输出能力：包括用户数据怎样去赋能业务，给予决策人以正向的数据依据。这一点比较宽泛，数据输出可以有多种方式，举一些简单的例子：1）最直接的，是数据直接触达业务，常见的场景包括线上的用户定向，推荐场景中的基于用户数据的召回过滤策略等；2）各类DMP系统、分析系统、画像系统，都需要用户数据支持，给到系统的数据，往往是经过查询聚合的；3）离线的用户特征，用户行为分析等。
基于以上几点考虑，我们可以归纳为，一个用户数据平台，自底向上应该是包括三个主要层级的，分别是：数据、系统、服务。
与小规模的用户角色分析不同，大数据下的用户分析方法是基于用户画像的。下图从技术方法、核心目标、数据形态、应用场景和应用特点分析了用户角色和用户画像的区别。在这里，我们所说的用户数据平台，也可以称之为用户画像平台。
简单的描述画像中的一条数据，那就是在一个特定的用户ID下，有多个维度的用户标签。如下图所示，我们通过用户标签数据来描述一个用户。在这里，用户是一个抽象的概念，一个用户，可以是一台手机设备，一台PC或者TV设备，也可以是从账号维度来描述的一个虚拟用户，用户标签数据的结构往往是复杂的，一个标签数据可能存在多个信息，例如权重等，图中只是标签值的一个简单表述。
我们从数据层、系统层、服务层三个层级，具体谈谈如何从零去搭建这样的一个平台。
数据层主要描述的是如何进行用户数据的挖掘以及存储。
用户数据挖掘的方法多种多样，包括：统计分析、数据建模、机器学习等等。这边不再展开详细描述。大数据场景下的数据处理技术已经很成熟了，包括Hive，MR，Impala以及一些流数据处理技术包括Flink、SparkStreaming等。
从数据生产过程看，整条数据线一般是按如下流程。
投递层：pingback数据
|
数仓层：数仓数据表 + 数据流 + 业务线DB + 第三方数据
|
使用层：用户数据挖掘
|
存储层：大数据服务 + 数据库以用户标签为例，数据挖掘过程可以描述为：在海量用户行为数据中根据用户标签的定义产出最终的用户标签值。
简单的用户数据挖掘，例如我们现在需要挖掘用户的常驻城市，可以有的做法很多。最简单的，我们可以通过上报日志中的IP地址做一份IP到CITY的对应关系，通过简单的聚合运算配合合理的规则，推测出用户近一段时间的常驻城市；进一步的，我们考虑IP对CITY是有大量的脏数据的，例如小运营商、代理等情况，这时候我们可以考虑使用GPS的数据来进行校正，通过开放的地图API获取GPS对应CITY的关系，获取更为准确的位置信息；更进一步，我们可以加入其它数据源来增大标签的填充率和准确性，例如使用Wifi的上报数据等。
更复杂的，我们可以通过用户行为特征，预测用户的年龄、性别、人生阶段、消费水平等信息，算法同学会更为了解这个过程。此外，数据分析师基于数据建模分析的结论也是一个准确的数据获取途径，例如观影忠实度、会员流失预测等。
这里的数据存储仅限于底层的离线用户数据，暂不涉及上游的数据服务。技术的选型是因应用而异的，不同的数据大小，数据结构，其所用到的数据解决方案都不一样。
在TB以上级别的数据量级下，我们会考虑大数据的解决方案。一个用户数据，多个维度标签，显然列式存储的数据库更适合于这样条数多但相对稀疏的数据。
底层离线数据的存储，这里更推荐的是HBase，回想一下HBase的特点和适用场景是什么？
HBase是Google Bigtable的开源版本，是建立在HDFS之上，提供高可靠性、高性能、列存储、可伸缩、实时读写的数据库。
HBase 中的表一般有这样的特点：
- 大：一个表可以有上亿行，上百万列；（足以应对标签维度）
- 面向列：面向列(族)的存储和权限控制，列(族)独立检索；（单独的数据检索和权限控制）
- 稀疏：对于为空(null)的列，并不占用存储空间，因此，表可以设计的非常稀疏；（Bingo）
- 数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元插入时的时间戳；（多数据版本，灵活的数据提供和使用方案）
无疑HBase的表特点是与用户数据的特点吻合的。
进一步的，我们想想HBase能提供什么样的能力。HBase的数据Get是亚秒级别的，无疑不适合高并发的数据获取，但HBase提供批量Scan的功能，适合一次写，多次读的场景，针对不同的服务应用，我们只需要将数据导入到其他不同的存储介质下即可；
即通过怎样的数据结构来存储用户数据，最直观的理解，一条用户数据的存储应该是这样的。
// 使用Java对象表述，仅是便于理解，不等同于真实场景中的设计
// 整个用户库数据，其中key为用户ID，即某种规则下的唯一标识，value为用户标签数据
Map<Object, Map<Object, Tag>> userData;
// 用户标签数据，其中key为标签ID，即某种规则下的标签标识，value为标签数据的结构
Map<Object, Tag> userTags;具体的设计因场景而异，实际应用中，以下几点我们可以稍加考虑：
- 数据压缩：尽可能使用少的字节数来存储数据
- 跨语言：结合跨语言、跨平台和数据压缩，google protobuf是一个比较不错的选择
- 结构稳定性：举一个这样的例子，假如你的设计中，把每一个标签设计成pb的一个字段，那每次新增字段时，pb的结构是会变的，这样带来的一个影响是，对所有数据使用方，需要用到该字段时，都得更新数据schema。
- 可扩展性：数据结构的设计应该是有能力满足未来更多可扩展的需求的。
常用的保证高可用的手段包括：多集群多机房的数据部署；数据读写分离。
一个鸡蛋不能放在同一个篮子里，多集群的数据部署可以保证不同集群的业务获取数据的便捷性，同时保证了集群出现问题的情况下，依然可以有数据提供。
数据读写分离的操作主要是为了保证业务方使用数据的稳定性和一致性。此外，在构建读表时，可以根据实际情况中业务的情况，导出不同的视图表，做业务上的数据隔离。
在这里从数据质量和数据时效性谈谈用户数据是否对业务可靠。
数据质量无疑是一个最基本、最关键的点，就像高楼大厦的地基，若一份数据，质量不能保证，那对所有的业务，都有可能造成影响。
造成数据不准确的原因有很多，比如上游数据的规则更改，数据计算逻辑的错误，数据产出的不稳定，数据时效性过低等等。面对这些问题，这就要求我们在整条数据流水线中，做到一个非常严格的统一规范。
这要求我们从根源上开始保证数据质量，投递层一定是有一套统一的规范的，上到数仓层，所有的数仓表必须满足数仓规范，在这一层，大量的工作需要花在数据清洗上，他就像一个盾牌，帮助我们处理和拦住所有的数据问题。理想情况下数据使用层是完全建立在数仓上的，在数据规范的情况下，很多数据工作都是可以自动化的。
标签在进行数据挖掘时，逻辑的准确是必须保证的。针对一些软性的标签数据，例如偏好类的标签，建立完成的数据反馈路径是很重要的，用户数据反馈到具体标签上，是标签数据校准的一个重要依据。
理想情况下，我们希望实现这样的完美数据闭环。
投递 ---> 挖掘 ---> 应用
| |
|<---feed back-----|离线情况下，合理的数据时效性是T+1天。在线的场景下，合理的数据时效性是秒级（分钟级）。
当日的用户标签数据，应该是用到截止至当日凌晨之前的底层日志数据，处理后存储入库，以支持当日所有的数据应用，当然，对时效性要求更高的应用，我们可以在服务层做到分钟级甚至秒级的数据支持。
真实情况中，满足T+1的数据时效性并不是一件简单的事情。每一天有大量的日志数据需要处理，多维度的用户标签需要被挖掘，这就考验到我们如何来设计整个标签数据的生产线，每一个细节，我们都得去尽力的节省时间，做到效率最优。我们在数据管理层来谈一谈应该怎么去做。
管理层是一个怎样的角色呢？
- 对内，负责数据任务的调度和监控，帮助我们管理数据生产流程。这里的数据任务，简单的说，是一个用户标签从生产、加工到入库的整个流程。
- 对外，负责为数据使用方介绍数据，指引他们去使用数据。
总体来说，管理层是一个负责实现数据调度、数据管理、数据监控的完整系统。这其中还包括很多细节，例如：数据的权限控制、数据的快速恢复、数据的debug等等。
数据调度指的是如何合理的调度每日的标签数据任务，关键点在几个。
- 优先级控制：不同的数据优先级是不一样的，时间敏感型的数据，优先级会高于偏好型的数据
- 并发控制：涉及到底层数据队列资源的合理应用
- 错误重试：在整个数据流程中，调度出错时应做到重试和报警
监控系统主要做好两件事情。
- 数据入库前：对每天生产的数据有一个大概的预估，做好数据格式的校验，用户活跃校验等，将可能存在的数据不合理的变动，一律在数据入库前进行处理，异常变动会发出报警。
- 数据入库后：对库里的数据做好指标统计，包括数据量级、覆盖率等指标。合理的统计指标可以保证数据的稳定，同时也可以作为报表分析的依据。
此外，监控系统应该有完善的数据恢复手段。保证在出现数据错误的情况下，能快速的对数据进行恢复，避免影响到业务使用。
数据管理系统是一个面向于用户的web应用，类似于常见的管理系统，系统的主要目的则是与用户打交道，为用户提供便捷的相关数据操作。
管理系统因场景而异，一般来说可以包括以下几个方面：
- 数据介绍：包括每一个用户标签的详情介绍，基础指标查看
- 用户画像：展现一个完整的用户数据画像
- 申请管理：统一管理业务方的数据申请，包括数据接入，服务接入，权限申请等
- 后台管理：为系统管理员提供审批和数据修改等功能
这里不再展开进行介绍。
根据业务需求的不同，数据服务相对的也会有所差异。按照服务的性质，可以具体分为以下几类。
服务主要是为了满足用户特征或分析场景。
这样的场景需要用到全量的用户数据，因此需要每次根据需求，获取到全量用户的相关数据。
针对分析场景，可以使用Hive或Impala等OLAP的数据提供方式，提供统一的数据管理和更新，分析师可以按需进行数据查询。
针对用户特征的场景，常见的需求是需要获取一个用户的某一些标签数据作为某个模型的训练特征。针对这样的场景，更建议直接通过HBase作数据输出，当然，中间的数据步骤需要我们来介入，包括数据的解密、权限的控制等，一般来说，封装SDK是一个合理的选择。
服务主要是用户线上的数据定向。调用方通过一个或多个用户id，获取对应的用户标签信息。
使用的场景很多，例如线上推荐等需要用户数据进行数据判断的场景，具体的服务设计实现可以参考：高并发低延时的在线服务设计和实现
服务主要提供快速的用户数据聚合，例如画像分析系统或广告分析系统中，需要快速获取符合某个条件的用户群里的数量预估、信息分布等；
具体的服务设计实现可参考：快速查询服务设计和实现
实时数据服务用于解决高时效用户数据场景下的数据提供，如推荐场景中的用户行为反馈、冷启动等。
提供实时数据服务的方式大致有两种。一种是直接通过数据流提供，业务方通过数据流进行加工处理；另一种是将数据转换成用户标签进行数据提供，提供形式同样为根据用户id获取用户的标签信息。
一个实际中的应用场景是，新客用户画像服务。针对各冷启动的场景，新客用户画像服务可以快速的提供用户基本信息，包括设备信息、位置信息等，以用作用户召回。
用户数据应用是一个很宽泛的场景，针对不同的行业，不同的数据，不同的应用场景，都有其独特的数据解决方案。但数据、系统、服务，这三个大层级是不会变的。
技术没有好坏，针对不同的场景，去设计更为合理的方案，这才是重中之重！