接上一篇业务洞察——从人货场提炼电商数据指标
数据指标体系已经提炼好了，接着就是想办法落地实现。现在数据中台是个流行词汇，在技术思维里，重复的逻辑会被抽象为组件、服务或者系统，系统这个层级都包不住的，可以上升为中台。数据中台，顾名思义，是要对外(也就是多个使用方)提供统一的数据服务。我把数据中台的建设简单的划分为数据建模、数据采集、ETL以及数据分析四个阶段，这四个阶段形成良性的迭代循环，推动整个数据中台的持续进化。
数据建模里的模型通常指的是多维模型，多维模型由事实表和维度表组成，我们要建的第一个多维模型是商品订单模型，事实表里添加销售额、毛利额、销售件数这三个度量，毛利率作为计算指标可以在数据分析阶段再做处理。维度表精选了商品、用户、渠道、场景、时间、订单这6个，很显然，订单作为维度表是不合理的，膨胀的速度太快，需要把是否首单这类有价值的数据合并到事实表中。在前面提炼指标的时候，我把渠道和场景放在了一起，实际上渠道和场景之间是并列的关系，不是隶属关系，在这里需要拆分成两个维度表。
我们要建的第二个多维模型是商品流量模型，事实表里添加商品展示次数、单品页PV、加车次数、下单次数、支付次数、支付金额这6个度量，UV、点击率、转化率、客单价作为计算指标放到数据分析阶段再做处理。维度表与商品订单模型一样，精选了商品、用户、渠道、场景、时间这5个。
多维模型建好之后，需要尽快确认上游数据是否存在，在这两个模型里，需要的上游数据主要有订单交易流水、流量日志、商品配置数据、商品成本数据、运营费用数据、渠道配置数据、场景配置数据以及用户画像数据。在这些上游数据里，订单交易流水、商品配置数据、商品成本数据一般都会比较齐全，流量日志、渠道配置数据、场景配置数据、以及运营费用数据通常会比较散乱或者缺失，用户画像数据则可能根本就没有。在这种情况下，我们需要对模型进行精简，先实现能找到上游数据的度量和维度，同时开启支线任务去推动完善上游数据建设，这就是前面提到的迭代循环。
找到了上游数据源，接下来就到了秀技术能力的时候，先不讲技术细节，我们继续抽象，上游数据源和目标数据模型之间的差异很大，直接用ETL一步到位，很容易被噎着，还会牺牲系统的稳定性和模型的可复用性，基本上每新建一个模型都得从源头上开始全程来一遍。所以需要在中间添加一些处理层，按照标准的数据仓库建设流程，一般会在中间抽象出两层，ODS层和DW层，ODS层会把各个异构数据源中的相关业务数据都抽取上来，一般不做清洗和转换，以保持与源数据的一致性。ODS层的数据经过各种清洗、转换和计算后，按照多维模型的形式进入到DW层，俗称的大宽表就在这一层，像每笔订单中每个商品的成本计算结果、费用计算结果和毛利计算结果都在这一层存着。在DW层之上再进行汇总和处理，就进到了目标数据模型层，这一层一般被叫做DM层或者APP应用层，到了这一层之后，为了方便后续的数据分析，也可以把这一层的数据存储到关系型数据库中。在之后就是数据分析，在数据分析这个环节，可以使用成熟的商业产品，像观远的BI就非常好用。
简单的总结，我们可以把数据中台简化为这个四层结构，越往下就越稳健，越往上就越灵活可变。这个层级结构可以把整个数据中台的维护成本降到最低，在数据分析层，借助像观远BI这样的成熟商业产品，只需要极少数的数据分析师，就能够支持业务部门绝大部分的日常数据需求。维护成本降低后，就可以把数据组从之前繁琐的报表开发工作中解放出来，投入到能产生更大价值的工作中，比如可以去持续的改进数据模型，优化集群性能，将更多的业务数据源纳入到数据中台，同时还可以去推动上游数据从源头上加强建设。(技术实现后面展开讲)
