这是彭文华的第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层？
以上就是出大事了！IBM的数仓项目黄了，赔了好几亿！错错错 莫莫莫的全部内容了，希望大家喜欢。