【引言】：
在笔者作为供应链业务的角色时，经常需要针对特定场景，进行分析并解决业务问题。
在A公司的物流部，公司当时没有大数据平台，只有数据分析认知能力的笔者，遇到了跨数据库抓数卡壳的尴尬。举例说明，商城订单在MYSQL的OMS里，运单在ORACLE的LMS里。当商城的老板派遣其数据分析伙伴来找物流部对运单账单明细的时候，大家就尬住了。跨数据库关联取数毕竟还是没有同一个数据库跨表关联便捷。
在B公司的供应链运营中心，集团老板尤其看重数据安全，权限收口，集团有专门的BI团队提供取数服务，且提需求需要业务明确口径与数据来源。那么一个先有鸡还是先有蛋的问题就来了，业务哪里会熟悉数据库以及表结构呢？经常发生等了一周数据出来以后发现并不能满足业务需求；当口径和来源逐渐依靠试错沉淀下来，高频取数需求转化为报表开发需求时，不同部门/BU一开会，精彩又来临了。因为不同部门同一指标的口径以及来源难以统一，加之每一个报表的沉淀背后都有一个曲折或忐忑的故事，所以大家基本都只信自己的报表。万般无奈之余，当需要统一时，只能统一以财务口径为准。
不论是数据分析还是提报表需求，顺畅的数据清洗加工体验那基本是不存在的。区别只是在于梗在哪里以及梗多少次而已。
【一个概念两个工具】：
机缘巧合+主动争取，目前笔者有幸从事大数据在供应链行业的应用。解决问题的角度也从数据分析延伸为数据治理以及大数据开发。相信但凡是将数据作为资产来对待的公司，都会需要了解领域建模的概念。手动画图（领域划分/脑图/ER图）之余，有幸接触到指标梳理工具，可以将其沉淀为企业数据资产。这两个产品分别是JD EASY 系列的EasyModel以及阿里的Dataphin。
先来看一下JD的EASY MODEL。
因为京东的产品分为研发产品以及业务产品，所以其产品设计的方法论也根据职能进行了划分。其主要思路是在领域以及主题划分完成之后，BI伙伴将维表以及明细表开发好，供业务根据自身多元的需求灵活加工产生派生指标以及汇总表。
可能是由于先入为主的原因，又可能是EASY MODEL产品运营团队耐心的培训，以及产品覆盖的功能从核心功能逐期开发，EASY MODEL的概念还是比较适合零售场景以及容易吸收的。
产品界面简要图示如下：
再来看一下阿里的Dataphin.
说到数据治理，那自然绕不开阿里云以及阿里的数据中台产品Dataphin。
通过阅读产品文档中【使用教程】中【面向零售店铺的模型建构与管理】...恩，不知道是巧合还是同行们心有灵犀，EASY MODEL同该章程的建模部分基本一模一样...
不同的是从操作上来说，EASY MODEL有托拉拽；
从功能上来说，dataphin还有完善的调度管理以及质量管理功能。
那看点不同的，通过阅读产品文档，了解到其数据【萃取】功能模块主要如下图，其中【行为中心】是从对象的角度（案例中为人）的视角来命名各个规范，除此之外，还延伸了【标签中心】的功能。
那从建模到萃取看起来流程以及概念都不一样，是不是建模的方法论就不一样了呢？同时去了解两个功能会不会占用很多认知成本？
条条大路通罗马，笔者认为，治理的理念和流程是类似的，只是名称不同而已，下图列出笔者目前理解的俩个功能不同名称/概念的映射。若有偏差，欢迎打脸。
从产品的产出，也就是行为看板所展示的内容来看，dataphin不仅仅是生成了汇总表，并且连可视化展功能一并包涵了。萃取-建模-展现一条龙。
时间有限，对两个产品的认知还不够深入，本次主要聚焦于其数据治理的核心方法论进行了初步的认知。也激发了笔者关于如何依托此类工具进行对象维度的领域建模的思考。
最后，希望多一些类似这两款提高数据治理以及大数据开发效率的产品，因为这意味着可以减少许多不必要的BI开发产品文档。
