大数据从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里抽取数据，由多了一个环节。）
俗话说：一个人走的比较快，一堆人走的比较远，大概就是这个意思吧，这种架构，也就是在现阶段临时解决一下，后面还需要提升；

附上最基本的架构图，为一期做个总结；

下一阶段：流式计算；