https://www.infoq.cn/article/MNAPUqi1vHzlRHx0uHWa
整个架构设计过程中应用了一些基本原则，也是我个人对数据中台的理解，包括以下几点：
中台一定是有业务属性的，中台要比前台更稳定；
尽量减少 ETL 加工，引入分布式技术进行即时运算，提升系统的鲁棒性；
API 服务接口优于文件和 JDBC 接口。
中台内部多层次提供 API 服务，通过服务集成的方式减少跨域的数据集成。
一家之言，希望和大家多多交流切磋。
传统上，数据体系的系统接口主要是以批量文件形式为主，前台和中台是否要延续这种接口呢？我的观点是，应该最大程度的避免使用批量文件作为接口，更多的使用 API 服务方式。具体原因有以下几点。
- 批量文件的自解释性差、可治理性差
- 前台的灵活性是源自其轻、薄的设计约束，业务功能更多依托中台的复用能力来实现，而文件接口会增加前台数据累积数据的可能性，从而为前台的边界无序扩展创造土壤。
- 依托于批量文件的“数据搬家”削弱了整个数据体系的鲁棒性
数据中台的外部接口主要是 API 服务。
那么数据中台是在炒概念吗？我认为并不是。
数据中台与数据仓库的差别不是有没有能力复用，而是因为数据集市仍然太重不符合前台的灵活性要求。同样是二元结构，因为数据集市不等于前台，所以数据仓库也就不等于中台。
数据中台既“面向主题”也“面向应用”
数据中台“面向主题”是因为包含了数据仓库，“面向应用”则是因为包含了数据集市下沉部分。这里的新问题是如何重组数据集市下沉到中台的部分，重组方式依赖设计者的经验，其实没有统一方法。我的建议是按“价值链”和“产品线”两个维度分解，两者正交构成若干单元，这些单元称为“业务域”。
同样是数据沉淀，为什么不使用数据仓库的主题，而要新建“业务域”呢？数据仓库的主题是数据层面的高度抽象，基本不体现业务流程。今天，数据应用的大趋势是强化对“一线操作”数据赋能，必然更加关注业务流程，而价值链正是业务流程的起点；产品则是衔接企业与用户的桥梁，同时也是业务操作的核心。
“业务域”是对业务流程的抽象，可以说是“面向流程的”，本质还是“面向应用”的。“业务域”数据模型不像数据仓库“主题”那样严格的去冗余，有些维度信息会重复出现，比如客户基本信息、机构信息等。
以银行为例，“价值链”上的典型环节包括营销、运营、风控等，“产品线”可以分为零售、对公、同业等，两者正交则可以得到“零售营销”、“对公营销”、“零售风控”等业务域，当然正交得出的业务域也可以适当调整。
数据中台包含一个“面向主题”的数据仓库（及数据湖）和若干个“面向应用”的业务域。
中台的针对性设计。
减少“数据搬家”和 ETL，因为这会导致削弱系统的鲁棒性，对于中台的内部设计我也坚持同样的观点。数据应该通过最短的加工路径，形成 API 服务向前台交付，所以数据仓库和业务域都应该具备 API 服务能力。
业务域的服务和中台最终交付的服务是存在差异的，这种差异是为了保护业务域的稳定性。无论我们按什么标准划分业务域，也总会有应用场景需要多个业务域参与。所以，在业务域之上还要增加一层，我将其成为“服务联邦层”。
通过“服务联邦层”，我们可以完成服务间的拼接，避免数据复制导致业务域边界的模糊，这种拼接是数据语义上的关联。此外还会对单个服务再加工，隔离应用的特异性和存储数据结构的通用性，这意味着过滤、聚合甚至嵌套子查询。数据语义的加入使“服务联邦层”比标准的服务总线更复杂了一些，更像 Presto 这样的数据联邦产品，但接口是 API 服务而不是 SQL。
最后还会存在一些特殊情况，跨业务域但通过服务拼接无法性能要求，必须通过批量加工完成，我们要专门建立一个区域隔离这种跨域数据加工，称为“数据隔离区”。这里可以汇聚多个业务域的数据，但仅向上层的“数据联邦层”输出。业务域与“数据隔离区”保持单向数据流动，维护业务域的稳定性。
网友评论