本文旨在探讨数据中心架构的通用设计方法，输出为数据中心的逻辑架构。当然，考虑到业界对数据中台的定义千差万别，可以预见大家可能不会认同本文所设想的中台架构，但我认为每一步的推演过程可能会给大家带来一些启发，或者最后的文件，大家把它看成是疫情期间做的心理体操。1.划清中台边界首先，我们面临的问题域是整个数据系统。本系统是指由数据仓库和数据集市组成的传统生态环境，不包括在线交易系统（如核心系统、理财销售系统）和纯流程管理系统（如业务审批系统）。随着技术的发展，该系统加入了大数据和人工智能的元素，使其更加智能化，但仍侧重于战略和战术层面的数据能力供给，作为决策的权威依据和决定性因素。业务发生变化，但不直接改变业务状态。第一次分解，我们可以先把技术平台和“剩下的”以是否有业务属性为标准进行拆解。这样，从整体架构来看，无论“其余”分解成多少个系统，这些系统与技术平台的关系是一致的，即技术平台提供的支撑能力与技术平台无关做业务，包括数据存储，Processing甚至可以覆盖可视化层面，前提是平台化需要这样的技术能力。第二次分解，我们把前台和中台从“休息”中拆分出来。支持这次分拆的理由自然是“小前台，大中台”，这也是中台建设热潮的口号。前台侧重于灵活性，而中台侧重于稳定性。两者形成一种类似于“换档”的关系。如何理解灵活性和稳定性？我认为一个重要的标准是系统的生产频率。面对需求的变化，前台和中台的生产频率至少应该是2:1，才能体现中台的稳定性。反之，如果每次需求变化都影响到中台，那么中台就会失败。在数据系统方面，通过厘清中台边界，我们形成了前台、中台、技术平台三部分的格局，如下图所示。2.细化中台对外接口。目前我们所描述的边界还是概念性的，比较宽泛，会造成很多理解上的差异。细化接口可以帮助我们更深入地描述中台的期望，从而在组织内部达成共识，所以我们会在第二步做这个工作。技术平台和中台之间有各种各样的接口，但是因为和业务无关，不容易产生歧义，所以我们重点说一下前台和中台的接口。传统上，数据系统的系统接口主要以批处理文件的形式存在。前中台要不要继续这个接口？我的观点是尽量避免使用批处理文件作为接口，多使用API??服务。具体原因如下。批处理文件在自我解释和治理方面很差。在工程实践中，批处理文件的数据和元数据往往是分离的，甚至干脆省略。具体来说，批处理文件通常是仅包含数据的平面文件。在源系统中（可能存在于数据库中），很少在界面中看到“数据项标识”、“名称”、“数据类型”、“备注”等内容。当然，如果我们做得更好，我们也可以在数据治理系统中注册这个接口，但问题是治理系统中“元数据”的正确性与系统的运行完全无关，他们有从来没有真正验证过，也无法确定是否实时更新，因为业务的变化往往让我们在需要根据这些“元数据”做决策时缺乏信心。随着时间的推移，治理系统中的“元数据”不再被使用，成为死数据。相对而言，服务的自我描述要好得多，我们甚至可以在组织内部约定更丰富的元数据，并与服务发布整合。基于架构设计中的服务注册和发现机制，这些服务将受到更强的约束，以保证元数据的质量。前景的灵活性来自于其轻薄的设计约束。业务功能更多的是靠中台的可复用性来实现，文件接口会增加前台堆积数据的可能性，从而无序地扩展前台的边界。创造土壤。我们在系统建设中经常可以观察到一个现象，系统会自驱动，业务会越来越复杂发散。原因很可能是系统的主要利益相关者更倾向于在系统内扩展功能，这样可以降低与外界（技术、业务等）协调的成本。从局部的角度来看，尤其是对于一个特定的需求，这可能是一个更快更好的选择，但总体来说是一种伤害。在哲学层面，问题是局部最优解不一定是全局最优解。追求局部最优解的后果是构建大量筒仓系统，无法积累可重用的能力。中泰的使命恰恰是要从整体上打破或弱化这种建设模式。前台尽量不积累数据，这也消除或控制了其逻辑向复杂和发散演化的可能性。我们可以以较低的成本在更高的管理层面洞察这一演化趋势，并采取相应的措施。服务方式自然满足了控制前端系统积累数据的目的。基于批处理文件的“数据移动”削弱了整个数据系统的健壮性。数据仓库方法论秉承“以空间换取时间”的思想，通过ETL（SQL处理）预处理降低用户查询报表时的计算负荷。这可以实现低延迟交互。为统筹提高整体处理效率，个别报表不按顺序处理，而是合并报表的处理层级，逐层推进共性，逐层推进个性。层。一批（一天可能有2-3批处理批次，一般不会太多）处理结果会在大致相同的时间段内完成。这种方式的缺点是一旦上游数据或基础层处理出现错误，发现错误的时间会大大延迟。单进程查询能发现的错误，需要提前付出大量的批计算成本才能看到。这个过程浪费了大量的计算资源和时间资源（ETL必须在当天完成，所以时间资源也是有限的），甚至导致无法在剩余时间窗口内完成纠错和任务重跑，造成重大对业务的影响。我们应该看到，“以空间换时间”的策略是几年前基于即时算力的权衡。如今，分布式技术的发展带来了实时计算能力的大幅提升。是时候在ETL处理和实时计算之间找到更好的平衡了。我的建议是将部分计算负载迁移到服务上，用分布式计算框架替换部分ETL。中台和前台的接口位于整体ETL的末尾，所以在这里使用服务接口比较合适。另外，我还想说说第三种接口方式JDBC，个人不推荐。一个原因是JDBC暴露了数据源的数据存储结构，加强了前台和中台的耦合。既然我们希望两者在架构层面是松耦合的，那么对于具体的接口我们也应该选择一种匹配的技术。第二个原因是业务语义的不同。RESTFUL服务有一个“有趣”的原则，服务必须有业务语义。直接访问一张表显然不“有趣”，所以JDBC不能称为服务。数据中心平台的对外接口主要是API服务。3、梳理中台内部结构我们继续讨论数据中台的内部结构。根据我们第一步设定的边界，“数据仓库”和“数据湖”必须是中台的一部分。这两个是整个中国和台湾吗？我不认为这就是全部。数据中心不仅仅是数据仓库。数据仓库方法论有两个流派，Inmon和Kimball。国内数据仓库的实现大多采用Inmon方式。具体来说，在数据仓库和数据集市的二元结构中，数据仓库连接上游各个业务系统，按照企业级模型对数据进行重组，消除源系统的特殊性。该模型按照几个主题进行组织，是数据仓库理论体系的核心；在此基础上，数据集市根据具体的应用场景进一步对数据进行处理，以实现最终的功能交付。可见两者的指导思想不同，数据仓库是“面向主题”，而数据集市是“面向应用”。一些企业以前是筒仓式的数据集市，现在把集市中的公共部分压低，节省处理成本，以为这就是数据中心。如果普遍以“能力复用”为标准，似乎数据仓库和数据集市就是中台和前台。那么数据中心是在炒概念吗？我不这么认为。数据中心和数据仓库的区别不在于复用能力，而是因为数据集市还是太重了，无法满足前台的灵活性需求。也是二元结构，因为数据集市不等于前台，所以数据仓库不等于中台。理论上，前端分片数据集市是为了满足一个“业务单元”的数据分析需求。在实践中，这个“事业部”往往对应“事业部”，因为这样一来，业务管控职责明确，可以快速需求边界和财务管理。系统也有直接关系，项目操作比较简单。然而，今天这种方法遇到了挑战。随着数据应用的深入，需求越来越具体，同一部门不同团队的需求也各有侧重。他们都希望保证自己的灵活性，不希望自己的稳定性受到其他球队灵活性的影响。“事业部”呈现明显的“碎片化”。随着业务的“碎片化”，数据集市不断变化，底层逻??辑大量重复。显然，是时候进行结构调整了。说到前台，它服务的“业务单元”更小，但逻辑比数据集市更薄。原来针对“业务部门”的处理，必须要沉淀在数据中心，沉淀的部分也要重新整理。机会。数据中心既是“面向学科的”，又是“面向应用的”。数据中心是“面向主题”的，因为它包含了数据仓库，“面向应用”是因为它包含了数据集市的下沉部分。这里的新问题是如何重组数据集市下沉到中台的部分。重组方法取决于设计者的经验。其实并没有统一的方法。我的建议是按照“价值链”和“产品线”两个维度进行分解，两者正交形成若干个单元，称为“业务领域”。同样是数据沉淀，为什么不以数据仓库为主题，而是创建一个新的“业务域”呢？数据仓库的主题是数据层面的高度抽象，基本不反映业务流程。今天，数据应用的大趋势是加强“一线运营”的数据赋能，必然会更加关注业务流程，而价值链是业务流程的起点；产品是连接企业与用户的桥梁，也是企业运营的核心。“业务领域”是对业务流程的抽象，可以说是“面向流程”，其实质是“面向应用”。“业务域”数据模型不像数据仓库的“主题”那样严格去冗余，一些维度信息会重复出现，比如客户基本信息、组织信息等。以银行为例，“价值链”上的典型环节包括营销、运营、风控等，而“产品线”又可以分为零售、企业、同业等。当然，“企业营销”和“企业营销”等业务领域零售风控”也可适当调整。数据中心包括一个“面向主题”的数据仓库（和数据湖）和若干“面向应用”的业务域。4、面向非功能需求的设计到目前为止，我们只是从数据结构上讨论了中台的组成，没有考虑系统的非功能需求。事实上，前台的非功能性需求在不同的应用场景下会有很大差异，最有代表性的就是对并发和延迟的需求。因为我们已经约定了中台和前台的接口是API服务，所以这些需求会直接传给中台。接下来说说中台的针对性设计。第二步，我给大家的建议是减少“数据移动”和ETL，因为这会导致系统的健壮性减弱。我对中台的内部设计也持有同样的看法。数据要经过最短的处理路径形成API服务，交付给前台，所以数据仓库和业务域都应该具备API服务能力。数据仓库本来主要是批量处理，以文件的形式输出。考虑到API服务绝对是一个很大的挑战。设计一个被业界广泛使用的主题模型，在我看来其实是有点玄学的，但是既然有那么多公司在实践，我们还是先认同，但是说到改造这个模型，实在是无从下手。在找到兼顾两者的方法之前，我更愿意保持原样，这样可以使用成熟的实现方法。毕竟，继续在数据仓库上下功夫，会有不错的回报。我们可以让数据仓库在现有的架构上提供一些兼职的API服务，适合那些对延迟要求低的应用场景（比如一些报表查询），如果不能满足，在上层区域重新构建??这些服务要求。业务域的数据结构是“面向应用”的，因此有更好的提供API服务能力的基础。对于常见的查询场景，可以选择兼顾批处理性能和在线查询性能的存储产品，比如MPP数据库或者HTAP数据库。高可靠低延时场景（比如反欺诈，反洗钱，数据查询结果是阻断异常转账的基础，对时延要求极高），可能是两种存储产品的结合，提供批处理和在线访问功能。在线查询可选择K/V数据库（如HBase）或分布式数据库（NewSQL）或分库分表方案（MyCat或更好的方案），总之是一种更接近于OLTP的存储系统。存储产品的组合必然会带来数据冗余。这种冗余虽然也需要数据搬迁，但是不会带来业务逻辑的重叠，不会偏离我们的设计理念。业务域的服务和中台最终交付的服务是有区别的。这种差异是为了保护业务域的稳定性。不管我们用什么标准来划分业务域，总会有应用场景需要多个业务域的参与。因此，在业务领域之上多了一层，我称之为“服务联邦层”。通过“服务联邦层”，我们可以完成服务之间的拼接，避免数据复制带来的业务域边界模糊。这种拼接就是数据的语义关联。此外，对个别服务进行了返工，隔离了应用的特殊性，存储了数据结构的通用性，即过滤、聚合甚至嵌套子查询。数据语义的加入使得“服务联邦层”比标准的服务总线复杂了一点，更像是Presto这样的数据联邦产品，但接口是API服务而不是SQL。最后，还会有一些特殊情况，不能通过跨业务域的服务拼接来满足性能需求，必须通过批处理来完成。我们需要建立一个专门的区域来隔离这种跨域的数据处理，我们称之为“数据隔离区”。来自多个业务领域的数据可以在这里聚合，但只输出到上层的“数据联邦层”。业务域与“数据隔离区”保持数据单向流动，维护业务域的稳定。这样，我们就得到了一个完整的逻辑架构图。5.结语整个架构设计过程中应用了一些基本原则，这也是我个人对数据中台的理解，包括以下几点：中台要有业务属性，中台要比前台更稳定桌子;尽量减少ETL处理，引入分布式技术进行实时计算，提高系统的健壮性；API服务接口优于文件和JDBC接口。中台内部多层次提供API服务，通过服务集成减少跨域数据集成。作为一家人，希望能和大家多交流、多讨论。6、作者介绍王磊，光大银行企业架构师，Pharos架构设计及主要开发人员，曾在IBM全球咨询服务部从事技术咨询工作。目前负责全行数据领域系统的关键架构设计、评审和内部研发，对分布式数据库、Hadoop等基础设施的研究有浓厚的兴趣。
