共计 5360 个字符，预计需要花费 14 分钟才能阅读完成。
好将来（NYSE：TAL）是一家以智慧教育和开放平台为主体，以素质教育和课外辅导为载体，在寰球范畴内服务公办教育，助力民办教育，摸索将来教育新模式的科技教育公司。截至 2020 年 11 月底，好将来在 102 个城市建设起 990 个教学点，业务范围覆盖全国 331 个地级市以及海内 20 多个国家和地区。
随着业务的倒退，实时数据的剖析需要日益增多，尤其在营销举荐、归因剖析、业务辅助决策等场景下，实时数据分析所带来的效益晋升是离线数据所不能比较的。在这些业务场景的驱动下，好将来抉择了 StarRocks 来撑持实时数据的剖析利用。实现了数据秒级查问响应能力，构建了一个对立 & 疾速 & 高效 & 灵便的实时数仓。
“作者：王岳，
好将来数据迷信组负责人，专一于数仓建设、数据分析、算法等畛域钻研。”
业务背景
业务场景分类
在教育场景下，依据数据时效性划分，数据分析解决可分为离线和实时两大部分：
离线
离线数据以 8 大数据域（日志、营销、交易、服务、教学、内容、学习、画像）建设为主，次要解决外围历史数据，解决“业务经营、分析师、算法”等海量数据多维度剖析和开掘等，采纳批处理的形式定时计算。
实时
实时数据分析解决，次要包含由埋点产生的各种日志数据，数据量大，以结构化或半结构化类型为主；另外还包含由业务交易产生的业务数据，通常应用数据库的 Binlog 获取。
实时数据分析的需要越来越多，特地是在营销签单业务和在读学员是否续报等场景，须要实时数据来助力业务营销付费和续费指标达成。当指标没实现时，业务经营须要对数据进行多维度剖析，找到起因，并疾速做出决策调整等治理动作。
业务痛点
T+ 1 的离线数据分析曾经无奈满足业务对时效性的需要，咱们心愿建设实时数仓来反对业务实时数据分析场景，解决如下痛点：
- 市场：想通过广告页投放策略，洞悉 PV、UV 等流量数据，如果出现异常，可疾速剖析和优化。但之前因为各种因素咱们无奈提供实时数据，对于业务来说 T + 1 数据时效性滞后，参考价值无限。
- 销售：通过剖析动向用户跟进和签单数据，依据当日销售指标，及时发现还有哪些治理动作须要优化。但目前是提供滞后数据，每日签多少单都通过人来统计，剖析也是通过历史数据，剖析成果很差。
- 在读学员续报：实时观测哪些学员续报了，老师须要做哪些续报动作。
- 课堂行为剖析：剖析课堂实时互动行为、答题行为等，阶段评测报告、课堂品质等。
- 算法模型：实时更新模型须要的特色数据，更准时的预测模型成果。
实时数仓指标
数据团队要提供灵便 & 丰盛的分钟级的实时数据，并要保证数据的丰富性 & 准确性 & 及时性等。
丰富性
沿用离线数仓建模好的数据维度和指标，保障离线能用到的，实时也能用到。
准确性
实时指标的构建须要能够保障数据完整性和准确性。所有指标开发依照指标定义文档，线上应用 DQC 平台来监控数据准确性，实时发送异样数据等。
及时性
要保证数据的“陈腐”度，线上实时产生的业务数据和日志数据，要能及时地被用于数据分析，晋升一线人员或业务的反馈速度。
实时数仓技术架构演进
实时数仓的摸索过程中，咱们先后经验了如下几个阶段：
- 2018 年~2019 年，基于 Hive 框架下的小时级任务计划；
- 2019 年，基于 Flink+Kudu 的实时计算计划；
- 2020 年至今，基于 StarRocks 的实时数仓技术架构。
基于 Hive
在原有天级提早的离线数据处理工作根底上，开发小时级提早的数据处理链路，将外围数据按小时同步到 Hive 数仓中，每小时调度一次 DAG 工作，实现小时级任务计算。工作 DAG 示意图如下所示：
长处 ：
- 离线和小时级任务各自独立
- 代码逻辑复用性高，缩小开发成本
- 能够应用离线数据笼罩小时级数据，进行数据修复
毛病 ：
- 小时级数据的提早性还是很高，已无奈满足业务对数据时效性的要求
- MapRecude 不适宜分钟级频次的任务调度，次要是 MapReduce 工作启动慢，另外会过高的频次会产生很多小文件，影响 HDFS 的稳定性，以及 SQL on Hadoop 零碎的查问速度
- 批量数据处理每次运行对资源要求高，尤其是当凌晨 Hadoop 资源缓和时，工作常常无奈失去调度，提早重大
基于 Flink+Kudu
为了解决下面基于 MapReduce 小时级任务的问题，咱们采纳了流式解决零碎 Flink 和反对增量更新的存储系统 Kudu。
如上图所示，实时的日志数据通过 Flume 采集到 Kafka，实时的业务数据通过 canal 实时同步数据库的 binlog 再转发到 Kafka 中，Flink 再实时生产 Kafka 中的数据写入 Kudu 中。
在应用 Flink+Kudu 的实际中，咱们遇到了如下几个问题：
- Flink 基于 stream 语义，做简单指标计算非常复杂，门槛高，开发效率不高，数据仓库更多应用批处理 SQL
- Kudu+Impala 聚合查问效率不高，查问响应工夫不能满足业务多维分析要求
- 应用 Kudu 须要依赖 Impala、Hive 等整个 Hadoop 组件，保护老本太高
- Kudu 社区不沉闷，遇到问题很难找到相干解决方案，应用过程中遇到过宕机等各类疑难问题
基于 StarRocks
基于下面计划的问题，咱们开始对实时数仓进行调研，包含 StarRocks、ClickHouse、Kylin 等零碎，思考到查问性能、社区倒退、运维老本等多种因素，咱们最初抉择 StarRocks 作为咱们的实时数仓，各零碎的比照总结如下：
咱们也深刻思考过 ClickHouse，对于教育场景，一个学员要关联的数据维度多，包含课堂、服务、订单、教研等。在每个主题咱们都会建设灵便且易用的星型数据模型。当业务想进行个性化自助剖析时，仅须要关联相干表即可。但如果间接构建明细大宽表，随着业务一直调整，常常须要重构开发。这种状况下，ClickHouse 的 join 能力弱，无奈满足需要，而 StarRocks 强悍的 Join 能力，就成了咱们应答业务变动的利器。而且 StarRocks 反对 CBO（基于老本统计的优化器），具备简单查问的优化能力，从而能够疾速的进行简单实时微批处理工作，能够帮忙咱们更好的进行实时指标构建。
最终抉择 StarRocks 的起因：
- 应用 StarRocks 能够让咱们像开发离线 Hive 工作一样进行实时数仓的开发，防止了简单的 Flink stream 语义，同时也能在性能上对齐离线指标，保障指标丰富性的根底上实现指标定义口径的统一，并且能够保障分钟级的数据可见性。
- 大宽表和星型模型的查问性能都很好，能够灵便高效的满足各类业务剖析要求。
- StarRocks 简略易用，运维治理成本低
基于 StarRocks 的实时数仓架构
零碎搭建
整个零碎，除了 StarRocks 集群之外，咱们还搭建了上面两个配套零碎
- 调度：应用 Airflow，进行 DAG 任务调度
- 监控：应用 grafana+prometheus，采集 StarRocks 信息并进行实时监控
实时数仓总体架构
基于 StarRocks 的实时数仓总体架构，次要包含上面三个局部：
数据源 ：业务数据（应用 Flink 实时同步 mysql 的 binlog 日志，写入到 Kafka）、日志数据（包含 H5 小程序、APP、直播 ipad 客户端等埋点采集的各类日志数据，通过 Flume 写入到 Kafka 中）
数据存储 ：
- 采纳 StarRocks 的 Routine Load 间接生产 Kafka 中的日志和业务数据
- 应用 StarRocks 的 Broker Load 将 Hadoop 中的 DWD、DWS、ADS 等数据导入到 StarRocks 中
- 对于 Flink 等流式解决下零碎，应用 StarRocks 的 Stream Load 形式实时将数据导入 StarRocks
数据利用 ：
- 应用 DataX 能够将 StarRocks 数据导出到 MySQL 中
- 应用 StarRocks 的 Export 能够将 StarRocks 中的数据导出到 HDFS 中
- StarRocks 齐全兼容 Mysql 协定，BI 或业务零碎能够应用 Mysql Connector 间接连贯 StarRocks 进行应用
实时数仓数据处理流程
在实时数仓外部，也是依照传统离线数仓的形式，对数据处理进行分层解决：
- ODS 层，设置 StarRocks 的 Routine Load 距离 30 秒生产一次 Kafka 数，写入到 ODS 表中
- DWD 层，按业务剖析的须要建模 DWD 表，通过 Airflow 距离 5 分钟，将 ODS 表中过来 5 分钟的增量数据写入到 DWD 表中
- DWS 层，对 DWD 表中的维度进行轻度或中度汇总，能够放慢下层查问速度
- BI 层，通过自研的一个指标定义工具，剖析人员能够疾速的基于 DWS 构建报表，也能够衍生出一些复合指标进行二次加工。分析师也能够将取数口径中的 SQL 做长期批改，生成一个简单跨主题查问 SQL，来应答一些 Adhoc 需要场景。
StarRocks 实时数仓具体利用
在好将来，为保障课堂上课数据、订单数据的实时剖析要求，应用 StarRocks 撑持了课堂、订单等剖析业务。上面以课堂、订单场景为例，从数据同步、数据加工等几个步骤拆解 StarRocks 在好将来利用场景的落地计划。
实时数据同步
在好将来，采纳 flink 采集业务库的 binlog 数据，而后写入到 kafka 中，StarRocks 只须要生产 kafka 对应的 topic 数据即可，整体流程如下图：
实时数仓数据处理
StarRocks 外部的实时数据加工解决次要有如下操作：
- 缩短计算链路的长度，实时局部最多计算 2 层。dwd 或 dws 层
- 增量计算，采纳 StarRocks 的 UNIQUE KEY 模型，相当于 (insert + update)，因而只计算增量局部即可
- 采纳工夫分区，多正本策略。既为了数据安全，又能防止锁表
- 离线表构造与实时表构造，放弃一样，这样就能够用离线修复 T + 1 数据
DAG 任务调度
为了使 StarRocks 能在 airflow 上执行，咱们封装了 airflow 调用 StarRocks 执行 sql 的算子，以便 StarRocks 的加工逻辑在 airflow 上被定时调度。
StarRocks 工作执行状态的查看，因为不像 T + 1，只须要判断昨天工作是否执行就行了，实时查看须要满足以下条件：
- 查看轮询距离，须要依据不同的调度距离，适当调整
- 查看轮询总时长，不能超过 (调度距离时长 -10 秒)
- 查看的范畴，最小须要大于调度距离，最大小于 2 倍的调度距离
依据以上的实时调度查看条件，咱们封装了基于 StarRocks 的实时调度的工作查看 airflow 算子，方便使用。
实时数据生产预警
为了监控 StarRocks 的实时数据生产状况，咱们设置了三种预警：
1、查看 StarRocks 生产 Kafka 的工作，是否停掉了，如果停掉主动重启，重启 3 次仍然失败，再发告诉，人为干涉
2、查看惯例工作的执行，如果执行报错，就发告诉。
3、查看数据源与 StarRocks 实时数仓 ods 层表，schema 的比照，如果呈现 schema 变更，就发告诉人为干涉。这样咱们就能在白天实时理解 schema 的变更状况，不必要等到调度报错才发现，而且不影响线上数据产出。
StarRocks 应用成果
晋升业务收益
StarRocks 在泛滥场景给业务带来了间接收益，尤其是 StarRocks 的实时数据与算法模型相结合的场景。比方教育的获客、转化、用户续报等业务，之前模型须要特色数据都是前一天的，所以模型也绝对滞后。而咱们通过大量数据分析得出结论：是当日行为和跟进数据，是最有价值的特色数据，这样模型成果较好。特地是动向用户辨认模型，成为线索当天的历史积攒数据的特色和前一天的历史积攒数据的特色，别离训练模型后，线上理论预测成果相差 2 - 3 个百分点，AUC 0.752 和 AUC 0.721 的差异，所以，当天的特色模型成果特地显著。
升高应用老本
- 用简略的 SQL 语义代替 Stream 语义实现实时数仓的开发，大大降低了开发的复杂度和工夫老本，同时可能保障和离线指标的一致性。
- 联合应用宽表模型和星型模型，宽表和物化视图能够保障报表性能和并发能力，星型模型能够保证系统的查问灵活性，在一套零碎中满足不同场景的剖析需要。另外，明细表查问咱们通过 StarRocks 表面的形式裸露查问，晋升了查问的速度，大大降低了业务方的老本。StarRocks 的分布式 Join 能力十分强，原来一些须要查问多个 Index 在从内存中计算的逻辑能够间接下推到 StarRocks 中，升高了原有计划的复杂度，晋升了查问服务的稳定性，放慢了响应工夫。
- BI 报表迁徙成本低，咱们后期 BI 可视化是基于 Mysql 构建的，某些看板一直优化和丰盛需要后，加上多维度灵便条件筛选，每次加载超级慢，业务无奈承受，当同样数据同步到 StarRocks 上后，咱们仅须要批改数据源链接信息，SQL 逻辑不必批改（这个超级爽，迁徙老本超级低），查问性能间接晋升 10 倍以上。
- 运维成本低，绝对其余大数据组件来说，StarRocks 只须要部署一种即可满足各类数据分析需要，不须要其他软件辅助，而且部署运维简略。
将来瞻望
StarRocks 作为新一代 MPP 数据库的引领者，以后在多种场景下性能都十分优良，帮忙咱们十分好的重构了实时数仓。目前 StarRocks 高效的反对了实时指标的计算，以及业务方在实时场景下的数据灵便探查和多维分析需要。StarRocks 在团体外部各个业务线的利用越来越多，咱们也将推动实时和离线数据分析进行对立，为业务剖析提供更好的撑持。后继咱们将分享更多 StarRocks 的成功实践。最初，感激鼎石科技的大力支持！
