老板要建中台，这些脏活儿累活儿，都得程序员来干？

1

一次聊天

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

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

他反问道&＃xff1a;“我们CDO也是你这个调调&＃xff0c;好什么好啊&＃xff0c;数据驱动&＃xff0c;数据在哪里儿&＃xff1f;”

我说&＃xff1a;“你们有ERP&＃xff0c;有CRM&＃xff0c;有关系数据库、Kafka、Hadoop、数据仓库、S3吗&＃xff0c;这么多数据&＃xff0c;还不够你用的&＃xff1f;”

他说&＃xff1a;“就是数据太多、太杂&＃xff0c;本地有&＃xff0c;云端有&＃xff0c;一团乱麻&＃xff0c;数据资产没有梳理过&＃xff0c;数据没有治理过&＃xff0c;怎么做数据驱动啊&＃xff1f;

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

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

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

2

数据治理

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

想实现数据驱动&＃xff0c;必须得把数据治理做好。

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

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

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

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

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

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

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

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

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

3

谁来牵头&＃xff1f;

大家可能要问了&＃xff0c;那把这些东西做出来不就行了&＃xff1f; 

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

IT部门&＃xff1f; 他们只负责最底层的存储和计算&＃xff0c;管不了那么多业务。

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

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

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

朋友说这些都是脏活累活&＃xff0c;他可不想干。

我给朋友说&＃xff1a;“你们别费劲了&＃xff0c;干脆请外边的咨询公司来做吧。”

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

所以有人说&＃xff0c;数据治理治不好是常态&＃xff0c;治好了才是奇迹。

4

敏捷破局

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

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

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

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

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

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

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

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

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

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

用户可以按照自己的需求&＃xff0c;把各个数据源的数据进行编目&＃xff0c;形成数据目录&＃xff08;Data Catalog&＃xff09;。

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

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

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

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

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

对云计算感兴趣的同学&＃xff0c;亚马逊云科技re:Invent是必须要关注&＃xff0c;而且要重点关注的活动&＃xff0c;因为这里会发布的业界最前沿的新产品、新观点、新技术&＃xff0c;每次都会突破云计算的边界&＃xff0c;re:Invent活动非常多&＃xff0c;12月20号&＃xff0c;亚马逊云科技会在线上举办INNOVATE大会&＃xff0c;对2022亚马逊云科技 re:Invent做深度解读&＃xff0c;详解端到端的数据战略及未来基础架构。

这相当于一个精华版了&＃xff0c;几个小时就可以领略最前沿的云计算技术&＃xff0c;不容错过啊&＃xff01;

扫描下方二维码或者点击阅读原文即可参与&＃xff01;