We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
___ ____ _____ _ _ __ _ _ _ / __| |_ / |_ _| ___ | |__ (_) / _` | __| | __ _ | |_ __ _ \__ \ / / | | |___| | '_ \ | | \__, | / _` | / _` | | _| / _` | |___/ /___| _|_|_ _____ |_.__/ _|_|_ |___/ \__,_| \__,_| _\__| \__,_| _|"""""|_|"""""|_|"""""|_| |_|"""""|_|"""""|_|"""""|_|"""""|_|"""""|_|"""""|_|"""""| "`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'
我发现越来越多的国产开源软件用户体验值得肯定。。。
以下是我的开发环境,仅作参考:
如果你选用原版 Apache 组件搭建大数据集群,那么你会有踩不完的坑。我的头发不够掉了,所以我选 CDH!!!⚙🛠😏😏😏
以上软件分开部署在我的三台电脑上,Win10 笔记本 VMware + Win10 台式机 VMware + 古董笔记本 CentOS7。物理机全都配置 SSD + 千兆以太网卡,HDFS 需要最快的网卡。好马配好鞍,当然你得有个千兆交换机配合千兆网线,木桶原理警告!!!🎈🎈🎈
有个机架当然再好不过了,哈哈哈。。。
如果你想避免网线牵来牵去,可以采用电力猫实现分布式家庭组网方案;
理论上可以当作实时数据,但是这个接口响应太慢了,如果采用 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条子数据;
cn.java666.etlspringboot.source.SZTData#saveData
/tmp/szt-data/szt-data-page.jsons
3- 调用 cn.java666.etlflink.sink.RedisSinkPageJson#main 实现 etl 清洗,去除重复数据,redis 天然去重排序,保证数据干净有序,跑完后核对 redis 数据量 1337。
cn.java666.etlflink.sink.RedisSinkPageJson#main
4- redis 查询,redis-cli 登录后执行 hget szt:pageJson 1 或者 dbeaver 可视化查询:
hget szt:pageJson 1
5- cn.java666.etlspringboot.EtlSApp#main 启动后,也可以用 knife4j 在线调试 REST API:
cn.java666.etlspringboot.EtlSApp#main
6- cn.java666.etlflink.source.MyRedisSourceFun#run 清洗数据发现 133.7 万数据中,有小部分源数据字段数为9,缺少两个字段:station、car_no;丢弃脏数据。
cn.java666.etlflink.source.MyRedisSourceFun#run
合格源数据示例:
{ "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 条。
cn.java666.etlflink.app.Redis2Kafka#main
topic-flink-szt-all
topic-flink-szt
8- kafka-eagle 监控查看 topic,基于原版去掉了背景图,漂亮多了:
ksql 命令查询: select * from "topic-flink-szt" where "partition" in (0) limit 1000
select * from "topic-flink-szt" where "partition" in (0) limit 1000
9- cn.java666.etlflink.app.Redis2Csv#main 实现了 flink sink csv 格式文件,并且支持按天分块保存。
cn.java666.etlflink.app.Redis2Csv#main
10- cn.java666.etlflink.app.Redis2ES#main 实现了 ES 存储源数据。实现实时全文检索,实时跟踪深圳通刷卡数据。
cn.java666.etlflink.app.Redis2ES#main
这个模块涉及技术细节比较多,如果没有 ES 使用经验,可以先做下功课,不然的话会很懵。
我之前在处理 ES 各种问题踩了不少坑,熬了不少通宵,掉了很多头发。
遇到问题心态要稳,因为你今天处理了一个问题,明天接触新的版本新的框架大概率又会出现新的问题。。🥺🥺🥺
所以最佳实践很重要!!!
👇👇👇这部分内容有更新:修正了上一个版本时区问题。
🎬接下来,让我们时光倒流,回到 2018-09-01这一天,调整 kibana 面板时间范围 2018-09-01 00:00:00.000~2018-09-01 23:59:59.999,看看当天深圳通刷卡记录的统计图曲线走向是否科学,间接验证数据源的完整性。
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
szt-data
在 1266039 条合格数据中,有 1227234 条数据集中在 2018-09-01 这一天的上午时段;
我们暂且相信上午时段的数据是真实的,那么是否说明官方提供的数据并不是全部的当天完整刷卡数据???
如果按照上午的刷卡量来估测全天的刷卡量,考虑到是周六,那么深圳通全天的刷卡记录数据应该在 122万 X 2 左右,当然这么武断的判断方式不是程序员的风格,接下来我们用科学的大数据分析方式来研究这些数据背后的意义。
注意,ES 大坑:
{ "properties": { "deal_date": { "format": "yyyy-MM-dd HH:mm:ss", "type": "date" } } }
这里并没有指定时区信息,但是 ES 默认使用 0 时区,这个软件很坑,无法设置全局默认时区。但是很多软件产生的数据都是默认机器所在时区,国内就是东八区。因为我们的源始数据本身也没有包含时区信息,这里我不想改源数据,那就假装自己在 ES 的 0 时区。同时需要修改 kibana 默认时区为 UTC,才可以保证 kibana 索引图表时间轴正确对位。不过这并不是一个科学的解决方案。
如果是企业项目,必须要用数据质量监控软件!!!要不然得有多少背锅侠要杀去祭天😂😂😂,数据可以没有但是千万不能错。
11- 查看 ES 数据库卡号,对比自己的深圳通地铁卡,逐渐发现了一些脱敏规律。 日志当中卡号脱敏字段密文反解猜想: 由脱敏的密文卡号反推真实卡号,因为所有卡号密文当中没有J开头的数据, 但是有A开头的数据,A != 0,而且出现了 BCDEFGHIJ 没有 K,所以猜想卡号映射关系如图!!! 类似摩斯电码解密。。。我现在还不确定这个解密方式是否正确🙄🙄🙄
12- cn.java666.sztcommon.util.ParseCardNo#parse 实现了支持自动识别卡号明文和密文、一键互转功能。 cn.java666.etlspringboot.controller.CardController#get 实现了卡号明文和密文互转 REST API。
cn.java666.sztcommon.util.ParseCardNo#parse
cn.java666.etlspringboot.controller.CardController#get
13- 在搭建数仓的过程中,需要分层,还得按天分区。 搭建数仓 ing ...
2020-04-17
2020-04-16
2020-04-15
2020-04-14
2020-04-13
欢迎交流技术,接头暗号github
github
百度和谷歌能找到的问题就不要再问了!很累的😕😕😕
坚持原则和底线。
比心🤞🤞🤞
程序员这辈子一定会遇到的三个问题:
The text was updated successfully, but these errors were encountered:
正在研究大数据相关的东西,看到你的东西希望更详细一些
Sorry, something went wrong.
目前该项目还在继续开发中,后期会不断添加新功能和完善。
No branches or pull requests
项目说明🚩:
核心技术栈 + 版本选择 + 点评 (持续更新)⚡:
准备工作🍬:
以下是我的开发环境,仅作参考:
如果你选用原版 Apache 组件搭建大数据集群,那么你会有踩不完的坑。我的头发不够掉了,所以我选 CDH!!!⚙🛠😏😏😏
物理机配置💎:
以上软件分开部署在我的三台电脑上,Win10 笔记本 VMware + Win10 台式机 VMware + 古董笔记本 CentOS7。物理机全都配置 SSD + 千兆以太网卡,HDFS 需要最快的网卡。好马配好鞍,当然你得有个千兆交换机配合千兆网线,木桶原理警告!!!🎈🎈🎈
有个机架当然再好不过了,哈哈哈。。。
如果你想避免网线牵来牵去,可以采用电力猫实现分布式家庭组网方案;
数据源🌍:
https://opendata.sz.gov.cn/data/api/toApiDetails/29200_00403601
理论上可以当作实时数据,但是这个接口响应太慢了,如果采用 kafka 队列方式,也可以模拟出实时效果。
本项目采用离线 + 实时思路 多种方案处理。
开发进度🥇:
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;丢弃脏数据。合格源数据示例:
不合格的源数据示例:
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 处理流程:
注意,ES 大坑:
🤣需要在存入 index 之前设置字段映射。参考格式,不要照抄!!!
这里并没有指定时区信息,但是 ES 默认使用 0 时区,这个软件很坑,无法设置全局默认时区。但是很多软件产生的数据都是默认机器所在时区,国内就是东八区。因为我们的源始数据本身也没有包含时区信息,这里我不想改源数据,那就假装自己在 ES 的 0 时区。同时需要修改 kibana 默认时区为 UTC,才可以保证 kibana 索引图表时间轴正确对位。不过这并不是一个科学的解决方案。
如果是企业项目,必须要用数据质量监控软件!!!要不然得有多少背锅侠要杀去祭天😂😂😂,数据可以没有但是千万不能错。
TIPS😙😙😙:
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🔔🔔🔔:
更新日志🌥:
2020-04-17
2020-04-16
2020-04-15
2020-04-14
2020-04-13
联系😪:
欢迎交流技术,接头暗号
github
补充💌💌💌:
比心🤞🤞🤞
吐个槽🍦🍦🍦:
程序员这辈子一定会遇到的三个问题:
教训:
The text was updated successfully, but these errors were encountered: