小 A 在实现一个需求的时候，发现接口文档中的设计不太合理，返回的数据结构不是平台标准的结构。
如果完全按照文档完成，则需要引入没必要的定制，徒增了复杂性。于是，小 A 按照平台标准结构进行实现。
需求实现完成之后，小 A 在预定时间之前，提前将接口调用方式发送给下游。
下游在集成的时候，发现与文档对不上，提出质疑。小 A 与下游沟通，坚持采用平台标准的结构。
小 A 强调说，之前的文档只是一个设计文档，而不是最终的接口文档。最终的接口文档必须是双方根据实际情况进行实现，双方协调，集成之后，才最终确定的。
朱熹说，大凡做事底人，多是先其大纲，其他节目可因则因。
小 A 觉得从上游数据源接入的数据字段命名不太合理，于是根据自己的理解将字段名重新映射为了一个新的名字。
数据 etl 基于这个新名字开发完了。
客户想要验证这个 etl 的正确性，于是从源系统中提取出明细数据让小 A 进行核对。
小 A 拿到数据之后，也自己提取了一份明细数据。两边一对比，小 A 就后悔了，因为客户提的明细数据的字段名全部是源系统的字段名，而小 A 则使用的是映射之后的名字。小 A 不得不重新做一次映射。
小 A 发现数据对不上，于是找到上游系统提数的人沟通。小 A 把自己的实现口径展示给对方看，对方看后，问道：“这个字段是什么？对应源系统的什么字段？”于是，小 A 又不得不去解释字段与原字段的对应关系。
小 A 感叹：这字段名映射，真不值！
早上项目团队站立会议。由于团队分散在各地，会议在线上进行。由团队成员轮流组织，今天轮到一位小伙伴，他在团队中已经工作了几个月了。
打开项目看板，他开始组织大家更新自己的工作。
站会按照角色及人员的顺序进行。点击人员列表，他开始找人。
“A 来更新一下吧”，他说道。等了一会，没人回应。会议室陷入了安静。“A 下项目了”，终于有人接着补充道。
鼠标移动到 B 旁边，停下来，犹豫着要不要往前。时间过去了约有 10 秒钟，终于跳过了 B。B 是一个非当前角色的人。接着，他找到了正确的人，会议继续。
有一个项目，其数据接入流程为：上游发送数据到 kafka -> 下游 flink 程序将 kafka 消息转换为标准的 debezium 格式 -> 另一个 flink 程序将数据写入到大数据平台以 iceberg 格式进行存储 -> 另一个 spark 批处理程序定时将 iceberg 中的数据增量写入到 hive 表
问题：中间过程太多，流程太长，涉及技术组件也多；为保证上述流程可稳定工作，还需要额外的 iceberg 表小文件优化程序；iceberg 表中的数据没有使用，无必要且存在浪费
优化：直接使用一个 spark 程序消费 kafka 数据写入 hive 表。
早上 8 点 10 分，还是按照以往的时间出门。昨晚下了雨，路上湿漉漉的。
拐过一个路口，来到了另一条路，通过这条路可以上主路。
刚一进这条路就发现已经堵得水泄不通了。车子只能慢慢蠕行，每次挪动不到一个车位的距离，挪动之后就得停下来等。
经过无数次挪动之后，看到了一点进度，到了一家吃串串的餐饮店。我感觉不太对，虽然以前这条路也堵，但是今天也太离谱了。以往三分钟的路今天竟然走了十五分钟！
没办法，到这里也只能硬着头皮继续往前挪了。经历了差不多半小时，终于才上了主路。
上主路的路口，有一个交警正在指挥交通。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。