前言

问题分析

不同人对数据的需求是不一样的，或者说，不同同学对同一份数据的不同指标组有不同的价值认可。

1.我们的交互同学更多地会参考大盘的“用户习惯”，使用某个问卷题型的比例来作为设计方案的数据支撑；

2.开发同学更多地会关注这个数据引发地一些性能（问题），架构指标等；

3.产品同学会非常关心某个上线项目的入口流量，转化率相关指标；

4.运营同学关注的方面更为通用，除了大家都关注的北极星和护栏指标，他们更会关心用户在使用上的一些点位问题，单个/单批用户的运营策略转换问题。

1.我们要如何快速找到我们指标对应的底层数据？当时一个关于「活跃用户」在团队版中的表现的下推分析，后面还加上了登录渠道的多维分析，我们甚至开了一场会去校对口径 ;

2.关于口径，我们如何确定什么数据是对的呢？不同的数据开发同学开发的报表相差很大；

3.开发同学有非常美好的想象力，一句超凡脱俗的SQL不仅在当前的架构下得不出结果，甚至会拖垮其他依赖的组件。

在做这个事之前，我问组里的同学：“我们有什么数据能够支持我们做数据分析？”，清一色的回答：“ES里的后端Event日志，前端上报的Pageview和埋点，业务DB中的表”。确实我们早期就有比较统一的基于事件流的日志格式和较为完备的前端埋点组件，但是我们还是没法回答我们拥有的数据如何支持我们完成某些需求的问题。只有我们把我们拥有的数据的具体能力和表现形式放出来，我们才能真正知道我们拥有的是什么，数据才能真正地从数据存储变成数据资产。

明确数据表

同理，我们把存在业务DB中的数据平移到数仓中，这些数据表本身经过了不错的数据建模，我们将我们拥有的表保留退化维度同步到数仓，我们就得到了DIM层(块)。维度表一般不带有时间属性，用于关联做维度分析。

业务总线矩阵构建

至此，我们能够清楚地认知数据可能会在哪个位置发挥什么作用，下一步要解决的是我们该怎么找到我们的数据这个问题。

元数据管理

问卷的业务数据库里有百余张表，其中大约有近4成为维度表，需要拆分成明细的点位或者日志会随着业务发展主键膨胀，业务总线矩阵也会主键变成一张大网，失去可检索性。事实上，我们对数据的需求是有描述性的，比如想看“这周问卷的新增明细”，我们并非记住一串冰冷的文字，我们更希望能把「1周」，「问卷」转换成描述条件作为我们元数据的检索入口。 我们支持了Superset从表comment、字段comment中检索的需求，把想要的关键字按照关键字检索匹配到正确的数仓入口。

数据架构

和Lambda架构不同，我们的低时延分析需求更多地由近实时分析层承担，针对不同需求，我们尝试过很多不同的组件，根据不同的使用场景，比如全文查找、强聚合、上下文分析等等，我们会选择不同的组件。基于不同的组件，我们在上层有去尝试做不同的应用实践。

应用实践

机器学习

在最早期我们通过ES去查找单份答卷用户在答题过程中的所有用户行为埋点数据来构建序列数据进行预测，将预测结果写入DB；在近一年中，我们把查询数据源经过计算清洗后写入按问卷和用户为索引的ClickHouse数据源中，同时将服务与线上服务解耦，使用kafka来进行通信；最后配置了消费监控和写入监控，使这个服务成为一个单独维护的组件。以牺牲少许的实时性为代价大幅提升了预测速度和可用性。

实时风控

在架构上，风控模型走的是全实时数仓链路，从Kafka明细中读出前端上报信息和后端收集答卷的日志，在Flink中做实时的多窗口聚合写入到下游的数据组件。在前期选型中，业务侧希望能够具有实时调用和短时间指标回溯的能力，同时希望系统组件能够相对轻，能从云上购买，最后我们选定了Kafka作为业务侧实时接收窗口聚合结果的组件，PostgreSQL作为小时间段的回溯组件来构建线上的风控分析。

AB实验

目前，我们已经在SaaS平台内对文案显示、用户逻辑等多方面做了很多次AB测试，通过pv上报的曝光和event埋点的转化分析，能够实时构建单个用户的转化行为；相同地，我们会对实验时间范围内的数据使用ClickHouse构建用户RBM，分析不同用户在不同实验命中的表现情况。

总结

通过补齐一些基本的数据架构和数据规范，目前我们在数据驱动的实践上已经走出了一条自己的路。随着用户调研类组件的发展、用户分析需求的增加，其分析能力也会随之增强，越来越多的数据能力正在沉淀成底层功能加入到SaaS服务侧。