大学最重要的事件应该是锤炼自学的能力、造就自律的心性。
工作后，最重要的事件应该是执行力 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 范畴有多大？）？
正解：世间没有银弹。咱们总是习惯于如法炮制，一套办法冠以多用，然而往往得失相当。
说了这么多，其实只是想表白一个点：多思考，多复盘，多反思，跳出极限。