企业官网建设流程全解析

网站建设的公文格式,做个人网站怎么做,wordpress地址,比较有趣的网站问题1 背景 有个供内部员工使用的后台管理系统#xff0c;每天会从上游的一个oa系统的接口同步员工数据#xff0c;oa系统侧维护了每个员工的id、名称、工作城市等等各类信息#xff0c;接口响应如下#xff1a;这个id就算是员工的唯一标识#xff0c;就像工号一样#x…问题1背景有个供内部员工使用的后台管理系统每天会从上游的一个oa系统的接口同步员工数据oa系统侧维护了每个员工的id、名称、工作城市等等各类信息接口响应如下这个id就算是员工的唯一标识就像工号一样不会变的那种。因此我们把接口数据拿到后就直接落地到我们本地数据库的表中表的主键虽然设定为自增主键但是在程序里我们会直接用oa系统给我们的这个id来设置本地表id的值后再插入。表结构sql如下这个sql是自动生成的默认生成出来的是不带id这种主键字段的我们手动加了一下手动加上id字段结果最近弄了一个员工报商业保险的活动简单来说就是存储一下数据用户id 、对应的商业保险id。报保险的过程中发现用户表缺了些数据没同步如用户证件号报保险需要、城市等所以就加了一下这几个字段。新增完字段后mapper.xml代码自动生成也没仔细看结果就把之前手动加的id字段给冲掉了这个上线后由于在程序中没有指定id字段就导致本地表中的id变成了使用自增的方式postgresql从序列中获取下一个id的值类似mysql中自增。而且从oa系统同步员工信息到我方系统每天都是靠一个定时任务在跑每天跑的时候/* by 01022.hk - online tools website : 01022.hk/zh/json2cs.html */ 1、从oa侧获取员工列表数据 2、清空本地表 3、批量插入从oa侧获取的员工数据这就导致员工的id上线后每天都在变每天都在变。当时我查问题看到这个问题的时候吓了一跳当时员工报商业保险正如火如荼呢我一想难道得赶紧通知全公司的人重新报了而且当时业务的人和保险公司约定的提供保险人员名单的时间也没几天了。。。后面我又仔细看了下发现问题还没有那么大。就是在数据先落地到t_user_sync这个表这个表和上游oa侧数据保持一模一样只读不写便于定位问题后还有个定时任务将数据从t_user_sync转移到我们实际的用户表sy_user这个表我们会进行增删改查等等。这个定时任务在将t_user_sync转移到sy_user的过程中是增量同步的。如发现zhangsan这个用户时先查一下sy_user里有没有没有才插入插入时sy_user的id也是用的t_user_sync的id也就是oa侧的id有就更新。这个增量同步机制救了我导致的结果是虽然t_user_sync中id错了且每天都在变但sy_user中的id虽然也是错的但是不会每天变而是用到第一次同步t_user_sync时的id。只要sy_user表中的id不变错的也影响不大至少员工报保险的相关表中的关联关系是没问题的员工id 员工名称 保险名称11111(错的) 张三 xxx商业保险而我们这个系统中其他地方也有用到这个用户id的虽然由于用户id变化导致了关联关系错乱但是影响毕竟业务影响没那么大到时候再修复即可。总结其实这个问题就是粗心造成的当然客观上现在手里系统太多精力分散也是一个原因。另外这个自动生成代码的机制后期看看这块是否可以优化吧能把id字段一起生成到xml中是最好。如果实在不行的话也应该考虑这种表的id字段就设置为非自增、非空必须让程序手动设置也能及时发现问题。问题2etl介绍背景前先讲讲etl吧在我从业没几年的时候当时由于接触的都是mysql这种oltp这类业务为主有时候看到一些招聘岗位写etl不知道是啥意思。也是这几年才大概了解/* by 01022.hk - online tools website : 01022.hk/zh/json2cs.html */ 将企业中分散的数据集中的输入到数据仓库中的过程就是 ETL。 Extract提取 从多个异构数据源如数据库、文件系统、API等中提取原始数据。数据源可以是关系型数据库如MySQL、PostgreSQL、非关系型数据库如MongoDB、Cassandra、文件如CSV、JSON、API或流式数据源。 Transform转换 对提取的数据进行清洗、标准化、聚合、去重等操作以满足业务需求或数据分析的要求。这一步可能涉及数据类型转换、格式转换、业务规则应用、数据聚合、数据质量校验等。 Load加载 将转换后的数据加载到目标存储系统中通常是数据仓库或数据湖中供后续的数据分析、报表或机器学习等用途。加载的方式可以是全量加载、增量加载或实时加载。像我们公司数据库种类又多oracle、mysql、pg、国产系统又多好多系统还是买的你想要某个系统的数据要么走接口要么通过人家的表。一方面好多买的系统不喜欢对外提供接口商业上的考虑毕竟数据是无价的让你难以迁移也就是这几年感觉新的软件系统才开始注重对外提供api另一方面有时候表很多有些表也很大自己写接口去每天同步工作量也不小还要申请api key/api secret还要开通网络也是挺麻烦的最终就慢慢习惯了、妥协了通过数仓etl同步还是能省一些事吧。背景另一个c端系统重要性比上面那个系统重要多了这两天也出了一个问题。这个系统本来是一个外包同事在维护由于他所在的公司和我们公司不再合作了他也就跟着离职了其实可以和新外包公司签约不过他说新外包公司不太喜欢。他开发完成了最后一个功能并完成测试后还没来得及系统上线所以上线的事就我来弄。我整理了一下上线的各种变更如sql、nacos配置、xxljob、版本jar包、前端包等等一大堆写了个文档就提交变更流程了。其中一个sql是给某个数仓同步表加id字段并新建了序列设置id字段通过序列来自增我当时还专门研究了一下我们有两个表jy_sync_h_logasset 当前表、jy_sync_h_logasset_history历史表两个表的结构类似只是一个存储最近几个月的数据jy_sync_h_logasset 一个存储几个人前的数据jy_sync_h_logasset_history。系统会定期把几个月前的数据从当前表转移到历史表里去保证当前表的数据量不要太大影响查询速度。这两个表有一个问题就是表没有设置id这种主键为啥没主键呢因为jy_sync_h_logasset 这个表的数据是通过数仓的etl操作从其他上游数据库搬运过来的。jy_sync_h_logasset 对应的上游的话不一定是一个表可能是一个视图或者是一个sql比如select name,oa_account from employee这种它的sql中就没有查询id字段或者是多表join那种一对多就是算有id也会导致id重复。所以我猜测是这个原因导致我方的这个表是没有id字段的也没弄主键。一个表没有主键据我所知在分页查询时容易不稳定某一条记录可能会在这一页出现在下一页继续出现一般我们解决这种分页查询不稳定的问题都是会按照某个字段排序而一般首选就是id字段。对于这个没有id字段的表来说分页查询应该是容易出问题的所以我猜测这就是本次sql变更加id字段创建序列设置id字段从序列取值的原因。我当时为啥注意这个sql呢我发现他只建了一个序列然后两个表都用了这个序列我当时多看了两眼只是有点奇怪一般来说每个表会设置一个自己的序列。后来我看到在将jy_sync_h_logasset表中几个月前的数据转移到jy_sync_h_logasset_history的定时任务中代码里设置了jy_sync_h_logasset_history的id就直接使用jy_sync_h_logasset中的id也就是说jy_sync_h_logasset_history实际并不会使用序列中的值作为id我也就没管了。当然出事的确实也不是这个问题。周四下午和运维一块看着他做完上线变更想着又了了一个事。结果周五早上8点多就给我发消息说有个xxljob的定时任务失败了。我赶紧吃完饭抱着电脑去找他看了下发现报错的原因是一个etl_status的表中没有查到当天的记录这个表的用途是数仓在给我们推送完各个表的数据后会在etl_status中写入一条成功记录。既然这次报错是没查到数仓写的成功记录是不是数据推送失败了呢我们赶紧联系了数仓的同事数仓同事过了会告诉我们说是数仓在往jy_sync_h_logasset写记录时报错了提示对jy_sync_h_logasset_pk这个序列的权限不足。然后我过去找他仔细聊了下比如他那边的一次数仓etl任务总共要推10个表过来如果其中一个表失败了就会导致不写入etl_status成功记录。但已经推送成功的表如这里成功了9个表的数据并不会回退。问题是搞清楚了还是粗心导致的我当时完全没有想起来序列要给数仓用户授权这个事。但这个问题看起来小导致的影响还是比较大的由于我们定位这个问题及修复给数仓用户增加权限数仓重新推送花了一些时间修复时已经过了某个特定的时点了导致我方已经没有时间再来跑xxljob了某个xxljob任务由于下游系统的限制要求必须在某个时点之前跑才行只能是让业务同事去通知客户道歉。部门的领导也介入了这个事情下周就得系统梳理下现状再看看有没有在这种异常情况下进行补救的措施当然我们这边其实是可以补救的数仓重新推送数据后我方也重新执行xxljob相关任务但是我们系统还有下游现在就是下游系统不支持过了某个时间点后进行补救这块还得再看看怎么弄。总结小小的问题大大的影响出了问题再来处理一般成本是最高的也会带来更多的工作如事故汇报、针对事故的改进措施等。还是得防患于未然治未病。当然我简单看了下希望postgresql可以做到新增的序列不用每次单独授权而是在数据库级别进行授权。下周再研究下吧和dba沟通下避免现在权限管的太细导致的问题。