好将来（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的成功实践。最初，感激鼎石科技的大力支持！