大数据从0到1构建
开始
虽然神往hadoop,大数据等名词许久,但一直没有机会实操,一是数据量实在太小,另外自己兴趣广泛,做着做着就容易做偏,于是走走停停,一直没有一个合适的机会。最近,我司正在如火如荼的进行着内部创业,人人岌岌可危,于是,身为后端的我,想找一个切入点,来展示一番自己的才能,于是就选择了这个赛道,原因一是兴趣,另外就是数据这个东西比较玄幻,讲故事最佳;
启动
说干就干,其实本身来说,这个事也比较简单,简单到无非就是用大数据的方式做一件非常low的事。我们的数据量也不大,来源也不多,无非就是一些语音交互的访问日志。一天也就几十万条数据而已。所以,这个数据及体量虽然对大数据系统来说有点杀鸡用牛刀的意思,但是对于个人和team来说,也足够干一阵子了。
环境
一旦说到大数据,上来就是hadoop,mapreduce,kafka,yarn,storm,zookeeper,光听这些名词就足以让你放弃。每个组件还都有安装、维护一大堆头疼的事。(我司没有运维)于是乎找了一个现成的方案,买云服务,单位买的某为云的mrs服务正好空闲中,里面各种工具一应俱全;这样,可以省去很多麻烦的安装环节。
但是,虽然看似选用云服务简单,实际上这种云服务对于代码的侵入导致的集成工作量,一点不亚于你安装并写一套服务;
1)版本不兼容;
2)文档不合理;
3)繁琐的东西太多
拿某为的一个基础款的mrs服务来说,甭管你用不用,storm,YUE等等一并都会安装,否则你就只能选择只带kafka服务的其他都没有的服务,这种绑定,从商家的角度来说,可能提升了自己的收益,但有多少人会真正的去用到这些所有的服务呢。
版本问题:尤其是对于kafka这一类的服务,巨挑版本,我司其他部门的同事,之前在客户现场部署服务的时候就遇到了一个问题,开发的时候自己选择了storm,但客户环境中不提供,需要自己安装,代码在某为云上测试成功,但是到了客户现场就不好使,最后发现kafka版本不兼容,客户不提供kafka升级,最后此事悬而未决,不知道怎么解决的。我们在部署的过程中也碰到了类似的问题,hadoop等版本也不兼容,最后都得自己填坑;
文档不合理:一般你选择了一个云服务,那么出现问题时,这种问题也都是这个系统独有的,比如说,某为云在安装客户端到本地时,集成了kerberos认证,出现问题时,不仅仅是shell不好使,因为所有的连接服务都要连接kerberos,尤其是我们的主要code program是python的情况下,更复杂。而这种问题,连百度都找不到问题答案;我在部署的过程中碰到了,某为云,首先得在系统中配置账户权限,选分组,最后下载客户端,但是,他的权限不是实时生效的,导致,你配置完成了,操作步骤也都OK,但是权限就是不生效,有时居然会出现一天中有一点时间是好的,其他时间不好使的问题。最后,都治好派工单给他们工程师,其实,我看了他们的操作步骤,也并没有什么特别之处。一句话,多试几次,总会成功;同时,也建议,按照官方网站的操作,一步步的执行;
User=hive的问题总结:
1)有可能是由于本地没有初始化kinit的问题;但不能解释为什么beeline也不能用的问题;
2)服务端加的用户生效时间比较长;所以,在测试的时候不行。因为今天操作最大的一个动作就是将某个用户加入了super组;
kerberos基本信息介绍:
https://www.cnblogs.com/xiaonq/p/10598280.html
hive导入数据:
https://www.cnblogs.com/airnew/p/9752342.html
#MRS问题最终是由于配置文件处理不当导致的;
https://support.huaweicloud.com/usermanual-mrs/mrs_01_0089.html
应用
我们的应用比较简单,就是每天,A系统会将文件打包成zip包供我们下载,我们的程序把它拉取到本地,做清洗,然后导入到hive,最后,再通过各种分析语句,从hive中汇总读取数据到mysql,再经过grafana展示出来。
过程不算很复杂,主要碰到的问题集中在我们的program都是python,而大数据这堆东西天生就对python不是很友好,某为的python帮助文档就跟闹着玩似的,简单的令人发指。而且对于,最复杂的kerberos认证,他们居然选择了调用shell来处理。看来大家都很头疼吧。
于是,我选择了一条奇径,我写一个java的程序,接送udp命令,然后,由java来执行hive语句。
对于数据从hive到mysql,也如法炮制。经过这种转换,开发效率提升好几倍,性能下降估计好几十倍。????不过好在这个系统一开始定位是一个离线分析系统,性能过的去就行。也就不在乎这些了。
这里面碰到最多的问题就是 python如何连接kerberos的某为云服务,python自己就有N多个版本,很多库都只支持python2,不支持python3,基本上没有一个库可以正常使用;
某为云官方的代码,是使用zkCli.sh来获取server,然后再调用服务,当然了,最终,即使我使用了官方的代码,也无法查询成功,主要还是出在kerberos上。不过,最终,我使用java绕过之后,也就没有再继续深究这个原因。所以,“人生苦短,我用python“ ,在大数据环境中不适用。
展示
绕过kerberos后,所面临的问题就是一马平川了,都是成熟方案,于是,很快的,一个数据大屏就做出来了。
因为担心泄密,整体上就不截图了。
番外问题
数据清洗的过程中还是碰到了一些问题的:
1)数据字段很多,而且,有些格式里面还嵌套这xml,json,导入到hive时有些字段会乱;
对于这种问题,我倒是没有刻意去解决,直接将数据转换成字符串,硬放进去了, 不过也带来了后续的很多麻烦,比如说,一些检索,这类字段无法使用等;这个问题后面再深入分析吧;
2)经纬度地址不全;我们的数据有些有经纬度,有些有IP,有些只有地址,没有经纬度,数据质量很差,为此,申请了一个高德的API,用来做这些转换。(由此引发了一场新的技术话题,原本的方案是想,将经纬度获取到的地址缓存下来,这样后续就不用再继续去调用高德了,节省宝贵的免费资源,但是,突然想到了,经纬度和地址在高德是如何存储的,于是又引发了一场其他的技术大讨论,为此,不得不求助于CSDN架构师群,得到了满意的答案,当然,也超出我们目前的执行范畴,所以,也就只是学习了一下,没有深究)
说到Image Server,不能不提ArcGIS Enterprise:
地图数据存储:
https://blog.csdn.net/u012599377/article/details/81350402?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task
GEO HASH
https://www.graphhopper.com/blog/2012/05/23/spatial-keys-memory-efficient-geohashes/
栅格化处理
https://docs.microsoft.com/en-us/bingmaps/articles/bing-maps-tile-system
墨卡托投影的问题是每个栅格的面积不一样,所以我们后期放弃了墨卡托投影,改成基于球面投影计算栅格
分享几个碰到的讲的比较明白的网站吧。
3)数据的分析和存储
我们碰到的问题是,数据在mysql里的存在形态?如果mysql里的数据集粒度过粗,会导致报表展示效果不好,粒度过细,数据量又很大,而且,和hive里的数据也有很大的重复。
解决方案是,mysql里的数据尽可能的细粒度,数据还是,从hive抽取到mysql里吧,后面如果有数据汇总等还是优先从mysql里进行数据抽取;(不过后面再开发别的过程时好像还是直接从hive里获取的情况比较多,究其原因就是这样开发效率比较高吧,否则,还得从mysql里抽取数据,由多了一个环节。)
俗话说:一个人走的比较快,一堆人走的比较远,大概就是这个意思吧,这种架构,也就是在现阶段临时解决一下,后面还需要提升;
附上最基本的架构图,为一期做个总结;
下一阶段:流式计算;
上一篇: oEmbed和WordPress简介