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