数据中台的设计原则,数据中台技术架构

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