【原创】SZT-bigdata 深圳地铁大数据客流分析系统 🚇🚇🚇开源了-v0.12

   ___     ____   _____           _         _      __ _      _             _
  / __|   |_  /  |_   _|   ___   | |__     (_)    / _` |  __| |   __ _    | |_    __ _
  \__ \    / /     | |    |___|  | '_ \    | |    \__, | / _` |  / _` |   |  _|  / _` |
  |___/   /___|   _|_|_   _____  |_.__/   _|_|_   |___/  \__,_|  \__,_|   _\__|  \__,_|
_|"""""|_|"""""|_|"""""|_|     |_|"""""|_|"""""|_|"""""|_|"""""|_|"""""|_|"""""|_|"""""|
"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'

项目说明🚩：

🎈 该项目主要分析深圳通刷卡数据，通过大数据技术角度来研究深圳地铁客运能力，探索深圳地铁优化服务的方向；
✨ 强调学以致用，本项目的原则是尽可能使用较多的常用技术框架，加深对各技术栈的理解和运用，在使用过程中体验各框架的差异和优劣，为以后的项目开发技术选型做基础；
👑 解决同一个问题，可能有多种技术实现，实际的企业开发应当遵守最佳实践原则；
🎉 学习过程优先选择较新的软件版本，因为新版踩坑一定比老版更多，坑踩的多了，技能也就提高了，遇到新问题可以见招拆招、对症下药；
🚀 ...

核心技术栈 + 版本选择 + 点评 (持续更新)⚡：

Java-1.8/Scala-2.11，生态丰富，轮子够多；
Flink-1.10，流式业务、ETL 首选。发展势头如日中天，阿里巴巴背书，轻快灵活、健步如飞；就问你信不信马云？？？😚😚😚
Redis-3.2，天然去重，自动排序，除了快还是快。廉价版硬盘实现同类产品 SSDB。Win10|CentOS7|Docker Redis-3.2 三选一，CentOS REPL yum 安装默认使用3.2版本；
Kafka-2.1，消息队列业务解耦、流量消峰、订阅发布场景首选。最佳 CP：kafka-eagle-1.4.5，集生产、消费、Ksql、大屏、监控、报警于一身，同时监控 zk。其他我用过的 Kafka 监控组件最后都放弃了：
- KafkaOffsetMonitor 问题太多，丑拒；
- Kafka Manager，已更名为 CMAK，老外写的软件用起来就觉得很别扭，而且最高只兼容 Kafka 0.11，但是 Kafka 官方已经升级到 2.4 了啊喂；
- 其他各种开源的 Kafka 监控基本都试过，一个能打的都没有。
Zookeeper-3.4.5，集群基础依赖，选举时 ID 越大越优势，通过会话机制维护各组件在线状态；
CDH-6.2，解决了程序员最难搞的软件兼容性问题，全家桶服务一键安装；
Docker-19，最快速度部署一款新软件，无侵入、无污染、快速扩容、服务打包。如果当前没有合适的运行环境，那么 docker 一定是首选；
SpringBoot-2.13，通用 JAVA 生态，敏捷开发必备；
knife4j-2.0，前身为 swagger-bootstrap-ui，REST API 项目调试简直不要太方便，秒杀原版丝袜哥十个数量级；
Elasticsearch-7，全文检索领域唯一靠谱的数据库，搜索引擎核心服务，亿级数据毫秒响应，真实时，坑也多🔊🔊🔊；
Kibana-7.4，ELK 全家桶成员，前端可视化，小白也不怕；
ClickHouse，目前资料还不多，正在学习中，就是觉得头皮有点凉😂😂😂；
MongoDB-4.0，文档数据库，对 Json 数据比较友好，主要用于爬虫数据库；
Spark-2.3，目前国内大数据框架实时微批处理、离线批处理主流方案。这个组件太吃资源了，曾经在我开发时，把我的笔记本搞到蓝屏，于是我直接远程提交到 spark 集群了。接下来预计 Flink 开始表演了🦘，真的用了更快的框架就爱上了😍😍😍；
Hive-2.1，Hadoop 生态数仓必备，大数据离线处理 OLAP 结构化数据库，准确来说是个 HQL 解析器，查询语法接近 Mysql，就是窗口函数比较复杂😭😭😭；
Impala-3.2，像羚羊一样轻快矫健，同样的 hive sql 复杂查询，impala 毫秒级返回，hive 却需要80秒左右甚至更多；
HBase-2.1 + Phoenix，Hadoop 生态下的非结构化数据库，HBase 的灵魂设计就是 rowkey 和多版本控制，凤凰嫁接 hbase 可以实现更复杂的业务；
Kylin-2.5，麒麟多维预分析系统，依赖内存快速计算，但是局限性有点多啊，适用于业务特别稳定，纬度固定少变的场景，渣渣机器就别试了，内存太小带不起；
HUE-4.3，CDH 全家桶赠送的，强调用户体验，操作数仓很方便，权限控制、hive + impala 查询、hdfs 文件管理、oozie 任务调度脚本编写全靠他了；
阿里巴巴 DataX，异构数据源同步工具，主持大部分主流数据库，甚至可以自己开发插件，马云家的东西，我选你！！！如果你觉得这还满足不了你的特殊业务需求，那么推荐你用 FlinkX，基于 Flink 的分布式数据同步工具。理论上你也可以自己开发插件；
Oozie-5.1，本身 UI 奇丑，但是配合 HUE 食用尚可接受，主要用来编写和运行任务调度脚本；
Sqoop-1.4，主要用来从 Mysql 导出业务数据到 HDFS 数仓，反过来也行；
Mysql-5.7，程序员都要用的吧，如果说全世界程序员都会用的语言，那一定是 SQL。Mysql 8.0 普及率不够高，MariaDB 暂不推荐，复杂的函数不兼容 Mysql，数据库这么基础的依赖组件出了问题你就哭吧；
Hadoop3.0（HDFS+Yarn），HDFS 是目前大数据领域最主流的分布式海量数据存储系统，这里的 Yarn 特指 hadoop 生态，主要用来分配集群资源，自带执行引擎 MR；
阿里巴巴 DataV 可视化展示；
...

我发现越来越多的国产开源软件用户体验值得肯定。。。

准备工作🍬：

以下是我的开发环境，仅作参考：

Win10 IDEA 2019.3 旗舰版，JAVA|Scala 开发必备，集万般功能于一身；
Win10 DBeaver 企业版 6.3，秒杀全宇宙所有数据库客户端，几乎一切常用数据库都可以连，选好驱动是关键；
Win10 Sublime Text3，地表最强轻量级编辑器，光速启动，无限量插件，主要用来编辑零散文件、markdown 实时预览、写前端特别友好（虽然我不擅长🖐🖐🖐），速度快到完全不用担心软件跟不上你的手速；
其他一些实用工具参考我的博客：https://java666.cn/#/AboutMe
CentOS7 CDH-6.2 集群，包含如下组件，对应的主机角色和配置如图，集群至少需要40 GB 总内存，才可以满足基本使用，不差钱的前提下，RAM 当然是合理范围内越大越好啦，鲁迅都说“天下武功唯快不破”；我们的追求是越快越好；

如果你选用原版 Apache 组件搭建大数据集群，那么你会有踩不完的坑。我的头发不够掉了，所以我选 CDH！！！⚙🛠😏😏😏

物理机配置💎：

以上软件分开部署在我的三台电脑上，Win10 笔记本 VMware + Win10 台式机 VMware + 古董笔记本 CentOS7。物理机全都配置 SSD + 千兆以太网卡，HDFS 需要最快的网卡。好马配好鞍，当然你得有个千兆交换机配合千兆网线，木桶原理警告！！！🎈🎈🎈
有个机架当然再好不过了，哈哈哈。。。
如果你想避免网线牵来牵去，可以采用电力猫实现分布式家庭组网方案；

数据源🌍：

深圳市政府数据开放平台，深圳通刷卡数据 133.7 万条【离线数据】， https://opendata.sz.gov.cn/data/api/toApiDetails/29200_00403601

理论上可以当作实时数据，但是这个接口响应太慢了，如果采用 kafka 队列方式，也可以模拟出实时效果。

本项目采用离线 + 实时思路多种方案处理。

开发进度🥇：

准备好 java、scala、大数据开发常用的环境，比如 IDEA、VMware 虚拟机、CDH等，然后手机静音盖上，跟我一起左手画个龙，右手划一道彩虹，开始表演吧🤪

1- 获取数据源的 appKey：https://opendata.sz.gov.cn/data/api/toApiDetails/29200_00403601

2- 调用 cn.java666.etlspringboot.source.SZTData#saveData 获取原始数据存盘 /tmp/szt-data/szt-data-page.jsons，核对数据量 1337，注意这里每条数据包含1000条子数据；

3- 调用 cn.java666.etlflink.sink.RedisSinkPageJson#main 实现 etl 清洗，去除重复数据，redis 天然去重排序，保证数据干净有序，跑完后核对 redis 数据量 1337。

4- redis 查询，redis-cli 登录后执行 hget szt:pageJson 1
或者 dbeaver 可视化查询：

5- cn.java666.etlspringboot.EtlSApp#main 启动后，也可以用 knife4j 在线调试 REST API：

6- cn.java666.etlflink.source.MyRedisSourceFun#run 清洗数据发现 133.7 万数据中，有小部分源数据字段数为9，缺少两个字段：station、car_no；丢弃脏数据。

合格源数据示例：

{
    "deal_date": "2018-08-31 21:15:55",
    "close_date": "2018-09-01 00:00:00",
    "card_no": "CBHGDEEJB",
    "deal_value": "0",
    "deal_type": "地铁入站",
    "company_name": "地铁五号线",
    "car_no": "IGT-104",
    "station": "布吉",
    "conn_mark": "0",
    "deal_money": "0",
    "equ_no": "263032104"
}

不合格的源数据示例：

{
    "deal_date": "2018-09-01 05:24:22",
    "close_date": "2018-09-01 00:00:00",
    "card_no": "HHAAABGEH",
    "deal_value": "0",
    "deal_type": "地铁入站",
    "company_name": "地铁一号线",
    "conn_mark": "0",
    "deal_money": "0",
    "equ_no": "268005140"
}

7- cn.java666.etlflink.app.Redis2Kafka#main 根据需求推送满足业务要求的源数据到 kafka，topic-flink-szt-all 保留了所有源数据 1337000 条， topic-flink-szt 仅包含清洗合格的源数据 1266039 条。

8- kafka-eagle 监控查看 topic，基于原版去掉了背景图，漂亮多了：

ksql 命令查询： select * from "topic-flink-szt" where "partition" in (0) limit 1000

9- cn.java666.etlflink.app.Redis2Csv#main 实现了 flink sink csv 格式文件，并且支持按天分块保存。

10- cn.java666.etlflink.app.Redis2ES#main 实现了 ES 存储源数据。实现实时全文检索，实时跟踪深圳通刷卡数据。

这个模块涉及技术细节比较多，如果没有 ES 使用经验，可以先做下功课，不然的话会很懵。

我之前在处理 ES 各种问题踩了不少坑，熬了不少通宵，掉了很多头发。

遇到问题心态要稳，因为你今天处理了一个问题，明天接触新的版本新的框架大概率又会出现新的问题。。🥺🥺🥺

所以最佳实践很重要！！！

👇👇👇这部分内容有更新：修正了上一个版本时区问题。

🎬接下来，让我们时光倒流，回到 2018-09-01这一天，调整 kibana 面板时间范围 2018-09-01 00:00:00.000~2018-09-01 23:59:59.999，看看当天深圳通刷卡记录的统计图曲线走向是否科学，间接验证数据源的完整性。

修正时区后统计数量，字段完整的合格源数据 1266039 条，2018-09-01全天 1229180 条。

图中可以看出 2018-09-01 这一天刷卡记录集中在上午6点~12点之间，早高峰数据比较吻合，虽然这一天是周六，高峰期不是特别明显。我们继续缩放 kibana 时间轴看看更详细的曲线：

回顾一下本项目 ETL 处理流程：

1337000 条源数据清洗去除字段不全的脏数据，剩余的合格数据条数 1266039 已经进入 ES 索引 szt-data

在 1266039 条合格数据中，有 1227234 条数据集中在 2018-09-01 这一天的上午时段；

我们暂且相信上午时段的数据是真实的，那么是否说明官方提供的数据并不是全部的当天完整刷卡数据？？？

如果按照上午的刷卡量来估测全天的刷卡量，考虑到是周六，那么深圳通全天的刷卡记录数据应该在 122万 X 2 左右，当然这么武断的判断方式不是程序员的风格，接下来我们用科学的大数据分析方式来研究这些数据背后的意义。

注意，ES 大坑：

ES 存数据时，带有时间字段的数据如何实时展示到 kibana 的图表面板上？
🤣需要在存入 index 之前设置字段映射。参考格式，不要照抄！！！
```
{
"properties": {
"deal_date": {
  "format": "yyyy-MM-dd HH:mm:ss",
  "type": "date"
}
}
}  
```
这里并没有指定时区信息，但是 ES 默认使用 0 时区，这个软件很坑，无法设置全局默认时区。但是很多软件产生的数据都是默认机器所在时区，国内就是东八区。因为我们的源始数据本身也没有包含时区信息，这里我不想改源数据，那就假装自己在 ES 的 0 时区。同时需要修改 kibana 默认时区为 UTC，才可以保证 kibana 索引图表时间轴正确对位。不过这并不是一个科学的解决方案。

如果是企业项目，必须要用数据质量监控软件！！！要不然得有多少背锅侠要杀去祭天😂😂😂，数据可以没有但是千万不能错。

ES 存数据时，需要使用 json 格式包装数据，不符合json 语法的纯字符无法保存；
ES 序列化复杂的 bean 对象时，如果 fastjson 报错，推荐使用 Gson，很强！

TIPS😙😙😙：

Gson 相比 fastjson：Gson 序列化能力更强，但是反序列化时，fastjson 速度更快。

11- 查看 ES 数据库卡号，对比自己的深圳通地铁卡，逐渐发现了一些脱敏规律。
日志当中卡号脱敏字段密文反解猜想：
由脱敏的密文卡号反推真实卡号，因为所有卡号密文当中没有J开头的数据，但是有A开头的数据，A != 0，而且出现了 BCDEFGHIJ 没有 K，所以猜想卡号映射关系如图！！！

类似摩斯电码解密。。。我现在还不确定这个解密方式是否正确🙄🙄🙄

12- cn.java666.sztcommon.util.ParseCardNo#parse 实现了支持自动识别卡号明文和密文、一键互转功能。 cn.java666.etlspringboot.controller.CardController#get 实现了卡号明文和密文互转 REST API。

13- 在搭建数仓的过程中，需要分层，还得按天分区。
搭建数仓 ing ...

TODO🔔🔔🔔:

[x] 解析 redis pageJson，转换数据格式为最小数据单元存到 csv，减少原始数据的冗余字符，方便存取和传输。丰富数据源的格式，兼容更多的实现方案；
[x] 推送 kafka，使用队列传输数据；
[x] 存入 elasticsearch，使用全文检索实现实时搜索，kibana 可视化展示；
[ ] 开放卡号查数据 REST API，提供卡号查询接口，返回数据库的刷卡记录；
[ ] 数仓建模：ODS、DWD、DWS、ADS
[ ] hive 分析，oozie 调度；
[ ] flink 流式实时分析早晚高峰站点压力排行；
[ ] spark 微批处理。。。
[ ] DataV 可视化大屏展示；

更新日志🌥：

2020-04-17
- 修正错别字；
- 发布v0.12;
2020-04-16
- 重构项目；
- 补充文档
- 发布v0.1
2020-04-15
- 增加 common 模块，拆分解耦；
- 支持自动识别卡号明文和密文，一键互转，提供 REST API；
- 修复 ES 时区导致的错误统计数量；
- Redis2Csv 实现了按天转换 csv 存盘；
2020-04-14
- 重构；
- 完成 csv 格式文件的抽取；
- 添加 GPL-3 开源证书，鼓励开源分发；
- 添加徽标；
- 完成写入 ES 数据库，添加时间映射,kibana 实时查看刷卡数据统计曲线的变化；
2020-04-13
- 项目初始化；
- 完成数据源清洗去重，存到 redis；
- 完成 redis 查询 REST API 的开发；
- 完成 flink 自定义 source redis 的开发，并且更细粒度清洗源数据；
- 完成推送源数据到 kafka；

联系😪：

欢迎交流技术，接头暗号github

百度和谷歌能找到的问题就不要再问了！很累的😕😕😕

补充💌💌💌：

不开小密圈；
不卖课、不卖教程；
不求赞，不求粉；
不发广告、不骚扰；
不割韭菜

坚持原则和底线。

比心🤞🤞🤞

吐个槽🍦🍦🍦：

程序员这辈子一定会遇到的三个问题：

乱码问题🌚；
时区不一致问题🌗；
软件版本不兼容问题❄；

教训：

大数据程序员千万不能生产错误的数据，容忍程序运行失败、甚至没有输出数据，失败了可以跟踪原因，至少不会有脏数据。
一旦数据错误，会影响后面的所有计算流程，甚至导致错误决策。

geekyouth / geekyouth.github.io