出大事了!IBM的数仓项目黄了,赔了好几亿!

204 阅读6分钟

这是彭文华的第182篇原创\

其实建模的文章写了不少了,但是都还停留在什么星型、雪花型这些比较粗浅的内容层面。\

其实,建模这件事情是个能力要求非常高的技术活儿。而且这个活儿不是说公司牛、技术牛就能搞定的,这件事情直接决定项目的成败。

就在2021年2月份,IBM因为一个数仓项目失利,赔了客户好几亿。其中一个原因就是因为IBM叫过去的人,没有按照Teradata(天睿)的金融服务逻辑数据模型(FSLDM)去设计企业数据仓库EDW。

我作为吃瓜群众,就喜欢看热闹。而且,这里面的建模可以好好跟你聊聊。

这是个啥项目?

起因是这样的,有一家英国保险公司,叫Direct Line,2014年整了一个项目“Best for Customer”,跟所有保险公司一样,这个项目的核心是为客户服务。\

他们本来想把所有的客户数据都归归拢,放到企业数据仓库EDW里,然后上面架设一个新的平台,所有保险业务都在这上面跑。数据打通了,业务流程也就能更顺畅,客户价值也能发挥到最大。

你看,想的是不是很好?没毛病啊!

整个项目的架构呢,也是早就设计好的。数仓用的是Teradata的Database14,数据迁移、ETL用的是Informatica的产品,也是世界顶尖产品。数据模型就用Teradata的金融服务逻辑数据模型FSLDM。

有些同学对这两个产品有些陌生啊。ETL工具刚才说过了,Teradata就好玩了。这么跟你说吧,Teradata一度是全球数仓界最牛的公司,没有之一。这个称号不是我说的啊,是客户说的。Teradata建的各种数据模型,早就是业界标杆了。

那出问题了?

按理来说,熟悉的业务,强大的技术,加上IBM、Teradata和Informatica这么强大的组合,又给了足够的时间。虽然有一些新系统的建设和新旧系统的切换,但是这都是有完善的解决方案的,不应该出现啥问题。

但是恰恰就是这不可能出问题的项目,最终让IBM赔钱了。

这次争议的核心点之一,就是Direct Line公司说IBM没有按照Teradata的金融服务逻辑数据模型(FSLDM)去搞设计。明明Teradata这边已经有标准模型了,还要不断重复建已有的实体。\

原话是:“过以一种毫无章法、毫无根据的方式来复制和粘贴,以扩展该模型,结果破坏了设计集成层,使得EDW难以填充、维护和理解”。这句话的评价真的是太崩溃了。

明眼人一看就知道,IBM和Teradata之间肯定有什么不可调和的矛盾。我估摸着是这样的:IBM要去做项目,但是关系没搞好,Teradata一直就没鸟他,也不给资料,也不给支持,然后IBM就只好自己干。自己干呢,又没有Teradata的支持,就只好根据自己这边的经验搞建设了,最后搞的稀碎。

最后,IBM在2016年移交全部代码,由Teradata全盘接手,推到重来。你说这事闹的。

这还没算完。东家把IBM给告了!官司打了好几年。反正双方都你来我往,说自己没问题呗。这个案子到今年2月才判下来,我看的是赔了3个多亿啊。

其实我对IBM的事情一点都不关心,我其实想跟大家分享的是Teradata的金融服务逻辑数据模型FSLDM。这个比较难讲,没有啥动力啊。

如果本文的“在看”超过30个,我就单开一篇给大家解剖一下Teradata的标准数仓模型FSLDM,看看业界最经典的数仓模型是怎么建设的。

配合以下文章享受更佳

干货 | 一口气讲完数据仓库建模方法

干货 | 如何搭建一个数据仓库

【资料包】数据仓库建设完整资料包\

【实战】 手摸手搭建一个实时数据仓库

【干货】 数仓到底要分多少层?

数据仓库为什么要有ODS层?\

我需要你的转发,小小的满足一下我的虚荣心