前言
兄弟们太猛了！我就要30个“在看”，结果半个小时就点满30个了，到今天，已经快130个了，多出来的是要干啥？吓的我肝儿直颤。。。
那我就写着，您老凑合看？
上次说到一家英国保险公司Direct Line委托IBM做客户中心的项目。结果IBM不知道派过去的人有问题，还是别的原因，给整劈叉了。项目原定要用Teradata的FSLDM模型，结果IBM就是不用，反而自己又整了一套，最后整的是一塌糊涂。
甲方甚至给出了这样的评价：
“以一种毫无章法、毫无根据的方式来复制和粘贴，以扩展该模型，结果破坏了设计集成层，使得EDW难以填充、维护和理解”。
最后的结果呢，IBM移交所有代码，赔了3个多亿。你可能会幸灾乐祸，IBM这么牛的公司，怎么也不会建模啊？
建模
其实数仓建模的方法论，Inmon和Kimball两位老爷子早就已经说完了。后面的各大公司基于两位老爷子的理论，做了大量的实践。
这两位老爷子的理论研究已经非常透彻了，透彻到什么程度？就是他们写的书，到现在依然能拿过来当做教材。什么数据湖、数据中台，其实底层建模理论还是原来的那些。
那么问题来了，到底啥是建模？
其实讲穿了，建模就是对现实世界的抽象。
现实世界只有一个，那理论基础也是同源的，具体的应用场景也能找到共同性，那就必然能对某个场景抽象出一个合理的模型套路对吧？
是的。IBM、Teradata等IT巨头早已经把这些模型按照自己的方式抽象好了。
在银行这个行当，IBM有BDWM，银行数据仓库模型，Banking Data Warehouse Model。
Teradata这边的呢，就是FSLDM了。FSLDM全称是金融服务逻辑数据模型，Financial Services Logical Data Model。
除此之外，IBM还针对保险行业细分出IAA和IIW、Sybase也有IWS，这些都是行业经典的数据仓库业务模型。
把模型固化下来之后有啥好处呢？咱回到我经常给大家看的这张图：
业务建模部分的主要任务是把业务流程梳理清楚，这时候会产出各种流程图，方便我们了解业务，最关键的是识别我们要抽象的业务实体。
领域建模这边，就是围绕上面的核心实体，进行主题区域划分。主题区域划分的核心目的是对建设内容进行合理的切分。既要让主题相对独立，又不能建的太多，闹哄哄的没法弄。
逻辑建模这里，就得承上启下，逐步细化了一方面要看底层数据，另一方面要看业务需求。这时候就要把所有的实体和量化内容梳理出来，数据如何从底层一直流到应用层，都得想清楚，设计好。
物理建模阶段，基本上就是机械的工程建设操作了，建表、设计有向无环图，做任务调度。
看完上面的流程，你会发现，FSLDM把前面两个步骤的工作全做完了，第三个步骤的绝大多数工作也都做好了 。
在FSLDM里，整个模型分为三层：主题、概念、细节。一共10个主题域、小3千个实体和1万多个属性。根据第三层细节中已经梳理出来的内容，构建了343个逻辑视图。
这是什么概念？拿着这一堆的模型文件，只需要按照客户的个性化情况稍微处理一下，就能直接推到物理建模的阶段。
这简直是数仓领域的方便面啊，打开盖子，放入适量调料包，喜欢就加根肠，敲个鸡蛋，不喜欢就算。然后加开水泡一下，就好了！
在这里顺便吐槽一下绝大多数互联网公司，几乎没有建模，也没有文档，上去就是干，最后就是一堆的宽表。唉！废了！
主题领域
FSLDM长啥样呢？我带你走一圈哈。建模的第一步是啥？捋业务，对吧？那银行保险业的业务是啥？选一个最简单的业务“买保险”场景来捋一捋：买保险需要有几个参与方？投保人、买保险的小哥，还有保险公司。交易涉及的内容呢？钱，保险产品，有时候还有活动，交易完了还得签个合同。合同签完了，保险其实才刚刚开始，所以后面会有续保、理赔等一列操作。OK，我们简单梳理之后，能提取出什么实体？交易双方得出来吧？交易内容得分别列出来吧？交易的核心内容得有吧？交易相关实体包括：交易双方（投保人、受益人、保险公司、保险代理人）；交易内容（保险产品、营销活动、保单）；其他交易信息（交易渠道、钱）。后续的续保、理赔也同理。这是从买保险的视角看，但是运营一个公司可不止这么简单。管理保险小哥，得要有绩效管理吧？不能光靠保险小哥啊，还得建立销售渠道。产品不能太单一了，得丰富起来吧？保险是一个强管控的行业，合规得做吧？财务得弄好吧？这里面的业务太复杂了！咋就能整理好？没法弄了！虽然我参与过某保险的数据治理项目经验，但我也没能力在这里就把整个业务理清楚。太难了！
啥？你让我划分主题域？这个倒还行。前面不是说了么？建模就是对现实世界的抽象么。我们真实反应就好了。有交易，有理赔，有续保，那就一个交易域，一个理赔域。续保算交易，划到交易就好了。客户域是少不了的，再来一个卖方吧，就是保险公司。产品域得有，保单这边也得有一个。差不多了，保险监管比较重要，再弄一个监管域。嗯，这样就差不多了。
看上去好像很有道理，对不对我们先放一边，咱来看看Teradata是怎么弄的。Teradata经过对所有核心业务的梳理，在FSLDM里，把最最核心的内容提炼成十大主题域，即：当事人、资产、财务、区域、营销活动、协议、事件、内部组织、产品和渠道。
啥玩意？怎么跟我们想的完全不一样啊？当事人是什么鬼？取个新名字就显得更高大上一些？活动、组织、产品、协议、渠道、区域，我都能理解。但是为啥要有事件？为啥把资产单独弄出来？财务和区域为啥还要单独有一个域？没法理解啊！别急，咱把问题先放一边，继续往下看。从上图我们可以看出各主题域的重要程度。很简单么，跟外面连接最多的，就是核心主题域了。最重要的就是当事人、协议和组织了。这个很容易理解，刚才买保险的场景大致能对上，就是你买我卖，然后签个合同呗。其他主题域为啥这么分呢？我们把Teradata和IBM的两个模型的主题域划分对比一下：
你看，是不是区别很大？前面5、6个主题域基本都能对上，后面的主题域划分逻辑就不一样了。从这个主题域的切分上，我们就能看出来两个模型的侧重了。FSLDM更倾向于穿透到业务，BDWM就更侧重于通用性，所以会有分类、资源项目、条件等看上去含糊不清的主题域。好，我们现在回想一下之前的一些问题。为什么FSLDM跟我们想的不一样？建模不是要真实反映现实世界么？是，也不是。我们怎么评价一个好的模型？一个好的逻辑数据模型，应该是稳定的，这个没争议吧？
应该是灵活、可扩展的，这个也非常肯定对不对？
应该是规范的，这个是原则性问题。应该是中性的、通用的。这个怎么理解？其实很好理解。如果我们在建模的时候，只是顾着当前的业务模式，那最终的结果就是业务不断的变化，数据模型就跟着不断的调整，就像那个追着喂饭的家长，累死累活也喂不进去几口饭。所以我们建的模型应该把抽象出来的对象尽可能的打散、重组，然后抽象、再重组，直到能够非常通用才可以。因为只有这样，我们建设的模型，才能为同类型的新业务服务，甚至外延到其他BU。而脱离中性、通用的模型，是不可能稳定的。简单来说，你不能说今天建一个卖保险的模型。明天你们公司要卖基金了，就支持不了啦，得再建一个。你要说流程不一样，咱可以理解，但是至少交易这个领域应该是可以共用的吧？举个不是特别恰当的例子：链家当年建的楼盘字典，可不仅仅是给链家用。贝壳就是依托楼盘字典为核心建立ACN的，所有卖房的同行都能用。你以为这就完了么？并不是，租房的也能用，自如用的也是链家的楼盘字典。这就是中性、通用的典型代表。所以理解了这一点，你再去看看数据中台，是不是也是这个逻辑？一样的！同学！有一次我蹭了一堂阿里CIO学院的内部分享会，有个同学就提问题了，数据中台的这个One Model怎么这么神奇，能支持上面那么多BU的各种应用，而且业务发展这么快，你们还不需要大改？
那位目测是阿里P9+主持人的回答就是建模，建一个优秀的模型。
所以你看，建模这功夫有多深，从主题域就已经开始体现了。而FSLDM做的就非常高明。
结语
这就结束了？当然没有！这才刚分领域呢！下面还有单个主题域怎么设计、单个实体又怎么设计，不同层级的实体之间咋处理？两个领域之间怎么联系等等，一系列的问题。这已经3300字了，今天先这样。
