189 8069 5689
数据中台是整个数据分析系统的灵魂与核心：
对下要对接每个业务系统以及外部数据；
对上要为企业整体决策分析服务，还要为其他业务系统提供数据服务；
对内要服务于企业内的每一个人；
对外服务于上级单位甚至供应链上下游伙伴。
这就对数据中台提出了很高的要求，包括但不限于：
1、数据准确性与可靠性
2、数据统一性：无论是内部还是外部数据是统一的，在不同的时间查询某一特定时间的数据是一致的；
3、数据安全性：严格的权限管理，保证数据安全没有外泄风险；
4、数据可追溯：一旦发生数据错误，能够快速定位错误发生来源，并且知道错误影响范围，包括影响哪些报表，影响哪些人员，哪些人员已经看到了错误数据并做出了决策；
5、良好的解耦性：对于大中型企业，企业的管理相对固定，一般半年到一年有一次变化，但是信息化系统及数据随时可能发生变化；对与中小型企业信息化系统及数据相对固定，但是管理模式及需求随时可能变化，这就要求数据的变化与管理的变化互相不干扰，这才能保证数据分析服务能时时为管理提供“贴身”服务；
6、平滑的可扩展性 ：数据对企业越来越重要，但是企业内数据种类越累越多，数据量越来越大，这就要求数据中台一直处于扩充状态，每次扩充都要在原来基础上实现，而不会对原有架构与业务产生影响。
7、易维护性 ：现代企业对数据依赖性越来越高，已有很多企业报表与分析动辄在几千张，而一般传统企业往往在IT投入很有限，这就要求数据中台必须很容易被维护，比如1-2人维护几千人几千张报表的使用。
因此，数据中台的设计必须遵循一定的原则，否则数据中台的作用无法体现出来，将把数据中台系统建设成为数据仓库系统或者报表系统。
传统数据仓库的显著特点是面向主题的，比如财务主题、客户主题、商品主题，其优势在于同一主题内进行数据分析非常方便且查询效率非常高；劣势在于不同主题之间数据分析非常不方便且查询效率很低，因此现实中为了跨主题使用数据，往往会使得一份数据在不同主题内多次存储，造成了存储资源的浪费与系统维护的复杂度，也使得不同主题内的数据可能无法保持同步。
比如企业想实现客户分析（时间、客户、地区、商品、要求运送方式、实际运送方式、订单单据数量、订货数量、订货金额、发货数量、开票金额、回款金额）、商品分析（时间、商品、订货数量、发货数量、商品成本、毛利）。
如果用数据仓库实现，表设计如下：
客户分析_Fact(时间、客户、地区、商品、要求运送方式、实际运送方式、订单单据数量、订货数量、订货金额、发货数量、开票金额、回款金额)
商品分析_Fact(时间、商品、订货数量、发货数量、商品成本、毛利)，可以明显看出，在两个Fact内，订货数量、发货数量是重复的。
如果用数据中台实现，表设计如下：
订单业务表（时间、订单号、地区、客户、商品、要求运送方式、订货数量、订货金额）
发货业务表（时间、订单号、发货单号、客户、商品、实际运送方式、发货数量）
开票业务表（时间、订单号、发票号、客户、开票数量）
回款业务表（时间、订单号、发票号、客户、开票数量）
成本业务表（时间、商品、商品成本）
其中订单业务表、发货业务表是商品分析与客户分析公用内容，所有业务分析表是平行关系，最后模型层会引用这些业务表。
有三层含义：一是数据抽取脚本的唯一性，比如订单业务表，需要从原有销售系统中抽取数据，这是数据分析不可避免的，但是所有涉及到订单的抽取脚本只能有唯一一份，这样当原有销售系统升级或者其他原因导致数据库变化，进而需要更改抽取脚本时，只需要修改一处即可；二是数据存储的唯一性，比如订单业务表，所有跟订单相关的数据都存储在该表内，在空间、查询效率、维护成本上做了很好的平衡（如果表内数据量太大，可以用分布式存储）；三是指标的唯一性，比如订货数量，所有模型内应该只有一份订货数量，所有需要使用订货数量的报表都要引用该指标，如果确实需要有多个指标，比如预订货数量，一定在指标名称上明确区分，以避免使用者之间产生混淆与分歧。
数据中台与数据仓库很大的一点不同就是对历史数据的处理，一旦数据进入数据仓库，则数据一般不能发生变化；但是数据中台不同，既要保留历史状态，又要保证当前有变化可以对历史数据产生影响，比如前文提到的参照处理方式，数据仓库是在抽取时处理，数据中台是在查询时处理。
数据中台一要把所有分析打平，又要考虑以后的平滑扩展性，因此数据中台建设时更多是考虑原有系统的数据支撑，而不仅仅是当前需求，粒度一般到单据行（同时要考虑数据量问题），这样才能保证能支撑企业以后的深入分析。
由于所有分析打平，所以数据中台不能把所有计算都在数据中台内实现（有的模型需要计算，有的模型不需要计算，而且计算方式可能有差别），而是要进行分层计算。
第一层数据抽取时计算，比如某个订单内某种商品的成本，这要根据采购、库存和成本累积方式进行计算得出；
第二层模型计算，比如订单单据数量，直接在模型上设置公式计算即可；
第三层应用服务器计算，比如某个客户（购买了多个订单，多种商品）在2019年一年内购买商品的所有成本总和，报表计算引擎就会在应用服务器上自动计算得出；
第四层报表前端计算，比如产品利润（收入-成本），报表前端自动计算得出。这样会给予分析展现高的计算效率，同时又能支持应用服务器分离、数据库服务器支持分布。
所有进入数据中台的数据都要进行统一处理。但是数据统一时既要考虑原业务部门需要，又要考虑集团需要。
比如科目体系，集团有标准财务科目体系，各子公司有自己的科目体系，那么集团进行分析时会使用标准科目体系分析，各子公司自己分析时，将使用自己的科目体系，标准科目体系与各子公司科目体系之间存在映射关系。
有些维度不是档案，而是随着业务进行不断增加，但是实际分析时又需要按照这个维度来进行分析，需要进行特殊处理。
比如要求运送方式、实际运送方式，要求运送方式可能是：空运、陆运、快递-顺丰、邮政、快递-中通；
实际运送方式为：空运、陆运、快递-顺丰、邮政、京东，也可能会随着订单有更多的运送方式出现。
要求运送方式实际上以字符的形式存储在订单业务表内，实际运送方式实际上以字符方式存储在发货业务表内。则需要设计一张维度表，运送方式维度（运送方式编码、运送方式名称），其内容为：
此表内容为所有相关业务表内内容的全集（去掉重复的），相关业务表内由存储运送方式名称转为存储运送方式编码，这样才能保证查询时的高效率。
维度表的维护在数据抽取前后程序自动生成与维护，比如按照运送方式查询订单数量与发货数量：
如果用原有方式，查询脚本如下：订单业务表 关联 发货业务表，其中订单业务表有千万行数据、发货业务表有千万行数据，而且关联条件是通过运送方式名称（字符）关联，这个查询效率是很低的；
如果采用新增维度方式，查询脚本如下：订单业务表 关联 运送方式表，还有发货业务表 关联 运送方式表，这样查询效率会高很多。
互联互通社区
互联互通社区专注于IT互联网交流与学习，关注公众号：互联互通社区，每日获取最新报告并附带专题内容辅助学习。方案打造与宣讲、架构设计与执行、技术攻坚与培训、数据中台等技术咨询与服务合作请+微信：hulianhutongshequ