内容来源于需求的评审和我的工作内容，简单的讲一下数据中台订单域的建设感想
工作中遇到的问题
- 数据中台收集了多bu的数据,由于各bu的业务过程千人千面，我无法了解具体的字段根源，我难以了解BU具体业务
- 多业务方口径的不一致性，例如是金额，人次的口径，时间含义的不同口径，订单状态的不一致性，字段编码的不一致性
- ALLBU汇总表可以汇总所有业务线的共性字段，但是也丧失了具体的业务过程描述，可以保留各BU表
- 业务线众多，沟通成本大，维护成本大
- 在设计数据中台之初，考虑的东西比较少，对于后期的项目迭代，由于缺少重要字段以及错误的口径，导致严重的问题
- 中台数据服务于多项目，多项目缺少沟通，在二次加工时采取了各自不同的逻辑，导致了孤岛
- 说是数据中台，其实可能不同的中台部门都维护了一套ALLBU的数据，造成数据的冗余，同时数据的多源性导致在一个部门可能的情况是维护两套中台数据源
- 数据中台也是不断迭代的，下游应用数据层切换表的非幂等性问题，复杂程度，
- 某些业务线的业务可能发生了重大的重构并没有提供到中台
- 中台需要推广和维护，一个没人用的中台随着时间的流逝就丧失了业务价值,中台也是不易于推广的，为什么我不去业务方的底表去拿更多的数据呢
- 建设中维度建模的失效，以及考虑欠佳，导致数据模型的返工
- 数据中台是集成各BU数据的，各BU只是负责推送数据的，当各BU的业务过程发生了改变，就要即时通知中台，但是存在的问题是人离职了，不知道通知谁了？中台有一个很大的问题就是后知后觉，维护的工作量非常大，或者说什么样的业务适合中台架构
- 以度假业务线为例子。相当于一个小中台，业务线足够丰富，但是存在的问题是业务线会经常变构，导致中台来不及维护和更新
- 中台的数据治理谁来保证
- 数据中台服务于多个业务部门,就目前遇到一个问题是,底表修改了依赖关系,导致下游重跑任务遗漏的问题.底表的修改也是符合规范的,但是受限于平台血缘关系做的不够好,导致的问题,所以应该怎么建设中台底表
等等吧，总之问题很多
订单域数据中台建设有感
- 如何获取数据，最有效的方法是我们应该去BU调研业务过程，如果条件不支持我们要梳理自己的中台有哪些订单数据，比较多源数据，使得数据更为丰富和准确
- 通用层的建设，把所有的重要字段都放在一张表中，事实上并不通用，比较好的方法是建设汇总业务层同时保留BU原始信息表
- 中台一个很重要的任务就是解决交叉的问题，订单交叉订单，订单交叉UBT，在这之前我们要盘点我们的资产，理解订单之间的关系，维度和维度之间的重要映射关系，构建我们的ONE DATA/ONE ID,理解用户和实体之间的关系，每张表反应那些信息
- 要建设订单域的数据中台，各业务线的场景错综复杂，作为外Bu没有引路人和一手的数据业务资料，想把数据给吃透还是很难的
- 一味的，单纯的建设，缺少产品的支持，可能的结果就是无用功吧，但是丰富数据还是要做的
- 数据中台的一个目标是解决Data Fabric的问题,统一出口,统一分发
7.中台和业务方之间不仅存在合作关系,还存在竞争关系,要做的数据分析边界也要进行控制,这是一个问题:中台产品的发展方向问题 - 中台定位的问题,对于互联网企业来说,订单数据和用户行为数据是必不可缺少的,中台的定位在于收口和统一的数据上游和数据资产的丰富,这并不好做
