这是彭文华的第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层？

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