再谈数据中台是什么以及MLSQL为什么可以作为数据中台

昨天还是前天，正好看到朋友圈里大家都在发AI前线推的一篇文章。 数据中台已成下一风口，它会颠覆数据工程师的工作吗？ , 个人认为风口谈不上，但是确实是技术发展到一定程度的产物。这里的技术不仅仅是大数据，也是后端，前端技术前进的共同产物。N年前我们是想都不会想这件事情的，因为技术上很难达到。

文章认为数据中台出现的原因是为了弥补数据开发和应用开发严重不匹配而出现的。这其实只是一方面，数据中台真正出现的原因其实是因为人们对数据的渴望，但是这种渴望超出了传统大数据模式（响应式需求，把渴望转化为需求，传达给数据研发，算法，分析师等）能够承受的范围。我个人认为传统大数据的服务模式严重压制了人们对数据的需求，甚至连最简单的【取数】都要以天响应时间计算，所以很多模式要重构。而中台的产生则是这种模式重构的产物。

数据中台我认为应该有如下几个特点

1. 数据中台整合一切内外数据。中台底层的数据组织不再局限于集中式的数据仓库，数据仓库只是中台的一个数据源。中台表现层面的数据形态是联邦制的，大家可以参考我这篇文章： 数据部门起步阶段需要建立数仓么？ ，这里面对数据的整合做了比较详细的描述。

2. 数据中台整合一切内外服务，这种服务形态可以是UDF函数，可以是ET(MLSQL术语，Estimator/Transformer缩写)。在数据中台中，除了传统数据部提供的服务以外，还包括公司内外一切API服务，你可以利用这些API服务帮助你进行数据的探索，加工。这也得益于后端的微服务化，以及类似k8s调度的兴起，让后端抗压能力越来越水平。印证了我前面说的，数据中台是前端，后端，数据发展的共同产物。

3. 数据中台是可编程的。任何托拉拽最终的结局都是无法满足新的需求，需要根据需求开发，所以在中台提供了一个可以涵盖批处理，流式计算，机器学习，提供API开发等统一一致的语言是必要的。同样的，这个语言还要能很好的和其他语言，比如Scala/Java, Python等进行交互和集成。同时，这个编程语言要足够简单，才能面向产品，运营，商务等非技术体系的同仁。

4. 数据中台不仅仅与人交互，还可以和机器交互。这是什么意思的呢？ 数据中台是产品，运营，商务，分析师，后端，前端，算法，数据研发们的日常工作台，同时他们也可以把自己的写的脚本（工作）在数据中台里直接对外提供成API,简单的form表单，从而实现和其他的服务交互。

当然，从数据中台要解决的问题，我是认同前文作者提到的三点的：

1. 效率问题：为什么应用开发增加一个报表，就要十几天时间？为什么不能实时获得用户推荐清单？当业务人员对数据产生一点疑问的时候，需要花费很长的时间，结果发现是数据源的数据变了，最终影响上线时间。
2. 协作问题：当业务应用开发的时候，虽然和别的项目需求大致差不多，但因为是别的项目组维护的，所以数据还是要自己再开发一遍。
3. 能力问题：数据的处理和维护是一个相对独立的技术，需要相当专业的人来完成，但是很多时候，我们有一大把的应用开发人员，而数据开发人员很少。

所以我认为数据中台并不是前台，中台，后台里这样的中台概念，而是一个”中军“的概念。 实际应该是这么一个东西：

image.png

摒弃传统模式，我们应该把前台，后台，以及所有的非研发序列的人，都划分为业务层。 再下面是资源层，包含内外数据，内外计算，所谓内外计算包括前台，后台已经有的API接口，也包括大数据部的各种算法，数据接口。

也就是说，资源层其实是前台，后台，还有人的积累下来的东西，现在我们通过数据中台，以极高的效率重新反哺前台，后台，非研发序列。我们希望前台更加敏捷创新，不依赖后台，而是依赖中台。我们希望后台能进行更好的数据积累，稳步前进，不受前端影响太大，同时从中台获取帮助，从中台获取前台传导的诉求。我们也希望人能更好的和数据，和计算进行交互，并且通过中台更加高效的和前台，后台协作。

MLSQL高度满足前面提到的四个点，并且是按照中太的概念进行设计的一些列产品（目前是三套件）。大家可以参看最新的一些内容：

1. 一键体验MLSQL产品 http://docs.mlsql.tech/zh/installation/docker.html
2. 手动部署MLSQL三套件 http://docs.mlsql.tech/zh/installation/compile.html
3. 产品和运营如何利用MLSQL完成excel处理 http://docs.mlsql.tech/zh/action/mlsql-excel.html
4. MLSQL初学者常见问题集锦 http://docs.mlsql.tech/zh/qa/
5. MLSQL Console介绍 https://www.jianshu.com/p/b75e1a510a76