如何围绕MLSQL构建数据中台
MLSQL 目前开源的部分包括三个组件：
- Console, 也就是Web控制台
- Cluster, 方便管理和代理后端多个MLSQL Engine实例
- Engine, 相当于MLSQL的JVM(脚本解释器)
同时，Engine还内置了一个非常简易的Scheduler。不过仅仅靠这三个项目是远远难以达到中台水平的。那还欠缺什么呢?
- 元数据中心
- 统一登录平台
- 权限控制服务
- 调度系统
- 日志系统
- 监控报警体系
看到这里，大家会想，这些不是老生长谈么，哪个大数据平台或者体系缺的了这些。当然了，从架构上讲，大部分成熟的大数据体系都需要包含这些组件。但是以前，我们会在各种开源系统里挑选每个领域里的组件，然后把他们拼凑起来（比如自己写胶水代码，系统）从而使得其成为一个完整的系统。大家的实力主要比拼在胶水系统的水品已经对各个开源系统的定制能力。但是，你会发现，这对于大公司其实是OK的，但是对于很多中小公司，你的系统很难处于一个“易用”的状态，核心原因是这些系统都是以自我为中心，形成合力是比较困难的。而MLSQL要求这些组件，都是围绕MLSQL Engine而生的，必须能够对接MLSQL,这样，我们可以形成一个更加高效的体系，并且减少成本。当然，因为MLSQL Engine本身高度的可扩展和丰富的接口，也让你开发这些服务变得更加容易。我们来看下，上面我提及的系统分别应该怎么设计。
元数据中心
元数据中心一般采用传统数据库，比如MySQL，不过我推荐不妨尝试下TiDB,因为元数据往往也非常庞大。但是一般而言，较高配置的单机也能Cover住很多公司的元数据量了。通常，元数据有build-in 和external两种模式的数据来源。 buildin主要是存在元数据自己的存储介质里，而external模式，则属于代理模式，经过元数据转发到其他的“垂直元数据”系统里
元数据包含的信息有：
- 任何MLSQL Engine实例启动或者关闭，以及启动相关的配置参数或者启动后需要的一些元数据都需要在元数据中心里存储。在这里，你可以获取到MLSQL Engine的大部分部署运行信息
- Schema信息，包括hive所有库表以及schema信息，此外还包含各种数据源如ES/HBase，业务数据库等各种系统Schema信息。所有涉及到的
- 表的脱敏配置信息
- 帮助系统需要的文档信息
- 画像元数据体系，比如画像表，字段schema，读取和写入这些字段的关联程序的信息
- 所有流（批）对关键组件读取和写入（通过SDK）都会更新到元数据系统
- 监控相关的订阅数据
本质上就是MLSQL Engine运行时需要的信息，以及产生的部分信息都会实时更新到元数据中心。通过元数据中心，你可以一窥整个数据的规范，流转状态，资源状态等等。 MLSQL提供包括敏感列在内处理规范，该规范需要用户自己实现一个server端(也可以定制client端，也就是内嵌在MLSQL Engine中的client端)。
统一登录平台
用户可以开发自己的MLSQL Console，从而实现交互和脚本管理。脚本管理功能对于MLSQL Engine是必要的，因为MLSQL Engine只是个类似JVM的执行引擎，他本身不提供脚本的管理，而是提供传递过来的脚本的执行和计算。用户可以单独出一个脚本服务，也可以内嵌在MLSQL Console中。尽管如此，MLSQL Engine部分功能依赖于用户需要按指定规范暴露脚本接口，以便它能获取到特定脚本的内容。统一登录平台允许用户已更合乎自己需求的方式登录MLSQL Console,比如很多公司都是需要用内部IM扫码登录，绑定公司员工账号等等。所以我们需要一个统一的登录服务，完成和公司账号体系的打通。
权限控制服务
MLSQL Engine提供了完整的表以及列的权限控制机制，但需要用户自身提供对应的服务端。比如MLSQL Engine会把脚本中访问到的所有表提取出来，然后发送给一个“特定的服务A”，又A来告诉它，哪些表或者列的访问是不合法的。MLSQL 完整的解决传统Hadoop体系遇到的权限问题，完全不需要侵入到任何组件，比如HBase, HDFS，ES等等。因为他的权限拦截体系是在MLSQL语法层面设计和解决的。MLSQL Console中内置了一个简易的权限控制服务，MLSQL Engine会调用该控制服务来觉得哪些表的访问是否被合法授权。
调度系统
调度系统一般而言需要和MLSQL Console(或者你的Web控制台)进行深度整合。譬如我在debug完一个脚本后，我应该能够在Console里直接设置依赖/定时任务。一个好的调度系统应该要能够支持动态DAG的构成，而不是事先写在某个配置文件里。MLSQL Engine内置了一个调度，这意味着你可以启动一个MLSQL Engine实例作为专门的调度系统，但是该调度仅仅作为参考实现。
日志系统
日志系统是用户排查问题的核心利器。一个完美的User-Story应该是像这样的：
在Console中调试MLSQL脚本（可能是流也可能是批程序），点击运行，在当前console或者prometheus查看效果指标，不好，在当前页面Kill掉脚本，然后调整参数（譬如生成的文件数，延迟等不符合要求），重新运行，运行时发现报错了，没有启动成功，在Console中看到错误概要，通过错误概要到日志系统（你也可以集成到Console中进行交互）根据关键字定位日志，接着查看该日志前后两百条信息，发现问题，修改后重复前面提交，最后效果满意，完成任务。
从上面我们可以看出，一个好的日志系统对于提升研发效率有多重要。我们需要把MLSQL的日志实时收集到分布式存储系统中，核心需要要实现三个功能
- 多层级类目
- 根据关键字查找
- 可以任意查看前后N行
大家可以基于ES来作为底层存储，然后自己开发一个实现上面三个功能Web界面（或者接口即可）
监控报警体系
监控报警体系应该是难度最大的。为了解决发送报警的人希望发送的尽可能多，接受报警的人往尽可能减少报警这一堪比中午吃什么的的世界难题，核心是用户自主订阅。也就是各个业务的负责人或者某个系统的负责人可以自己订阅自己感兴趣的报警。这是一个点。第二个点是，大数据的监控报警体系的输入数据来源都需要抽象出event,这样方便温和大数据的流的概念，第二个是进来的event要分门别类，要有schema,这意味着不同类型的event有他自己的schema。 有了schema，有了event, 我们就可以利用MLSQL里的Stream来处理了。
对于输入的event,有两大来源：
- 调度系统
- Promesue等传统运维层面的报警
当然还有很多其他的，比如我们通过调度去定时check 日志系统里面的某个系统的日志，检查特定关键之（类似OOM之类），然后将这个事情作为event发送出来。这些系统都可以发送到Kafka,然后我们启动一个单独的MLSQL Engine写MLSQL去对这些event做处理，比如对于报警我们可能还会聚合，发送给一个“端投递服务”。所谓端投递服务本质上是要适配各种目标，比如邮件，比如企业内部IM，微信，还有短信，甚至电话。端投递服务会从元数据里获取报警订阅的相关关系，投递给用户（群主）。
部署
K8s和yarn相结合。所有local模式或者driver或者上面的各种服务都部署在k8s, executor都运行在yarn上。这是一个当前比较完美的形态。
总结
通过MLSQL Engine强大的可扩展能力，MLSQL语言的简单和灵活性，再配合上面的几个系统辅助，一个横跨分析师，算法，研发，数仓，各业务线中的产品，研发，运营的数据中台就此可慢慢成形。