前言
早期阶段的ToB SaaS，从数据规模来讲，相对较小，所以从研发成本、服务器成本上，一切从简，采用「简单」的数据收集方案，进行用户行为数据的收集工作，从而指导业务和产品。
大数据计算一般的流程如下：
其中「数据收集」包含了「数据采集」「数据加工」「数据存储」三个步骤，通过这些步骤将用户的行为和环境信息转化为结构化数据，从而沉淀为数据资产，为产品设计、运营分析、业务决策提供重要的数据支持。
事件模型
记录用户行为，首先要考虑的就是如何结构化，即事件模型
- WHO：用户ID、设备指纹、学校ID ......
- WHEN：事件发生时间、时间上报时间
- WHERE：设备信息、网络环境、业务环境 ......
- WHAT：事件标识、场景标识、事件参数
埋点SDK
为了简化业务同学开发埋点时的工作量，并对埋点日志进行一些必要的限制，需要统一的埋点SDK，目前需要2个端的SDK：微信小程序SDK、JS SDK
SDK包含的功能如下：
- 用户标识管理
- 设备信息、网络环境、业务环境自动收集
- 事件上报生命周期管理（上报机制）
- 兼容性处理
- ......
数据存储
日志经过「数据采集」「数据加工」「数据存储」这三个阶段，在每个阶段后，产生的数据，从类别、存储介质、保存时间上是有区别的。
数据收集架构设计
- 各种端的SDK监控用户行为，通过Http请求上报给日志收集服务
- 日志收集服务，把原始数据写到硬盘，并进行归档操作
- 通过Filebeat + Logstash转发到Kafka内（主要是为了在高并发下，利用队列模式降低IO）
- 日志ETL服务，针对原始数据进行分析和相关数据补全，存储到MySQL，形成中间层数据
- 日志分析服务，针对业务，进行数据分析，形成分析结果数据
- WEB UI针对分析结果数据进行相应的报表展现
未来阶段
数据量
由于目前SaaS平台的数据量不大，数据的ETL、存储等等，采取了经济、简单方案，在后面数据量升级后，ETL可以采用Hive、Spark、Flink等等大数据解决方案，存储可以采用分布式大数据存储方案，HDFS等等。
大数据测试
当埋点较多、端类型比较多时，为了便于QA进行埋点测试，需要针对QA的测试方案，进行自动化大数据测试流程的设计和实现，保证埋点数据的准确。
