背景介绍
在传统数据仓库方面，通常以T+1离线批量计算为主，按照数仓建模方式，把要处理的业务按照主题域划分，构建各种数据模型，来满足公司经营分析，财务分析等各种公司管理层的数据需求。
然而，随着在线教育快速发展市场竞争非常激烈，T+1的方式在某些需求上很难对业务产生实际的价值，很可能因为数据延迟导致业务动作滞后，管理要求跟进不及时，最终导致客户流失，影响公司业务发展。
目前我们遇到的主要痛点如下：
续费业务场景：在线教育上课主要分为4个时段（春季，暑假，秋季，寒假）。当每一个时段上课要结束的时候，就会有一个续费周期，每个学科每个班级续费率的高低直接影响公司是否盈利的问题。所以实时的观测每个学科每个班级每个学科负责人每个教学负责人的续费率完成情况就显得尤为重要。
直播行课场景：分析课中学员与老师互动行为，其中包含实时的连麦、发言、红包等行为数据，同时分析学员实时到课、完课、考试等数据对于管理学员和调整老师动作有重要的指导意义。
销售场景：监控新线索的实时分配，以及后续销售外呼频次、外呼时长，统计销售线索覆盖量，外呼覆盖量等指标。通过分析销售对于学员的跟进与转化数据，对比个人和团队当日人次和金额达成目标，指导运营管理动作。
算法线索分场景：每当进行广告投放的时候，针对每一个销售线索给出一个评分值，来评估这个线索可能转化的高低，利于销售人员更好的跟进，提高转化率。
实时数仓技术架构
01实时数仓选型
在年以前公司实时数据部分，主要由小时级和分钟级的支持。小时级部分使用基于Hive/Spark的小时级任务方案，分钟级使用Spark-Streaming方案。
基于Hive/Spark小时级方案虽然能满足快速响应业务需求和变化的特点，但延迟性还是很高，并且大量的小时任务对集群计算资源有很大压力，很有可能导致这一批小时任务根本跑不完。
分钟级Spark-Streaming方案，能够满足数据时效性需求，但采用纯代码方式来开发，无法满足快速变化的数据需求
基于此，我们开始调研业界方案，目前业界有主要有两种实时数仓方案，分别是实时数仓方案和准实时数仓方案。
02实时数仓方案
实时数仓方案分别可以采用Lambda架构和Kappa架构。
Lambda架构
如上图所示例，Lambda架构存在离线和实时两条链路，实时部分以消息队列的方式实时增量消费，一般以Flink和Kafka的组合实现，维度表存在MySQL数据库或者Hbase；离线部分一般采用T+1周期调度分析历史存量数据，每天凌晨产出，更新覆盖前一天的结果数据，计算引擎通常会选择Hive，优点是数据准确度高，出错后容易修复数据；缺点是架构复杂，运维成本高。
Kappa架构
Kappa架构是由LinkedIn的JayKreps提出的（参考Paper: