前言
本文来自于大数据架构建模大咖群聊天实录。
一问一答一讨论，都是真问题和实战答复。
以下为研讨实录，请查收：
第三方如何做OneID
提问：
请教一下大佬，来自于很多合作方的不同渠道用户订单数据如何做oneid，打不通很头疼啊。
回答：
第三方，你只能通过你本身的数据（如果有地理位置、姓名啥的）与第三方能提供的信息进行匹配，然后弄个算法计算匹配率。推断一下。
我们与第三方都是推断的。第三方不会给你电话这些用户信息的。
还有一种办法，和他们合作，他们会给你们一些标签。只是标签，没有用户详细信息。我们和**签协议就是拿风控标签。**元一次。没人会给你客户信息，法律就不允许
我们买的是风控标签，其他的我也没有咨询过，因为我们公司是保险行业和互联网结合的所以有点特殊，客户信息非常全，通过一些信息就能匹配出来。
我们和***保险合作就是联邦学习的方式，都不透露客户信息，然后计算相关客户特点。 主要是我们只要用户分析标签，不要具体信息（自己有）。
解决问题的方法：\
隐私计算，联邦学习，共同建模
现有的方案：\
蚂蚁的morse(付费)、微众银行的 FATE（开源）、光之树
实际效果：\
大家都是碰碰运气
这个是看体量，两边都是由上亿用户信息的时候就能跑出点东西，如果只用一点数据，那就没啥意义。
联邦另一个坑是训练太慢，因为双方交换的都不是直接特征数据，防止被推出来原始特征，所以收敛很慢，加上双方数据传输都走网络，比本地慢太多
所以相比本地建模基本搜索上万倍的时间开销，最终效果也会打折扣
公司内联邦落地的不少，厂外联邦选择好像正经用起来的没几个。
感谢 @跨越**、@隽*、@whyme***、@漫** 等大佬的精彩答复。
银行信贷业务数仓建模
提问：
想请教各位大佬一个数仓建模问题：
以银行信贷业务为例，源系统的模型如下（个人理解应该事实维度划分了），那数仓DWD层还需要再建模么？
源系统表如下
- 基本信贷客户数据表（维度表，包括借款方和担保方）
- 借款方的借款合同表（事实表，含维度1信息）
- 借款合同和担保合同（押品，担保人）关系表 （个人理解这个是无事实的事实表，是N:M 关系）
- 押品信息表 （维度表）担保人信息表（维度表）
不是主从，就比如公司借款100万，有80万通过房产担保，20万通过担保人担保。反之，有500万的房产，可以给2-3个借款合同作担保。\
就是想问问，这种源表的结构，进了数仓还用怎么建模吗？感觉宽表也不能拉，事实和维度也和源表差不多，数据粒度也一致，那中间层怎么搞？现在是直接ods到了adm。\
回答：
把2和3的合并，构建一个借款事实表 粒度是借款和合同的组合。
100万这个生成两条记录：借款合同和担保合同。
借款事实表上 借款 和担保的合同外健都有，关系就落在了借款事实表上。
贷款合同，借款还款，利息，以及担保和额度不是同一个层次的东西。\
贷款合同是和facility自己担保关联的，合同项下的借款还款，利息支付是下一层级的记录，对于普通的商业贷款应该这么理解。对于贸易融资做法可能有不同。
授信是针对贷款主体的。担保是贷款主体额外的一个保证。担保者是第三方。
担保的履约，实际上就是贷款主体违约造成的由担保者承担责任义务。
担保者可以是母公司，集团公司，或者是供应链上的买卖方，俗称大腿。
授信一般都要有，担保不一定非要有。
看看EAST 4.0 数据标准，里面有信贷方面的主题，看看是否有参考价值。\
EAST是银保监倒逼银行数据治理的一个监管政策。
都是明细数据，分十个主题，校验规则也很多，对学习银行业务很有帮助。
感谢 @风在**、@散步的**、@Whyme、@Feyn**等一众大佬的专业解答。
hive 怎么切片
提问：
又遇到个问题，面试的时候人家问你们的hive数仓怎么切片的，我完全不知道怎么说更全面。
回答：
切片和分区不同，切片是并发搬迁后最终在Hive里还是一个文件， 分区Hive相当于一个文件夹，分几个区就保持几个文件夹的。分区不是关系数据库的物理字段，是一个逻辑概念，在Hive对应的就是文件夹。
切片表其实就是只展示某一个维度的数据表。按照维度枚举值，可以分多个切片，对应多个实例任务做数据接入。高并发，提升效率。\
全量表：记录每天的所有的最新状态的数据，\
增量表：记录每天的新增数据，增量数据是上次导出之后的新数据。
快照表：按日分区，记录截止数据日期的全量数据
切片表：切片表根据基础表，往往只反映某一个维度的相应数据。其表结构与基础表结构相同，但数据往往只有某一维度，或者某一个事实条件的数据。
结语
用一个哥们的私信作为结语吧：
加油，数字人，今天又是美好的一天！
感谢阅读，本次分享的内容就结束了。也欢迎大家加我微信，咱俩私聊啊
推荐阅读：\
更多精彩：
