经过几天的奋战，数据中台节点终于尘埃落定，权限认证、多线程跨页数据获取、查询构造器等一系列功能均已实现。什么是数据中台，为什么要数据中台呢？数据专家中的数据中台节点又是如何运行的呢？
一、为什么要数据中台
一直以来，在传统企业中，数据建设不那么起眼，也不那么受关注，把数据模型做好，把数据充填进去就行了。这是一种典型的静态建设思路。这种方式，太过依赖于顶层设计，时代在变，技术在变，企业里新的数据新的需求不断涌现，数据库的模型也得跟着；其次是数据模型不敢变，上面挂接太多应用，变了诸多系统就不灵了；最关键是数据建设是幕后工作，走不到台前，不被观注，出不了成果，要不来投资。因而，造就了企业级数据建设，以不变应万变的差不多先生的局面，直至有一天，天塌下来，推倒重来了。
数据中台的意义就在于以新应新、以变应变，以动态的思路开展数据建设工作。它介于数据库与应用系统之间，可以将数据中台，理解为企业级的数据应用标准与规范，应用时只需关注数据，而不必关心其来源，其主要作用有三点：
数据与应用的中介。数据中台是数据库与应用之间的中间人，起中介作用，话事人的作用。中台旨在减少数据与应用之间的耦合度，让两大体系不致于因步子跨太大而扯到裆。
企业的数据外交官。多源头的数据之间存在差异，应用者的数据理解有差异，使得数据口径不一致。设计阶段数据与实施阶段的不一致，实施阶段与生产阶段的不一致等。通过中台，统一对外数据规范与口径。
划清工作界面。可以将数据中台理解为数据库的微服务化，它是一个与具体数据库无关的服务。应用系统建设者，不必操心数据存放位置、数据的权限，将精力集中于应用功能开发中，无形中减少了项目的运行成本，为企业节省开支。
二、数据中台节点
数据中台节点提供一个访问数据专家数据中台系统的入口，通过可视化的方式，将数据中台系统中的数据引入数据流程中。其主要功能有三个：
- API列表，以列表方式展现了数据中台中的可用数据服务。
- 权限认证，提供数据访问权限认证功能。
- 查询条件构造器，用可视化的方式构造一个访问数据中台的URL地址。
数据中台从应用的角度来讲，就是一个数据服务地址，数据中台节点的所有功能就是为了构造这个URL地址。URL是一种特殊的字符串，它通过一定的规则，将数据查询的关键字与值组合而形成查询条件。 除了查询条件构造器来构造数据访问语句之外，我们也可以依据规范手工编写查询语句。
数据查询规范如下：
1. 大于等于
格式：>{Field}={Value}
示例：/rockstars?>day=24
2. 大于
格式：{Field}>={Value}
示例：/rockstars?day>=24
3. 小于
格式：<{Field}={Value}
示例：/rockstars?<day=24
4. 小于等于
格式：{Field}<={Value}
示例：/rockstars?day<=24
5. 集合枚举
格式：{Field}In={Value1},{Value2},{Value3}...
示例：/rockstars?dayIn=23,25
6. 界于之间
格式：{Field}Between={Value1},{Value2}
示例：/rockstars?dayBetween=23,25
7. 以...开始
格式：{Field}StartsWith={Value}
示例：/rockstars?dayStartsWith=2
8. 以...结束
格式：{Field}EndsWith={Value}
示例：/rockstars?dayEndsWith=2
9. 包含字符
格式：{Field}Contains={Value}
示例：/rockstars?dayContains=2
企业级的数据建设，涉及面广，体系庞杂，貌似高不可攀，其实近在咫尺。建设者的思路决定建设思念，思维差异决定了系统走向。两种建设思路的较量，没有对与错之分，只有与企业现状的吻合度的差异。以不变应万变一劳永逸，是理想，是梦想。而以变应变则是现实，是人生常态。
