0%

每日一思

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 分,还是按照以往的时间出门。昨晚下了雨,路上湿漉漉的。

拐过一个路口,来到了另一条路,通过这条路可以上主路。

刚一进这条路就发现已经堵得水泄不通了。车子只能慢慢蠕行,每次挪动不到一个车位的距离,挪动之后就得停下来等。

经过无数次挪动之后,看到了一点进度,到了一家吃串串的餐饮店。我感觉不太对,虽然以前这条路也堵,但是今天也太离谱了。以往三分钟的路今天竟然走了十五分钟!

没办法,到这里也只能硬着头皮继续往前挪了。经历了差不多半小时,终于才上了主路。

上主路的路口,有一个交警正在指挥交通。

欢迎关注我的其它发布渠道