数据SCT定律：存储，计算，时间

其实没有SCT定律，这个是我根据分布式CAP定律瞎造的。不过呢，从大数据这个行业来说，我们始终都是在存储，计算和时间进行权衡，博弈以及突破。某种程度上来说，当拥有其中两者，可能很难兼顾第三者。

我们日常做的很多事情，其实都是在突破这三者中的某一种，不过过程可能比较艰辛，可能为了突破A，反过来又要求突破B。

比如为了加快计算，我们会通过构建Cube,物化视图或者中间表（数仓里的分层）来完成，但这样对存储的要求会更高，要能支撑更大的存储量，同时需要支持更新，而且在覆盖写的时候，读不受影响。

再比如，做数据的家常便饭是增量/全量同步数据，这主要是为了解决数据搬迁的问题。早期的数仓是要求数据都汇总到一个分布式存储上的，所以必然会遇到增量/全量同步的问题。这个过程中会触发时间问题（也就是数据可见性的延时），也会触发计算的额外消耗，这些计算来源于同步以及涉及到Kafka,MySQL等各个子系统的消耗。

还有一个问题是，计算上，虽然SQL现在越来越成为主流，但是SQL依然有很多地方难以满足需求，所以我们依然要用各种API进行计算，我们没有一个统一的大数据应用，还是各种应用孤立的跑在硬件上（我们会把Yarn,K8s当做硬件），这个时候我们会尝试使用Spark，Preso,Impala,Kylin等各种系统解决各自的问题。

我今天回顾了下最近做的工作，这些工作其实也都是为了解决这三个层面的问题。

首先是存储上，早先的数仓已经不能满足更新，事务，版本等方面的要求了，同时对AI的支持也力有不逮，所以现在开始演化为数据湖。所以我基于delta开发了delta-plus,主要是我觉得对方的开发进度太慢，所以事先添加了一些社区还没开发的功能。有了delta-plus,我们完成了三个任务：

1. 并发读写。比如写不影响读。
2. 流批共享。流和批可以同时操作一张表。
3. 更新和删除。很多系统并不能支持更新。

有了存储上的支持，很多其他的事情就会变得简单。

其次是同步方面的问题，我们希望解决的是延时上的问题（时间），传统的模式是利用canal等工具读取binlog到kafka,然后kafka后面接一个计算系统，将数据写入到一个可更新的存储，比如hbase,系统需要对接hbase来进行查询，或者将hbase定时导出到hive供批使用。环节越长，无论计算效率，维护成本就会越高。针对这个问题，我希望有一个工具，能够一个环节搞定，这个工具直接对接mysql binlog,然后直接将数据同步到HDFS上，可以供流和批读取。这个问题由spark-binlog解决，然后存储由delta-plus完成。

第三个是计算的问题，大数据对外提供的一个很重要的功能就是海量数据的分析查询，为了应对各种需求，我们各种武器都上去，计算系统繁多而复杂，时间效率和不一定能达到诉求。这期间得益于阿里 Relational Cache的启发，了解到物化视图的概念,所以开发了sql-booster,他的出发点是实现物化视图的Query改写，但是现在的目标会更大一点。我们这里简单的介绍下物化视图是什么，假设你有A,B,C三张表，但是用户经常会将这三张表进行Join关联查询，这个时候按数仓分层的方式，就是我再建中间表比如v1,v2。这个时候你需要告诉用户，以后如果能用v1,v2尽可能用v1,v2,因为他们会更快些。物化视图就是，你不需要再告诉用户去使用v1,v2,用户依然还是使用A,B,C，但是系统通过改写SQL,来自动使用v1,v2加速。所以sql-booster本质上可以让你很方便的通过添加中间表的方式来透明加速用户的查询。不管你叫他物化视图，还是关系缓存，都可以。

前面三个，我们通过三个组件delta-plus,spark-binlog,sql-booster 分别解决了存储，同步，查询加速三个问题。大家当然可以独立使用，现在我们其实缺一个计算系统将三者融合起来，让三者可以以一个方便方式组合起来。我们知道，在Linux系统，有非常多的工具，比如sed,grep,cat等等，但是粘合他们的是shell。MLSQL Stack是为了完成这个任务的，他提供了MLSQL语言，相当于一个大数据的语言，脱胎于SQL。其次，MLSQL可以很好的把这些工具组织起来。

最后打个广告（虽然前面已经有很多广告），这些年我开源了很多项目，期待大家能一起用起来，然后让他们变得越来越好：

1. delta-plus delta with upsert/delete/compaction support, and can work with spark-binlog which make multi-table sync more easy.
2. spark-binlog Spark binlog datasource
3. simple-schema A new way to describe spark dataframe schema with text format.
4. spark-adhoc-kafka A Kafka datasource supports consuming Kafka data by specifing a time interval / offset / parallelism
5. spark-submitter-console Spark Submitter Console is a tinny but useful web console in which you can
   • Uploading jar
   • Submitting jar to Yarn cluster
   • Monitoring/Manager your applications:
6. spark-hbase A HBase datasource implementation for Spark and MLSQL. This library requires Spark 2.3+/2.4+, HBase 1.2+/2.0+ (tested).
7. sql-booster

This is a library for SQL optimizing/rewriting. Current version (0.1.0) we have already support Materialized View rewrite.

This project is under active development and *** NOT READY FOR PRODUCTION ***

1. MLSQL Stack

A Platform unifies BigData and AI. A language unifies BigData and AI.