早期阶段的ToB SaaS如何做「数据收集」

前言

早期阶段的ToB SaaS，从数据规模来讲，相对较小，所以从研发成本、服务器成本上，一切从简，采用「简单」的数据收集方案，进行用户行为数据的收集工作，从而指导业务和产品。

大数据计算一般的流程如下：

其中「数据收集」包含了「数据采集」「数据加工」「数据存储」三个步骤，通过这些步骤将用户的行为和环境信息转化为结构化数据，从而沉淀为数据资产，为产品设计、运营分析、业务决策提供重要的数据支持。

事件模型

记录用户行为，首先要考虑的就是如何结构化，即事件模型

• WHO：用户ID、设备指纹、学校ID ......
• WHEN：事件发生时间、时间上报时间
• WHERE：设备信息、网络环境、业务环境 ......
• WHAT：事件标识、场景标识、事件参数

埋点SDK

为了简化业务同学开发埋点时的工作量，并对埋点日志进行一些必要的限制，需要统一的埋点SDK，目前需要2个端的SDK：微信小程序SDK、JS SDK

SDK包含的功能如下：

• 用户标识管理
• 设备信息、网络环境、业务环境自动收集
• 事件上报生命周期管理（上报机制）
• 兼容性处理
• ......

数据存储

日志经过「数据采集」「数据加工」「数据存储」这三个阶段，在每个阶段后，产生的数据，从类别、存储介质、保存时间上是有区别的。

数据收集架构设计

1. 各种端的SDK监控用户行为，通过Http请求上报给日志收集服务
2. 日志收集服务，把原始数据写到硬盘，并进行归档操作
3. 通过Filebeat + Logstash转发到Kafka内（主要是为了在高并发下，利用队列模式降低IO）
4. 日志ETL服务，针对原始数据进行分析和相关数据补全，存储到MySQL，形成中间层数据
5. 日志分析服务，针对业务，进行数据分析，形成分析结果数据
6. WEB UI针对分析结果数据进行相应的报表展现

未来阶段

数据量

由于目前SaaS平台的数据量不大，数据的ETL、存储等等，采取了经济、简单方案，在后面数据量升级后，ETL可以采用Hive、Spark、Flink等等大数据解决方案，存储可以采用分布式大数据存储方案，HDFS等等。

大数据测试

当埋点较多、端类型比较多时，为了便于QA进行埋点测试，需要针对QA的测试方案，进行自动化大数据测试流程的设计和实现，保证埋点数据的准确。