这次故事的主角还是小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也跟着踏上了大数据之路。。。