BI项目记(二):给我接套数据

这次故事的主角还是小D,小D工作在一家传统公司的信息部门,负责数据仓库系统的运维和开发。

话说有一天,小D被教导老板的office,老板给布置了一个任务,让小D在现有数据仓库里接入刚上线的两个系统的数据。

于是小D找到了对应系统的开发团队。可能是对方刚上线的缘故,最终也没有人搭理小D,于是直接把数据库只读权限open给了小D,让小D需要什么数据自己去抓取,如果一个查询不知道怎么写再单独去发邮件问。

话说其中一个系统还好,是SQL Server,这个跟小D的数据仓库一致,直接抽取就行。

但是另外一个系统就麻烦了,是Oracle,于是小D查阅了很多资料,安装Oracle相应的组件在数据仓库中,然后磕磕绊绊的终于连接到了这个数据库。

收集完报表的需求,确认了用户需要看到的每一个原子数据在界面上的位置,然后在开发平台通过抓取的方式也获取到了相应的查询方式,有些实在抓取不到的就发邮件问,虽然对方很忙但邮件回复的也还算及时。(数据建模的故事这里暂且不谈,话题太大。)

但是随后问题就来了,小D发现这两个接口经常报错,多数错误集中在源端数据结构的变更,比如名字变了,类型变了,长度变了,是否允许为空变了。

这个也可以理解,因为对端源系统用的是敏捷开发方式,几个礼拜上线一个变更是家常便饭。而对于源端系统团队,下游到底拿了哪些数据,他们也无法获知,所以也不能在第一时间通知到下游受影响的部门。

所以小D想到一个方法,就是把他所要的数据,提交给源端系统,让源端系统负责帮忙组织这些数据,放在一个平面文件里,在这个平面文件中,所有的字段名都是提前约定好的。

这样一来,源端系统知道了下游系统需要什么数据,在每次做变更的时候,就会有一个地方知晓,这个变更对于下游的影响。而对于有些变更,完全在可以不改变这个接口的情况下实现,减少了下游系统的开发和测试成本。

小D对于这个方法还是很满意的,只是对于那个Oracle的系统,操作系统是Linux,他们只支持用SFTP的连接,而这个工具在Windows下是没有微软自带工具解决的,不过还好通过第三方工具都可以搞定,而且第三方工具也都支持ETL接口编程,调度起来也都还方便。

这个方法确实方便了小D,但源端系统如果得不到实惠其实也是很难推动的,而这里对于源端系统来说,最主要的一个实惠就是,对于同一份数据,可能下游好几个系统都需要,相比先前的方案,他们只导出一次就可以了,避免先前的数据库直连,同样的数据要被访问多次,影响系统的性能。

小D同时也发现,相比先前的数据库直连,这个方法有效的避免了,数据仓库由于某些特殊原因失败,错过数据的加载的时间的问题。先前有好几次就是由于小D的数据仓库后半夜莫名其妙的打补丁重启,然后错了了约定的数据加载时间,结果等问题被发现的时候,源端业务系统已经开始新一天的业务运营,先前的数据根本追不回来。

于是,接口顺利的运行了好长时间。

再后来,报表的需求越来越多,更多的明细数据提了出来,而此时通过平面文件的导出就显得很笨拙,跟传统数据库直连的方法来比较,这个方法多出了额外的IO开销,以及序列化和反序列化成本,直接导致的问题就是直到第二天上班的时候,要么是文件还没有导出完毕,要么是文件还没有加载完毕。

于是,通过中间数据库的方法被小D提起。就是在源系统和数据仓库间,建立另外一个单独的数据库,每天源系统会把下游系统系统需要的数据送到这里,下游系统随后直接从这个中间库加载数据。

就这样,系统平稳的运行了好久好久。

再后来,随着大数据的火热,好多部门都搭建起来了自己的大数据平台。突然有一天小D被通知道:请求的数据可以直接从大数据平台里获取,就不需要再走中间库了。

于是小D做了一番研究,发现源端系统每次是把数据发送给大数据平台存储,他们主要是方便自己部门报表平台,主要是Tableau系统的对接。

就这样,小D也跟着踏上了大数据之路。。。

posted @ 2018-12-11 00:41  哥本哈士奇(aspnetx)  阅读(601)  评论(0编辑  收藏  举报