2023年第一篇来谈谈效率

news2025/1/11 12:53:05

晚上临走的时候和同事聊了聊关于效率的问题，暂且称呼为A同学。借着和A同学的这次畅谈记录下这段时间的所负责的数据迁移过程。

数据迁移的整体内容并不复杂。主要内容如下

我们在做事情的时候总会遇到这件事情所关联的其他问题。

不要带着情绪去工作

书写脚本的时候正好赶上了数据部门对数据进行规范调整，以至于趋向于完成的脚本需要重新梳理，重新来一遍。和A同学沟通，我说便是部门与部门之间的KPI问题，甚至部门的KPI可能还有所冲突，以至于年前对于数据部门开展的数据规范治理动作着实有所怨气，毕竟它是我的工作量有所上升，且原本能够一气呵成的流程，还需要通过他们的协助才能搞定。更有甚者，发生了一次消息的摩擦，好在大家也都是明理之人，时至今日，整个数据迁移的工作已趋于完成。

回顾这次摩擦的经过，实在是了解到一个事实，也是规律。愤怒往往会把人的理智和智慧丢下，只剩下情绪而已。抱有一种有色眼睛看待事情，以至于我忘记了原本系统可以使用的功能（一键拒绝上线单）。外插这次和A同学的讨论，部门与部门都是一个公司的，相互之间的KPI不应该有所冲突，而是整体上是有共同趋势的。其实这次数据部门的数据规范调整也是值得认可的，之前的各种数据确实杂乱无章，管理松散。

可能是春节期间看了东坡传更加的豁达了，这一个星期自认为个人精神状态不错，没有任何的不快，唯一的不快可能是不能放肆的享受美食吧。且和数据部门打交道，没有任何不快，反而是有问题我直接去找他们，只有一个目标，已最快的速度把事情搞定，且有质量的搞定。

大胆起来，往前冲

在做一件事情的时候，往往会遇到和这次事情相关的各种问题。在这次数据迁移过程中，发现历史数据存在缺漏的问题，只能从归档备份的MySql重新走一遍流程，写入到Clickhouse里。数据大约有2亿条记录。由于对Spark，Clickhouse的性能相关并不了解，从一开始就担心会遇到内存不足等性能问题。但其实大数据这块还是很不错的，一千万的数据资源充足约摸着10分钟以内就搞定了。以至于迁移起来信心大增。

不以事后者的态度检讨自己

说起事后者，想起了罗翔老师的一些话，作为女性在面对男性的迫害时，哪怕偶然把男性打到在地，甚至男性也已经无力迫害，女性还是会对男性进行击打，甚至击打成重伤。作为当事者是很难做到反抗成功以后不再对迫害人进行击打的，因为她也不知道迫害人是否有能力在进行迫害。说多了，哈哈哈哈哈。在面对自己曾经的错误时，倒也不必过分的要求自己，俗话说当局者迷，身在其中总是容易被牵着走的。而且尽管以事后者去思考以另一种方式可能把事情做的更好，毕竟只是猜测，哪怕它的概率很小。不能保证你以其他方式做事的时候，不会出现其他的问题。

在最近这2亿条记录的迁移过程中，自己是分成了15个脚本依次执行。到现在想了一下也是可以写成5个脚本，脚本数量缩小了三倍。但是数量缩小了三倍，但每个脚本承担的任务也便重了，变重了的脚本你能够保证执行起来内存充足，执行不超时吗，也是未必的（到现在我觉得大概率是没有问题的）

有条理有计划还是很值得的

在这次迁移中，自己约摸着是直接开干，边写脚本边遇到一些问题。原本是打算按照ct去拉去数据，写完之后才发现ct压根没有索引，只能一次性的把整张表的数据全部拉取过去，如果有一个清晰的步骤好计划，我想还是能够提高一些效率的。

要不要规划的整体时间

做项目时经常会有项目时间倒排，在做事的时候往往会拖延，是不是应该去设置一个项目时间，去倒推整个数据迁移的节奏，有着数据迁移的节奏之后，便会去思考如何使整个迁移工作更快，在这样的压力下，是不是能够得出最有效率的迁移计划呢？

经验主义害人

写脚本的时候呢，往往倾向于自己的习惯，以至于不思考还能有其他的方式。在执行脚本的时候我，往往需要替换一些数据库表名，其实也可以替换库名。自己之前都是一个表抽取数据，这次涉及到多张表，由于替换的表名较多，以至于替换字典的字符串过长，因此写了两个ods层的迁移脚本，其实完全不必，还有另一种方式仅替换库名就可以了，由于经验，由于习惯当时压根就没想。。。我觉得这也是人脑的懒惰导致的，想要人脑不那么懒惰，只能经常锻炼自己勤思考了。