2019-06-05 10:50

大家好，我是来自东方金信的付威，今天给大家简单介绍一下数据中台如何快速支持业务场景。昨天的分享会上给大家说了一下，讨论了数据中台如何做，其实没有很明确的说法，我这里介绍一下数据中台在我们实践过程中的一些思路，抛砖引玉。

    首先数据中台的概念是起源于互联网领域的，明确说是起源于阿里。以前不叫数据中台，最早叫中台，中台又分业务、数据中台。我在传统互联网行业做过很多年，我非常理解为什么互联网领域提出数据中台概念，实际上它最主要的需求是快速，快速的支持业务模式。我们传统的话做数仓也好、大数据也好，做一个项目，比如在大数据平台上做一个应用，通常要三个月，要做ECM或者风控要5个月的时间，这在互联网行业是根本不可以接受的。可能8个月钱都烧完了公司要关门了，它的要求是一定要快。

    第二它的生命周期是非常短的。我们做互联网行业做的时候应用很简单，也可能这个应用是即用即抛型的，拿来用，可能半年之后就不会用这个了。第二应用的生命周期越来越短。

第三大数据技术产品越来越多，大数据团队的人也越来越多，很难协调一个产品的开发，协调资源是非常多的。所以企业对数据中台的需求我们总结出来3点：

1、要快速构建应用；

2、减少人力成本；

3、数据应用效能是不变的。

    在中台上举一个例子。在二战的战争前线人是非常多的，都是几万人作战，但是现在的作战前线是人可能很少的小分队，但是它的作战效能是不变的，因为它能呼叫远程空中火力包括各种支援，它的效能是不变的，这就是数据中台产生的背景。

东方金信基于这样的背景，包括各行各业的经验总结出来数据中台的定义是这样的：首先数据中台是必须建立在标准的大数据基础环境之上的，同时为业务应用提供数据解决方案的一系列服务与组件的集合，以及与开发相配合的组织架构和流程。

在这里我们把数据中台和数据后台分开了，我们说的更多的包括数据开发、运维、建模，我们常见的清洗也好，我们认为这是数据后台的工作，这个人是非常多的，我们把这种标准大数据的规划建设、统一的存储建模开发运维统称为大数据后台。大数据中台干什么？有两个：一是服务组件，第二有组织流程。通过服务组件、组织流程快速支持前台作用。前台只有一个前台，这一个前台上是由业务前台和数据中台和业务中台组合而成的。在我们这个理论想法的基础之上，我们规划出了整个东方金信大数据的产品架构。今天重点不是介绍东方金信大数据的产品架构，但是这里简单介绍一下。

    下面有个云数据的容器平台，未来用安全云容器，上面有海盒大数据基础的存储平台，包括海盒大数据和海盒流计算引擎，包括数据库、数仓数据库、图数据库和对象存储，一个企业至少是五六个以上的存储来解决大数据的存储。在这之上是海盒数据资产管理平台包括行业数据库和数据资源目录，这个数据资源目录和大数据有时候会混淆，这个通常在政府机关用的比较多，因为它的委办局特别多，数据差异性特别大，所以会有资源目录的场景。还有元数据、数据质量、数据标准、数据安全、数据周期和数据产品工厂，这会在另外一个会场中介绍这几个产品。这里重点提一下关于元数据，元数据的重点是影响分析，里面很重要的问题是影响分析爆炸，如果做三层分析一下子几万张表都会受影响，我们在这里已经把这个问题解决了，精细化，在这里就不细谈了。

    左边是海盒同步平台包括共享数据交换和任务项目处理，这上面是海盒大数据分析平台，包括分析套件和全终端的BI套件，在此之上还有海盒人工智能平台，包括自然语言处理、搜索引擎、图分析工具等等。这些下面说的没有圈出来的都认为是数据后台要管理的事情包括存储、管理、同步、开发、加工等等这些功能，这些对外输出是称之为海盒数据中台。上面有两个组件介绍一下，一个叫做数据服务，还有一个数据应用构建器。这两个组件会构建出数据中台的组件，包括自动分析、标签管理、位置服务引擎、外部数据管理。这个外部数据管理可能一些企业都会用到，比如爬虫、外部数据收集、企业上传数据等等。还有指标管理、企业和政府的知识图谱，还有一个引擎。这就是数据中台在整个海盒大数据产品架构中的背景。

    接下来重点介绍其中几个组件，介绍最重要的两个组件是数据服务和应用构建器。通过这两个组件可以快速的完成前排应用的快速构建。我们说底层数据刚才提到大数据平台上最少得几万张表，多的几十万张表很正常，上百万的字段，下游的应用是没法用的，他会问表存在哪儿、怎么存的、怎么取，下游的程序员思路是开发的思路和数据人员的思路不太一致，还要解释。这时候我们把下面的数据服务封装成标准的API接口，现在都是微服务的架构。在微服务架构中有个特点，是在这里自己研发了一个叫SchemaQL的语言，因为如果基于几万张表都做接口的话会做好多接口，我们把基于企业级模型做了一个SchemaQL语言，这样用起来就非常简单了，接口并不多，上面直接访问就可以了，这是数据服务的应用；

    还有一个是数据应用构建器，是右下角的工具，通过web搭一个应用可以很简单，跟传统的不一样。传统是搭前端，这上面每个组件，连服务接口带前端组织，一个身份验证组件一个流程组织，拖过来就可以了。而且这个组件是可以组装的，一个风控组件是好几个技术组件搭起来的，现在审批组件都搭好了，接口输入输出都可以了，只要把用户ID传进去，其他都不用管了，这样简单的应用构建器很多，我们搭了一个简单的应用支持业务员到前线看一下，看一下这里面有什么，这里面把身份验证组件拿过来，业务信息一匹配，一个应用很快的做出来了，小时级就把应用构建出来了。同时这个应用也不需要部署到一个应用服务器上直接在线发布就可以了。当然它的应用构建器和数据服务是数据中台的核心。

    除此之外我们也提到了，还有标签管理、自助分析等等，这些应用可以算是前台应用，但是为什么归为中台应用呢？实际上中台应用是服务组件结合，但是中台开发出来不能让前台验证，得自己验证，我们也构建中台应用验证核心组件的应用，同时也是服务高级用户。前台应用可能给普通的业务人员在前线使用，但是有些高级应用要自主分析，自己标签挖数、自己做知识图谱分析直接进来就可以了，也可以在平台上直接用。同时现在这里列了6个中台的应用还在不断丰富中，包装出来一系列的中台的组件就可以做一套相应的中台的应用，中台的应用不断丰富和扩展。

    除此之外，昨天开会有几个专家说的特别对，有了工具这个问题也解决不了。中台的问题，一定是组织流程、组织架构跟着变才可以，传统的中台可以看到开发团队、运维团队、模型团队等等，一个大数据团队至少一二百人，下游接口根本找不到要对接哪个人，找到之后协调人时间是非常长的，所以我们在这里推荐一些企业构建专业的数据中台团队，是在大数据团队当中，同时又面向业务，同时要向整个大数据团队反馈业务需求实现快速迭代。通常有了这样的工具、这样的组织也在流程上发生一些变化，传统就算是敏捷式开发，大数据团队收到一个下游业务需求，从立项在需求平台存需求，再分析有没有，后面模型改造改造，再把调度加上去，后面再做应用，有可能做一个流对接接口弄出去流程快的也得两三个月，这是不行的。我们流程有了这样的工具直接在平台上快速构建，灰度验证，然后在线发布，这样基本上一个中台应用在周以内，只要提出想法到发布出，基本在几天甚至一周内快速的中台应用就被发布出去了，我们称之为轻应用。传统应用可能在脚本上改个注释至少得好几个月时间，但是现在轻应用都是天级应用的发布。这也是规划流程上的变化。

接下来讲两个案例，中台支持客户的案例。

1、我们在某政府做政府热线12345热线，提高热线办公效率。因为政府热线接电话的人一般是外包，素质不是特别高，但是政府业务非常复杂，涉及到委办局特别多，政府自己的专家都讲不清楚，这个市民打过来的电话都不知道该找谁，这时候我们做了政府的知识图谱，把政府的语料库、知识图谱分析，结合语音识别的服务和数据服务接口快速构建了一个应用，市民打进来电话的时候一般通过语音识别、知识图谱分析，给他推荐出这个业务应该找哪个委办局的哪个负责人，快速把这个问题分派下去，这时候也是为政府的服务提高了市民的满意度。

    2、某燃气公司做采销负荷应用。燃气公司现在跟电网一样，是属于网销分离的模式。所以燃气公司对自己燃气负荷的销售预测需求是非常迫切的，以前基于他们自己的系统很难做出准确的预测，我们通过中台快速组装后台产品包括机器学习套件、数据服务、外部数据管理、标签管理，做了一个采销负荷管理的应用，预测整个城市燃气从年、月、日甚至小时级的燃气，因为爬虫爬来还要给城市打标签，我们在5个城市做了落地验证，不同城市燃气的用法是不一样的，给城市也归了类，有工业型、生活型、综合型城市，而且有南方、北方的城市，我们做了分析，预测准确率还是比较高的。基于整个数据中台的产品，支持了工业企业这样一些业务的场景。

    前面简单介绍了一下东方金信在数据中台的思考，包括一些产品以及在业务场景中的应用。东方金信公司成立时间不久，2013年成立，也是传统大数据行业里的专家们组成的创业公司，现在也是中国大数据的五百强企业，这个不再详细介绍了。