大学最重要的事件应该是锤炼自学的能力、造就自律的心性。
工作后,最重要的事件应该是执行力 MAX 的可靠性以及谨严处事的态度。
仿佛每件事都会有专门的目标性。
然而,工作久了,难免会 “学会偷懒”,不再像从前哐哧哐哧就开始无想法的口头。
1. 循序渐进固化思维
-
在遇到采集数据异样排查问题时,W 总是习惯于从文件系统拉取 log 日志进行查问,然而采集机器数少则十几台,多则成千盈百
- 不是吧不是吧,这种耗时费劲的事件,不会真的有人这么干吧?
- 想必除了想要摸鱼的人,不会有人傻到大批量拉取日志进行剖析。
正解:能够借助于 Hive or Flink 集群建表 SQL 剖析,效率更高。(当然,有更方便快捷的形式欢送举荐。)
2. 从零造轮子为哪般
-
有工具能够辅助疾速解决问题,然而常常习惯于本人从零造轮子?
- 没错,说的就是你,有极速模式,为何要采纳惯例流程模式呢?难道是不想有本人的闲暇工夫充电学习?
- 难道说你是在成心放松,给你迁延工作量,从而有工夫跳槽走位???
正解:咱们能够学习架构原理,使用思维,发散学习。(比方二叉树的中序遍历能够使用到自助式 ETL 中的表达式聚合计算中)
3. 架构缺点补丁一直
-
小文件合并性能,采纳单纯的 JAVA 服务本人实现,每天均匀有 80W+ 的小文件合并任务量???
- 如果数据都是存储在 HDFS 上的,那么你的 NameNode 压力是要多大啊?
- 大量小文件问题根本原因还是架构设计有问题,如果日志切分正当,小文件量是极其少的。
- 所以,你的工作量就是本人造就了架构问题,而后在此基础之上再开发一套服务来做小日志文件归并?他人从简单入简,而你是从简略到简单。(莫非你是安琪拉?要 “缝缝补补又是一年?”)
- 那么,你的思维是什么?是为了彰显你的研发能力以及代码量而生的吗?
正解:敢于推倒架构设计,架构师不是神人,也会有架构破绽以及有余点,要以倒退眼光对待问题,而不是尊敬。(毕竟活在前人暗影下很累。)
4. 随声附和普度众生
-
随声附和,技术选型素来都是拍脑袋 or 看了几篇博客???
- 不经大脑思考或者浅尝辄止就自认为一目了然某门技术?是骡子是马敢拉进去溜溜吗?走两步?
- 随声附和?如果没有本人想法就坦言,缓缓造就本人的意识,而不是人云亦云。( 要有对外我是“辅助位”,对内深藏不露。)
- 张口就来?这个用 Flink?这个用 Clickhouse?这个用 RabbitMQ?你调研了吗?有数据根据吗?请收回来你的测试报告以及数据凭证。
正解:往往最站不住脚的是空口无凭。聪慧的人,会间接收回上帝之手(有数据 + 测试报告),让你有力反驳。
5. 如法炮制乐此不疲
-
常常会遇到一类人,总喜爱如法炮制,一个计划解万千难题。
- 你可否思考过在同一套架构模式下,前后二者数据量级 or 数据埋点相干的差距?
- 你可否思考过在同一套代码逻辑下,前后二者 producer-consumer 部署计划不同会有所差异?
- 你可否思考过在用一个 HQL ETL 问题时,前后时间跨度曾经截然不同(一年前和一年后数据量差距有多大?dt 范畴有多大?)?
正解:世间没有银弹。咱们总是习惯于如法炮制,一套办法冠以多用,然而往往得失相当。
说了这么多,其实只是想表白一个点:多思考,多复盘,多反思,跳出极限。