kettle同步数据到hive 巨慢_一不小心做了个大数据中台(1)

比眉伴天荒 2023-01-01 09:53 120阅读 0赞

0 1业务背景

即将火爆到起飞的教育行业，还是ToB的

曾经有一份工作，我有幸接触到，做的是教育行业，而且是ToB的。

大数据、教育、ToB，三个风口啊，别说猪了，铅球都能飞起来了。

不过，这次不是聊八卦了，而是要说技术内容了。

所谓的教育ToB，说成是多媒体教学系统就很好理解了。

客户主要是学校或教育单位，用户以老师和学生为主。

将老师的课堂讲解、布置作业、学生答题、成绩统计等全部在线上，并提供一些数据分析、电子阅卷等辅助功能；

同时，还有一个相对薄弱的学生家长端，主要是可以查看学生成绩、学习情况、购买一些练习等。

额外说一句，现在教育成本还真是越来越来高了，老师经常发给学生一个pdf，就是作业了，让学生自己想办法打印，做完再交回去，我看到很多打印店都推出了会员业务。

0 2技术背景

教师端

教师端是一个独立的业务系统，是很标准的一个web项目，前后端分离，数据库是mysql。

最关键的3个业务场景是教师出卷(一份作业或一份试卷，统一被认为是一份试卷)，学生作答，教师阅卷。

数据中心

使用sqoop工具，每天0点开始，将前一天的数据从mysql同步到hdfs，结合Hive做数据处理。调度工具是kettle，对，你没看错，就是kettle。

0 3统计应用

业务报表

对于ToB的业务来说，在这一点跟ToC没有太大区别，也很关心用户活跃的情况。如：

新增客户学校，累计学校数，有出卷的学校，有考试的学校...

新增教师用户，累计教师用户，有出卷的教师，有阅卷的教师...

新增学生用户，累计学生用户，学生答题情况...

离线计算

这个场景是数据团队最常见的场景了，每天离线将业务系统的数据拉到hive中，然后由hive sql分层进行计算，最后再把数据推回到关系型数据库。

这里有个奇葩点，业务系统的数据库是mysql，但是报表数据库是pgsql。

业务系统的统计功能

作为一个多媒体教学服务，而且这都2020年了，没点数据统计就说不过去了；不跟大数据沾边，还怎么好意思说自己是互联网公司。

综上，我接手项目和团队的时候，有3大类问题要解决:

日常的教学统计

1、教师阅完券后，要能及时看到全班同学的成绩统计，如排名、成绩统计、知识点得分情况等。

2、不同班级用同一张试卷，在不同时间考试后，阅卷结束后要能更新大排名，比如年级排名等。

3、其他跟教学直接相关的日常统计。

数据应用产品

1、我们会主动提供一些练习券或练习题，供教师出卷使用。这些试卷、试题，在用户体验方面需要提供被不同学校使用的次数，以及正确率等。

2、试题搜索功能，教师在出题时，可以根据知识点、题干内容等，作为条件，搜索试题。

3、增值数据产品，如把学生最近一周做错过的习题进行汇总，可再次练习，并根据知识点和提醒提供增强练习题。

4、其他数据应用产品。

数据服务

1、对外合作的数据服务接口。如：获取某个学校某场考试的成绩统计等。

2、为一些开放给学校的数据报表，提供数据查询的接口。

3、其他服务等。

0 4问题爆发

上面说的是要解决的问题，那为什么是问题呢？下面阐述每一个问题的爆发点：

日常教学统计

业务量增加，系统不看重负

原本的计算方式是在教师阅完一次考试的全部试卷后，触发java程序应用，用java程序+sql的方式，在线进行一次相关的排名之类的计算，大概耗时几十秒，然后把结果写到mysql的结果表中。

其中的计算程序转过几次手，非常复杂，算个全班排名的java代码也要几百行。

随着用户的增多，以及在月考、期中考这种业务高峰，系统临时扩容已经不能解决问题了。

再结合其他一些稍复杂的统计，数据库不仅频繁出现慢sql，系统资源的使用率也经常无故飙升。

辅助性数据

mysql→hive→多个sql处理→ElasticSearch→教师系统后端

问题是从一些试卷，在暑假期间，显示被使用了几千次开始。用户严重怀疑数据的真实性。内部排查，发现很多其他辅助性统计，数据都不准确。

可是，我们的数据处理方式是：

从mysql拉取业务数据，包括试卷的被使用情况；

数据进入hive库中；

在hive中经过几个复杂sql的处理；

数据推送到ElasticSearch(下面简称ES)中；

教师系统后端根据业务逻辑查询。

从查询hive中的数据就要陷入绝境，几个业务场景数据处理写在了一起，写的人已经不在了，后人无从查起，导致一个试卷使用次数的简单逻辑，都无法从sql中总结出来。

经过了好几天，计算逻辑好不容易查明白了，发现hive结果表的数据，跟ES中的数据量竟然都是不一致的，不能轻易改数据...。

搜索功能

只是按照题干搜索一下试题，但因为搜索两个字，ES又上场了。扩充一次搜索题库，要几天的工作量

教师在出题的时候，为了方便，经常会根据知识点或题干在系统中直接搜索一些试题，然后引用到自己的试卷中，这样比较方便。

为了适配这个场景，当时系统结构这样做的：

通过购买、人工录入等方式，先准备好大量的试题原题；

试题转换成文件的形式(题干、答案、解析保存的是html路径)，录入到hive中；

hive把数据推送到es中。

在这样的结构下，如果要扩充题库，必须有一个熟悉流程的人，认真处理至少两天才可以。

搜索场景有两个，根据知识点直接搜索试题，由于知识点是有限的，系统有相应的码值表，其实这就是一个等值查询；

根据关键词模糊匹配题干内容，这里用户输入的是最短关键词了，没必要进行分词，因为分词后搜索结果基本就不是老师想要的了，而且老师在出卷，那么根据年级和科目的知识点，可以把试题范围缩小很多，这就转化成了一个sql的like查询。

数据服务

明明都是等值条件式的查询，又双叒上ES了

数据服务，场景想象一下都不复杂，按日期查询考试情况，按考试查询学生得分情况。

现状竟然又是在hive处理数据，然后把数据推送到了ES中，而且还是多个索引，导致hive中100G不到的数据，在ES中，因为倒排索引的关系，占用了1T的硬盘空间。

如果需求方想在返回结果加个字段或者改个字段，工期需要一周，对方对这个效率表示惊讶。

0 5运用合理的方案，事半功倍搜索的存储迁移到mysql  引入presto查询框业务系统修改部分逻辑 ![42b83850ae4c38fd03f195a403c9ffda.png][]数据服务查询使用prestohive数仓迭代式重构

业务系统启用消息队列

业务系统修改原有的数据都是存到表中的，且是三范式的。需要将数据以面向统计的结构实时写入到kafka中，kafka数据以分钟频率写到hdfs。

在大数据集群中部署presto准实时查询引擎。

将教师在线统计，迁移到jdbc发送presto sql查询hive数据。原本的在线统计就要几十秒甚至几分钟，且程序复杂。迁移到presto后，查询只要几秒，由于结构也有优化，统计sql清晰明了。

很多数据的不准确，跟数仓的逻辑混乱有很大关系，hive中的逻辑处理要迭代式更新(后面会详细说明)。

在业务系统的mysql新建数据库，用于存放数据系统推送过去的数据，为搜索服务。

修改数据服务的java代码，直接通过jdbc连接presto，直接查询hive的数据。由于是合作的业务获取场景，且数据量不大，单个查询的时间仍小于1s。

我被“逼”创业了系列

更多内容近期更新，避免走丢，请点关注呦！

[42b83850ae4c38fd03f195a403c9ffda.png]: /images/20221120/db0f595421764bd895ea6aff788914d0.png

kettle同步数据到hive 巨慢_一不小心做了个大数据中台(1)

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关大数据_数据中台_数据分层

相关大数据NiFi（二十）：实时同步MySQL数据到Hive

相关 Kettle-excel数据同步

相关 kettle 同步表数据

相关大数据技术之kettle（1）——安装

相关 Kettle连接Phoenix从Oracle同步数据到Phoenix大数据平台一些问题记录

相关 hive到mysql数据同步_datax实战-hive同步数据到mysql

相关 kettle同步数据到hive 巨慢_一不小心做了个大数据中台(1)

相关大数据中台

相关 kettle数据同步的5中方案