其實(shí)沒有SCT定律捐名，這個是我根據(jù)分布式CAP定律瞎造的。不過呢闹击，從大數(shù)據(jù)這個行業(yè)來說镶蹋，我們始終都是在存儲，計(jì)算和時間進(jìn)行權(quán)衡赏半，博弈以及突破梅忌。某種程度上來說，當(dāng)擁有其中兩者除破，可能很難兼顧第三者牧氮。
我們?nèi)粘Ｗ龅暮芏嗍虑椋鋵?shí)都是在突破這三者中的某一種瑰枫，不過過程可能比較艱辛踱葛，可能為了突破A，反過來又要求突破B光坝。
比如為了加快計(jì)算尸诽，我們會通過構(gòu)建Cube,物化視圖或者中間表（數(shù)倉里的分層）來完成，但這樣對存儲的要求會更高盯另，要能支撐更大的存儲量性含，同時需要支持更新，而且在覆蓋寫的時候鸳惯，讀不受影響商蕴。
再比如叠萍，做數(shù)據(jù)的家常便飯是增量/全量同步數(shù)據(jù)，這主要是為了解決數(shù)據(jù)搬遷的問題绪商。早期的數(shù)倉是要求數(shù)據(jù)都匯總到一個分布式存儲上的苛谷，所以必然會遇到增量/全量同步的問題。這個過程中會觸發(fā)時間問題（也就是數(shù)據(jù)可見性的延時）格郁，也會觸發(fā)計(jì)算的額外消耗腹殿，這些計(jì)算來源于同步以及涉及到Kafka,MySQL等各個子系統(tǒng)的消耗。
還有一個問題是例书，計(jì)算上锣尉，雖然SQL現(xiàn)在越來越成為主流，但是SQL依然有很多地方難以滿足需求决采，所以我們依然要用各種API進(jìn)行計(jì)算自沧，我們沒有一個統(tǒng)一的大數(shù)據(jù)應(yīng)用，還是各種應(yīng)用孤立的跑在硬件上（我們會把Yarn,K8s當(dāng)做硬件）织狐，這個時候我們會嘗試使用Spark暂幼，Preso,Impala,Kylin等各種系統(tǒng)解決各自的問題。
我今天回顧了下最近做的工作移迫，這些工作其實(shí)也都是為了解決這三個層面的問題旺嬉。
首先是存儲上，早先的數(shù)倉已經(jīng)不能滿足更新厨埋，事務(wù)邪媳，版本等方面的要求了，同時對AI的支持也力有不逮荡陷，所以現(xiàn)在開始演化為數(shù)據(jù)湖雨效。所以我基于delta開發(fā)了delta-plus,主要是我覺得對方的開發(fā)進(jìn)度太慢，所以事先添加了一些社區(qū)還沒開發(fā)的功能废赞。有了delta-plus,我們完成了三個任務(wù)：
- 并發(fā)讀寫徽龟。比如寫不影響讀。
- 流批共享唉地。流和批可以同時操作一張表据悔。
- 更新和刪除。很多系統(tǒng)并不能支持更新耘沼。
有了存儲上的支持极颓，很多其他的事情就會變得簡單。
其次是同步方面的問題群嗤，我們希望解決的是延時上的問題（時間）菠隆，傳統(tǒng)的模式是利用canal等工具讀取binlog到kafka,然后kafka后面接一個計(jì)算系統(tǒng)，將數(shù)據(jù)寫入到一個可更新的存儲，比如hbase,系統(tǒng)需要對接hbase來進(jìn)行查詢骇径，或者將hbase定時導(dǎo)出到hive供批使用躯肌。環(huán)節(jié)越長，無論計(jì)算效率既峡，維護(hù)成本就會越高羡榴。針對這個問題碧查，我希望有一個工具运敢，能夠一個環(huán)節(jié)搞定，這個工具直接對接mysql binlog,然后直接將數(shù)據(jù)同步到HDFS上忠售，可以供流和批讀取传惠。這個問題由spark-binlog解決，然后存儲由delta-plus完成稻扬。
第三個是計(jì)算的問題卦方，大數(shù)據(jù)對外提供的一個很重要的功能就是海量數(shù)據(jù)的分析查詢，為了應(yīng)對各種需求泰佳，我們各種武器都上去盼砍，計(jì)算系統(tǒng)繁多而復(fù)雜，時間效率和不一定能達(dá)到訴求逝她。這期間得益于阿里 Relational Cache的啟發(fā)浇坐，了解到物化視圖的概念,所以開發(fā)了sql-booster,他的出發(fā)點(diǎn)是實(shí)現(xiàn)物化視圖的Query改寫，但是現(xiàn)在的目標(biāo)會更大一點(diǎn)黔宛。我們這里簡單的介紹下物化視圖是什么近刘，假設(shè)你有A,B,C三張表，但是用戶經(jīng)常會將這三張表進(jìn)行Join關(guān)聯(lián)查詢臀晃，這個時候按數(shù)倉分層的方式觉渴，就是我再建中間表比如v1,v2。這個時候你需要告訴用戶徽惋，以后如果能用v1,v2盡可能用v1,v2,因?yàn)樗麄儠煨┌噶堋Ｎ锘晥D就是，你不需要再告訴用戶去使用v1,v2,用戶依然還是使用A,B,C险绘，但是系統(tǒng)通過改寫SQL,來自動使用v1,v2加速踢京。所以sql-booster本質(zhì)上可以讓你很方便的通過添加中間表的方式來透明加速用戶的查詢。不管你叫他物化視圖隆圆，還是關(guān)系緩存漱挚，都可以。
前面三個渺氧，我們通過三個組件delta-plus,spark-binlog,sql-booster 分別解決了存儲旨涝，同步，查詢加速三個問題。大家當(dāng)然可以獨(dú)立使用白华，現(xiàn)在我們其實(shí)缺一個計(jì)算系統(tǒng)將三者融合起來慨默，讓三者可以以一個方便方式組合起來。我們知道弧腥，在Linux系統(tǒng)厦取，有非常多的工具，比如sed,grep,cat等等管搪，但是粘合他們的是shell虾攻。MLSQL Stack是為了完成這個任務(wù)的，他提供了MLSQL語言更鲁，相當(dāng)于一個大數(shù)據(jù)的語言霎箍，脫胎于SQL。其次澡为，MLSQL可以很好的把這些工具組織起來漂坏。
最后打個廣告（雖然前面已經(jīng)有很多廣告），這些年我開源了很多項(xiàng)目媒至，期待大家能一起用起來顶别，然后讓他們變得越來越好：
delta-plus
delta with upsert/delete/compaction support, and can work with spark-binlog
which make multi-table sync more easy.spark-binlog
Spark binlog datasourcesimple-schema
A new way to describe spark dataframe schema with text format.spark-adhoc-kafka
A Kafka datasource supports consuming Kafka data by specifing
a time interval / offset / parallelism-
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:
spark-hbase
A HBase datasource implementation for Spark and MLSQL.
This library requires Spark 2.3+/2.4+, HBase 1.2+/2.0+ (tested).
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 ***
A Platform unifies BigData and AI. A language unifies BigData and AI.
