一次聊天

最近和一个搞开发的朋友聊天，他说他们公司要做数字化转型，成为一个数据驱动型的企业，还新设了一个什么首席数据官(CDO)。

我附和说：“这很好啊，数据驱动是未来的趋势，人家福布斯统计过了，85%的企业都希望转型为数据驱动型，更好更快地决策，你们公司早就该这么干了。”

他反问道：“我们CDO也是你这个调调，好什么好啊，数据驱动，数据在哪里儿？”

我说：“你们有ERP，有CRM，有关系数据库、Kafka、Hadoop、数据仓库、S3吗，这么多数据，还不够你用的？”

他说：“就是数据太多、太杂，本地有，云端有，一团乱麻，数据资产没有梳理过，数据没有治理过，怎么做数据驱动啊？

比方说，公司想知道下一个项目应该往哪个产品投资，往往需要财务数据，产品销售数据，社交评论数据，用户数据等等，把这些数据给整合起来才能做决定。

但这些数据存在于不同的系统中，需要ETL(提取、转换、加载），有些数据（如用户数据）还需要审批以后才能使用，处理起来很麻烦。

这仅仅是一个需求而已，如果需求很多的话，即使把IT部门累个半死也满足不了业务方的需求。”

数据治理

我心说他真是遇到了业界的一个大问题。

想实现数据驱动，必须得把数据治理做好。

数据治理需要梳理数字资产，以安全的方式来使用数据，从而获得更好的业务目标。

我们需要把来自不同部门，不同系统的底层数据做封装，形成公共的数据和服务，让前台的业务部门去使用。

这么说还有点抽象，不好理解，朋友曾给我说过一个做菜的例子，形象又有趣，给大家分享一下。

你厨房里（IT部门）有油、盐、酱、醋、生抽等各种调料（它们就相当于各个部门的数据），现在业务部门想吃糖醋里脊，你就需要调制糖醋汁出来，调制过程比较麻烦，比例不对味道就变了。

所以你想了招数，事先按比例调出一大桶糖醋汁，以后业务部门想做糖醋里脊了，直接给它倒点儿就行，很方便。

其他业务部门想吃糖醋鱼、糖醋排骨，糖醋xxxx，也都可以用预先做好的糖醋汁。

这个糖醋汁就是数据治理中一个可以共享的、公共的数据产品。

除了糖醋汁，还有高汤、各种浇头、卤汁等各种“数据产品”。最近几年流行一个词“数据中台”，其实也就是这个意思。

我朋友公司遇到的问题就是他们只有调料，没有糖醋汁、高汤、卤汁......

谁来牵头？

大家可能要问了，那把这些东西做出来不就行了？

这就是问题的关键所在，企业业务千变万化，各有不同，每家都需要定义属于自己的、独特的公共数据，形成数据中台，但是谁来牵头做这件事儿呢？

IT部门？ 他们只负责最底层的存储和计算，管不了那么多业务。

业务部门？他们也主要关注自己的一亩三分地，给IT部门提需求，很难去定义全公司级别的公共数据。

公司可以搞一个专门的机构来做这件事，从全局出发，定义数据治理的规范、标准、策略..... 也就是说，事先把糖醋汁、高汤、卤汁等所有的公共数据统统都定义出来。

这么做最有成效，但是可以想象得到，当你做一件不能很快看到价值的事情的时候，阻力非常大，想要得到别的部门的配合都很难。导致落地成本非常大，周期也非常长。

朋友说这些都是脏活累活，他可不想干。

我给朋友说：“你们别费劲了，干脆请外边的咨询公司来做吧。”

他笑了笑：“咨询服务动辄百万起，我们老板这么抠，恐怕不会去请咨询，关键是咨询公司也不一定能做出很好的东西......”

所以有人说，数据治理治不好是常态，治好了才是奇迹。

敏捷破局

其实，退一步海阔天空，暂时放弃那些大而全的规范、标准、策略，从实际问题入手，数据治理还是有可能从一个较小的范围启动起来的。

换句话说，如果需要糖醋汁，我们先把糖醋汁给调出来，先别管其他的什么高汤、卤汁之类。

市场部门需要销售部门的每周的数据汇总，那就先把这个数据给提取出来，形成API，让市场部门去用。

这样就在市场部门（数据消费者）和销售部门（数据生产者）之间，建立了一条线，并且有了一个公共的数据“每周销售汇总”。

这个数据就像一个手机充电头，不但市场部门可以“充电”，别的部门将来也可以用。随着时间推移，这样的充电头就会越来越多，就会形成一个小型充电站，数据治理也就基本完成了。

这是一种需求驱动的敏捷方法，不过，敏捷的方式需要敏捷的工具。

这个工具应该支持数据生成者迅速地把自家数据形成一个Schema，定义好有哪些字段，字段的具体含义。并且定义好哪些组织，什么人可以访问，消费者看到以后，就可以直接使用。

我知道亚马逊云科技最近就推出了这样一个工具，叫做Amazon DataZone，它的架构是这样的：

使用Amazon DataZone，可以轻松地创建起公司的组织结构。

前面说过，公司的数据可能来源于数据仓库、数据湖、流数据、关系数据库、第三方系统等多个地方，亚马逊云科技提供了一个叫Amazon Glue工具，可以轻松地发现、集成来自多个数据源的数据，并且可以对数据进行提取、转换、加载(ETL）。

用户可以按照自己的需求，把各个数据源的数据进行编目，形成数据目录（Data Catalog）。

有了数据目录和组织结构做基础，每个部门就可以根据需要来创建属于自己的业务术语，元数据，从而建立自己的数据资产。

数据资产一旦发布出去（当然，需要设置好权限），别人就可以查询了，Amazon DataZone 专门提供了一个门户（Portal）对数据资产进行查询，非常方便。

利用这种方式，可以迅速地对接生产者和消费者，把数据资产创建起来，马上投入使用，从而实现快速响应业务需求，应对市场变化。

沉淀下来的数据资产还可以继续被别的消费者使用，随着这样的数据资产越来越多，大家都看到了业务价值，数据治理就会走上正轨。

如果你的公司有数据治理的需求，不妨考虑一下这样敏捷的方式，利用Amazon DataZone这样敏捷的工具，先小范围启动，慢慢积累，最终修成正果，完成转型，成为真正的数据驱动的企业。