我是一個深資的函數式愛好者，研究得不深，但做過許多有趣的東西，應用在很多地方。。。
這些有趣的東西，就像成為魔術一樣，讓我變得自信快樂。。。
分享快樂會更加快樂，所以我很開心能夠分享給大家。。。

很多人覺得函數式只是一個奇技淫巧，大多是用不上的，這里我想從心底告訴大家，函數式將無處不在！
下面開始我的表演：

1. 極效開發環境REPL開發，盡情享受函數式
   a. 簡單開始REPL在線編程
   b. 遠程也能REPL在線編程
   c. hadoop集群上REPL編程
2. 大數據引擎，因函數式而生，因函數式而偉大
   a. 定長之痛，第一代DataSet數據引擎COBOL/SAS的缺陷及思考
   b. Report之痛，第二代OLTP數據引擎Mysql的缺陷及思考
   c. 3NF之痛，第三代OLAP數據引擎Oracle/Postgres的缺陷及思考
   d: Transform之痛，第四代半結構數據引擎Hive/SparkSQL的缺陷及思考
   e: State之痛，第五代實時數據引擎storm的缺陷及思考
   f: 傳統函數式之痛, 第六代函數式引擎SQL與傳統函數式融合之SparkSQL On lamdba的缺陷與思考
   g: 非明細累計之痛，第七代半結構實時SQL引擎KSQL的缺陷及思考
   h: 終級挑戰: 函數式引擎SQL on transducer
3. SQL好兄弟transducer助力，一招打遍無敵手，函數式未來不再是夢
   a. javascript上跑起來
   b. java上跑起來
   c. kafka上跑起來
   d. spark上跑起來
   e. ksql上跑起來
4. 一切數據結構盡在KV，datalog/specs保駕護航
   a. 索引查詢即map, map結構及數據庫rocksdb
   b. 菜單層級即tree，tree結構及數據庫zookeeper
   c. 依賴關系即graph，graph 結構及數據庫datomic/neo4j
   d: tree與graph積極擁抱函數式
   e: 終極挑戰: tree與graph之爭與轉換，調度系統未來的思考
5. 函數式終級無鎖編程，這個世界突然清凈了
   a. STM
   b. agent
   c. core.async
   d. zookeeper
   e. avout
   f. kafka
6. 函數式運維，將革命野火越燒越烈
   a. 函數式編程語言nix
   b. 函數式操作系統nixos
   c. 函數式軟件包nixpkg
   e. 函數式構建nix-env
   f. 函數式部署nix-store
   g. 函數式隔離nixops
7. 函數即服務Faas，云上爭霸天下
8. 函數式區塊鏈Cardano

一. 極效開發環境REPL開發，盡情享受函數式

相信大家對repl不陌生吧?
repl就是Read-eval-print-loop, 簡單說就是邊寫邊調，立即檢查結果。。。
用過python/r/js/scala的朋友自然能感受到它的高效，現在java也抵抗不了誘惑加入了陣營。

1 單純的repl的編輯功能比較弱，所以我們要高級一點，選擇代碼就運行！

image.png

2. 前面的功能確實不太過癮。那我們在遠程服務器上開個后門，悄悄連過去為所欲為如何？

a. 首先, 在服務器上拷貝安裝后門REPL程序。

image.png

b. 緊接著，啟動后門程序

image.png

c. 最后，我們可以對遠程服務器為所欲為，為所欲為。。。
直接cider-connect連接到遠程服務器:(如遇到ssh連接，請刪除.ssh/know_host入口)

image.png

接著運行shell命令隨意操縱遠程服務器

image.png

3. 遠程的操作權限于java跟clojure標準庫，因為我們沒有添加依賴的MAVEN庫。。。沒關系， maven庫可以運行時添加! 事情開始變得有趣 了。。。

a. 首先在遠程添加牛逼的動態maven解析庫: [com.cemerick/pomegranate "1.0.0"]后啟動repl后門

image.png

b. 連接到遠程repl服務器，想要哪個MAVEN庫就用哪個MAVENY庫。。。

image.png

至此，基本告一段落了，現在已經可以隨意運行各種SHELL命令，使用運行時加載各種MAVEN庫為所欲為了。

4. 通過SSH開后門太簡單了，我們應該把后門開到HADOOP集群上去！這么多機器其實可以拿來挖礦嘍。。。

這里我們介紹一下hadoop, hadoop分為兩部分: hdfs分布式文件存儲 & yarn資源管理.
hdfs可以通過9000端口進行rpc接口調用。。。而yarn可以通過8032端口訪問。。。
如果是HA的話，則可以通過ZOOKEEPER讀取，這里不過多細訴。
正常 的HADOOP運行過程是:

1. 本地上傳JAR包及至HDFS
2. 客戶端通過向Yarn申請ApplicationMaster容器運行AM程序
3. AM啟動后向Yarn進行注冊
4. AM接著向Yarn申請executor, 得到driver的task后分配運行并監控
5. AM根據所有executor運行的結果，返回給Yarn后退出。

那么我們怎么開后門呢？

1. 編寫我們的ApplicationMaster邏輯運行后門repl服務，打成jar包上傳hdfs
2. 通過repl啟動注冊服務，方便后門服務回連回來
3. 通過repl連接至yarn，提交AM Repl后門程序，并傳入監聽注冊中心服務地址
4. AM repl后門程序被 yarn隨機分配到集群上啟動后，通過參數回連到repl進行服務注冊。
5. 我們本地的repl服務連接到回連注冊的repl服務器上，發送代碼對hadoop為所欲為...

代碼示例如下:
a. 編寫repl后臺服務并打包上傳至hdfs(參數包含了回連的注冊服務器地址):

image.png

b. 通過repl啟動注冊服務供遠程后門回連

image.png

c. 通過repl連接至yarn，提交并運行AM REPL后門程序

image.png

d. AM REPL后門回連至注冊服務(屬于a過程中代碼)

image.png

e. 對回連注冊的AM REPL后門，發送任意代碼至遠程服務器執行

image.png

由于時間關系，后續將會進一步對其進行代碼整理，思路大致如此.

二. 大數據引擎，因函數式而生，因函數式而偉大

自從Hadoop的MR框架出現以后，大數據便以燎原之勢迅速占領了數據處理的主戰場。
隨后storm流式框架以及spark批量引擎的出現，將函數式編程推向了至高點。

也許你要問，Hadoop跟函數式編程有啥關系?
如果你稍弱了解一下，將會知道map以及reduce是函數式最基本的功能。
map是單行處理數據，如果進行過濾，則產生了一對零操作filter，如果進行explode分解，則進行了一對多mapcat/flatmap操作。
如果需要跨行操作，則是需要進行reduce處理。
所以map + reduce，就是先逐行處理，然后進行跨行處理，單行處理不關心狀態，多行處理往往伴隨著狀態。
跨行過程中，如果在分布式集群中，又涉及數據 的洗牌shffle或者 重分區repartition操作。

是不是感覺很熟悉？因為spark的基本API就是map, filter, flatmap, reduce操作...
如果熟悉storm trident機制，接口也是完全對等的。
除了數據處理操作之外，還有任務依賴的處理，那就屬于圖的概念了，后續將會詳細介紹。

最近隨著一股SQL On lambda之氣，presto以及spark選手紛紛上場。
clojure更是推出通用復合性引擎transducer，一統所有模式。
實在不得不感嘆到:

大數據處理，非函數式不破也！

本人從工作后一直從事數據搬運工工作，
玩過SAS/COBOL, MYSQL, Oracle/Teradata/SQL server/PostgreSQL, Hive/SparkSql, Storm, KSQL, Presto各種工具，
所以很清淅地看到了數據引擎發展的軌跡。也看懂了數據處理各階段的難題。
當然每一代都在一起發展，所以這里的區分也不一定嚴格。

1. 最早的一代屬于COBOL跟SAS。

也許你沒聽過COBOL，那你聽過BUG這個詞吧？那你聽過JAVA吧？那你聽過ATM取款機吧？
沒錯，BUG就是COBOL之母發明的，當時的COBOL就如當前的JAVA如此火爆，那怕是現在的銀行核心系統以及ATM上的代碼很多都是從COBOL誕用，延用直今。并且COBOL是完全面向人類習慣設計的語言，所有保貶不一，爭議極大。
緊接著統計分析工作越來越顯得重要，面向統計分析的SAS軟件也面世，它的數據處理功能也是非常強大的。
那時候的數據格式都是長度固定的，所以處理性能極高。但是模式是不可改變的！
那時候的操作都是原生數據處理操作，所以開發效率極高，并且很靈活。
當然SAS通過內置一些基本的RPOC操作，加大了復用性，但是每一個功能都得自己做一步步來，一遍遍處理。
所以很多人寫SAS不耐煩了，直接調用它的PROC SQL引擎以SQL方式處理也不為過了。

這一代的問題，是最基礎的問題。

1. 擅長處理定長文件，所以對模式擴展不友好，變長或者稀疏不太好搞。
2. 開發效率過低，由于采用的原生的代碼方式，對于多種操作的組合性不強，代碼理解力極差。
   比如要同時計算前十跟后十的計算，同比與環比的計算，移動平均值的計算。。。
   要想一次處理所有邏輯，各種變量轉移邏輯異常混亂

最終的結局:
數據模式及編程模式較為固定，故最終在特定領域發揮較大作用。
COBOL面向業務邏輯，SAS面向統計分析。

行業發展:
隨著SQL時代的到來，通用性的引擎開始發光發熱。

2. 第二代，關系型數據庫Mysql開始登場

這時關系型數據庫開始誕生，大部分用在OLTP事務處理上。
有了SQL引擎，不管怎么樣，對于第一代有了明顯的進步。
開始有了函數與聚合函數的概念，是不是跟map/reduce有點像?
函數及表達式 <=> map, where <=> filter, 多次insert<=>mapcat, group by <=> reduce。

所以簡單看來基本的數據操作功能也算是有了，那么它到底還弱在那里呢？

1. 分析功能太弱。比如我想算每個組排名前十的邏輯 ，需要自join才能處理好。自join隨著數據量的增大帶來了極大的性能開銷。
2. 數據量過大性能下降厲害，這個后期發展自然有分片機制發展，但是OLTP對于大數據處理，還是存在較大的問題。
3. 靈活度差，相比于第一代系統一次遍歷混亂搞定多個功能 來說，代碼是清晰不少了，但是性能也下降了。這里組合功能不弱，而是只能對于標準模式進行組合，組合自由度下降了。比如同時比多個維度處理，分別計算每一級維度的匯總值。

最終的結局:
常用的事務支持非常優勢，對于歷史性數據分析，性能極差，甚至影響OLTP系統。
對于OLTP查看歷史數據報表，甚至可以引起生產環境DOWN機的情況 發生。
這樣，所有早期的系統會進行歷史數據于當前數據區的劃分，就是為減緩歷史區對當前區所帶來的負擔。

發展:
ERP系統開始出現，DW+BI系統開始出現。新的OLAP引擎開始主載數據戰場。OLTP+OLAP完成分離。

3. 第三代， 主要以Oracle/Teradata//PostgreSQL為代表。

應該是人們眼中傳統的BI解析方案。SQL Server由于其經濟性，在數據量不是很大的情況下，也是占領了一部分市場，影響力稍少。

這一代引擎的特點是，為分析而生。所以常用的分析強能80%以上都能輕松解決，哪剩下的呢，后面再說。

前面講了多維度聚合的問題，它們有了grouping sets, cube, rollup去支持。
還有窗口狀態自定義，它們有了leading, lag, row_number+partition by去支持
遞歸功能有了connect by, with recursive支持。

看起來接近完美 了。 真的是這樣嗎？
讓我們一起來看一看它的弱點吧。

1. 分析性能較差
   傳統的SQL出生于存儲資源比較寶貴的年代。
   所有的數據都是分離了，之間的關聯則是通過主外鍵動態連接的，最終不斷地加工直至產生所謂的"寬表"
2. 狀態管理仍然不夠靈活
   雖然引入了窗口管理機制，可以引入不同層級的窗口進行跨行方面更細粒度的管理，但從本質上來說，并不能靈活定制。
   僅僅只是實現了常用的環比，占比，排名之類的功能 。對于遞歸功能也是挺無奈，只是簡單地進行關系關聯。
   但是分析功能的出現，在很大意義上提升了OLAP的實用性。
3. UDF開發極其困難。
   由于分析功能以及內部SQL引擎的復雜性，大部分并沒有開放期UDAF接口，僅支持簡單的非狀態化的MAP邏輯。
4. 反人類的三范式。
   三范式一方面有了第一步所提到的數據分離問題，另一方面由于其原子性上的靜態特征破壞了數據的結構性。
   a. UV算法難題。
   比如，一個用戶，進行了多次的記錄訪問，從分析的本質上來說，其實都 是用戶的訪問分析，應該在同一條記錄上。而在關系型數據庫中，必須存成多份，這就產生了臭名昭著的”UV算法難題“。如果要計算一年的UV，那么要把所有的明細計算提取出來去重計算才行！ 而不采用關系型存儲形式，所有的用戶記錄通過函數提取訪問記錄結構體簡單計算即可得出。
   b. 歷史拉鏈算法難題。
   比如，一個用戶，進行了多次狀態的變更，從分析的本質上來說，其實都是用戶的狀態結構，應該在同一條記錄上。而在關系型數據庫中，甚至還需要閉鏈操作去處理跨行的狀態管理 ，加上拉鏈修復難題，簡單是慘不忍暏啊！這個本質上來寫個函數提取一下狀態數據結構就能解決的事情，但是它們做不到啊。

發展:
由于三范式引起的結構破壞，以及UDF開發困難，狀態管理之難題等。新一代的半結構化數據開始逐漸登入舞臺。
而真正的函數式技術由于其狀態管理的高度自由，函數功能組合的高度自由 ，數據結構組合的高度自由 ，開始發光發熱，呼風喚雨，天下大勢，僅函數式是也！

第四代, 半結構化引擎HIVE為函數式之道義攻破關系型數據庫的城門！

從傳統OLAP發展得漫長歲月里，人們慢慢感覺到了它的局限性。
整個IT世界的，數據格式亦從最基本的CSV格式慢慢過渡到了JSON。

這說明了一個道理：數據之間的關系越來越緊密了。

所謂的數據關系，用專業角度來說，就是denormalize，反正則化。
一旦反正則化，好戲就要開始了，作為組合數據中，最基本的二種數據結構，MAP跟ARAAY登場了。
當然有人說還有STRUCT結構，STRUCT結構本質上等同于已知鍵模式的MAP，殊途同歸。。。
這里已經能清楚看到了，MAP跟ARRAY是函數式的基本結構，可以不停地組合并多層級轉換。

而函數式天生從骨子里就擅長干這個。

即然denormalize之后，數據組合在一起之后，多個表結構密集在一起了。
這個時候的數據模式，必定是多級的。HIVE在此種背景下應運而生。

為了支持模式的多樣性，HIVE采用了SerDe來自定義數據的讀取轉換，對于數據的collect及explode操作
因此打開了半結構化世界的大門。
另一方面，由于模式的多樣性，必然引入了復雜度。
所以當前主流的關結構化引擎都采取了自建門戶的模式，比如HIVE采用ORC， SPARK采用parquet。

諸子百家，好不熱鬧，數據行業由于半結構化的到來，重新顯示出了一片繁榮。

當然所有的核心結構依然是MAP跟ARRAY，互聯網連接依然以淺模式JSON和深模式AVRO格式互連。

在新的半結構化世界里，表模式就是STRUCT結構，關系則以MAP結構組織，一對多則用ARRAY結構打包。

有了可自由組合以及自由擴展的數據結構，處理這些數據結構的邏輯也是非常急需的。

所以，慢慢的HIVE開始顯示出不適應，而spark則以函數式為核心慢慢占領了主戰場。

所以這一階段處于先行軍，所急需解決的問題也是不少。

1. 最重要的一點，當然是對于數據結構的處理引擎。
   hive這個引擎提供了UDAF(自定義聚合函數)的接口，可以說是打開了一個新世界。但是由于HIVE本身的類型系統不完善，最終致使HIVE這個功能非常難用。最終HIVE只能妥協，提供了collect的方法將跨行的狀態累積起來編寫UDF處理。這本身會消耗大量內存，但也是一種可以使用的臨時解決方案。既然可以用UDAF COLLECT函數之后用UDF來處理，但是對于JAVA編程來說，處理半結構數據也是比較吃力的。
   spark引擎在HIVE的基礎上稍有增強，有RDD方法跟SQL方法 。Spark SQL方法本質上是傳統OLAP的繼承，采用窗口狀態模型，所以對于半結構化數據也是非常無力的，直至最近的2.3 版本開始支持SQL on lambda，當然這是后面的話題了。當然, spark還是有退路的，spark提供了RDD提供底層接口供自由編程。Spark RDD是將函數式編程的方法分布式化，提供了核心的map, filter,mapcat/flatmap.reduce功能, 但是Spark RDD這種思路也是有問題，它的函數式組合能力太弱，因為reduce功能涉及狀態管理，所有同時做sum與count處理就沒有SQL那么強大，而sql on lambda就是將這些功能集成在sql上，一定程度上解決了這種問題。
2. 數據引擎的統一性。
   對于大數據處理，依然會有人使用HADOOP MR + HIVE UDF處理，新一點的則是Spark RDD + Spark SQL。這說明了兩種模式的互補性。底層的函數式引擎能靈活處理各種問題，但是編碼開發困難，復用性差。而上層的窗口狀態模型依然存在傳統OLAP所面監的問題，狀態管理模式具有一定的局限性。隨著hive把半結構化數據推上了OLAP上，傳統OLAP引擎已顯得蒼白無力了。所以需要編寫大量的UDAF來處理。UDAF狀態管理模型與傳統OLAP的沖突，最終導致了新的兩代引擎誕生: 實時引擎 + SQL-on-lambda.

發展:
前面介紹了半結構數據的發展誕生了兩個分支: 實時引擎以及SQL-on-lambda。也許有人不明白了，這兩者有什么聯系？
對于實時引擎來說，既然狀態不好處理，那我們專心去處理狀態。
而對于大量的OLAP來說，放棄窗口模型狀態是不可能的！我們把函數式放在SQL上來用！
兩者都是函數式原型的代表，第一種代表了函數式引擎 transducer的發展方向，第二種代表 了傳統函數式的高階函數操作。
從未來發展上來看，實時引擎的路更好走一些。
因為隨著半結構化數據的成熟，所有的數據只需要遍歷一次，管理 好狀態就能得到結果。
現在的數據處理模式也在往這方面發展，達到”MapReduce邊轉換邊聚合，Explode多維狀態分解提取結果“。
接著，我們一一介紹。

第五代，實時引擎重新定義OLAP。

我們把實時引擎放在第五代，還不是SQL-on-lambda是有原因的。
在半結構化數據沒有到來之前，就有實時引擎開始活躍。但是隨著半結構化數據的到來，更加加劇了它的發展。

從技術上來說，主要有兩個原因:

1. 半結構化減 少了數據之間的分離，而實時處理對于表的join是很有局限性的，后期的KSQL很大程序上解決了這個問題
2. 半結構化增加了狀態復雜性，由于半結構化到來，傳統的OLAP的狀態管理不是特別適應，需要更靈活地解決方案。

從業務上來說，實時引擎有著極強的業務需要性。

對于傳統的ETL流程，一天跑批對于急劇變化的商業世界也不再適應用。
所以大量的OLAP需求從1天轉為1小時，接著10分鐘，接著1分鐘，最終形成了微批量！
微批量就是傳統的OLAP模式，這種模式在很大程度上解決了很多問題，也在一定程度上限定了技術的發展。
微批量有很大的局限性，批量調度更復雜，作業間并行影響更復雜，編程模型更復雜。

商業上實時處理引擎最早出現的就是STORM引擎，它是由函數式編程語言clojure開發的。
如果讀者讀 到這里，應該不難承認，函數式已經占領了數據引擎戰場。

實時處理引擎面臨的問題也很多。

backpress回壓技術，嚴格一次處理，tupl DAG依賴消息重發，狀態管理。
上面提到的核心點，狀態管理 。
對于嚴格一次來說，STORM處理得比較復雜，采用了微批量方式，按批次發送后補充發送完整，達到至少一次，接著將數據按照事務ID進行Persistent到外部存儲，達到嚴格一次。在persistent過程中，引入了窗口狀態管理機制。
所以，storm分為兩派:
一派是單tuple執行自由狀態管理，所有編程需要自己完成，可以通過數據間的依賴樹進行消息重發
另一派相似于spark，通過外部管理狀態實現窗口狀態管理 ，失去了底層的靈活性。

所以，初期的storm模型的基礎問題就在于以下幾點:

1. 狀態管理要么太低級，要么太封閉。
   如果采用最原生的tuple模型，需要大量的編碼。而如果采用trident微批量形式，則狀態管理其實是OLAP的這種微批量窗口模式。
2. 狀態管理需要外部系統侵入，低層接口與微批量接口的不一致嚴重損害系統的擴展能力。
   前者狀態比較自由，所以需要配合redis或者hbase進行狀態持久化。后者狀態比較封閉，則需要使用專用的接口去調用函數式接口編程。這兩者的分離，加上外部狀態管理 的耦合性，使流式計算擴展性大大削弱
3. 流式系統的join操作
   由于大部分平臺的數據還處于3NF模式，所以不可避免存在JOIN的操作。即使denormalize之后，對于關聯性不強的實體，依然是會有這種需求。所以呢，流式系統必然要實現join的操作
4. 模式系統支持
   由于早期的實時引擎需要管理狀態，并且依賴于外部系統，所有的數據處理過程均采用編程模型完成，最終代碼 沒有模式支持，均靠API接口實現。

發展:
實時引擎發展越來越壯大，對于狀態化管理 ，越來越多的方案出來了，并且實時引擎上面SQL平臺也開始成熟起來。
隨著函數式技術的進一步發展，可自由組合狀態的transducer技術也開始橫空出世，獨領風騷，未來不可預期。。。

第六代，SQL與傳統函數式融合之SQL On lamdba，持續發力中。。。

對于半結構化的到來，一方面函數式熱不可擋，另一方面傳統的函數式對于狀態管理復合性過弱。比如，同時進行sum跟count操作。SQL引擎本身類似于流式引擎，是單條處理的，所以在固有的窗口狀態模式下，是可以得合的，所以是可以同時進行SUM跟COUNTR的，這就是流式處理模式帶來的好處，而傳統的函數式采用的是映射式模式，對于狀態復合還是理解不到味，以致于后面的transducer出世成功解決了這一點。
現在有了SQL，可以做基礎的窗口狀態管理 ，有了lamdba/reduce高階函數，去處理半結構化數據進一步細化定制管理狀態 。

一切看起來非常得完美 了。

然而呢，我們還需要往前走，往前看。

對于半結構化數據處理， map/reducel的lamdba轉換只是函數式的基本功能！

前面已經論述過，lambda在一定程度上復合性太弱。哪種復合性?
首先你在SQL上能同時計算sum跟count了 ?可是如果lambda上面有這種需求呢?
當然你可以用SQL分別計算 之后通過lambda組合起來進行引擎的互補。
但是呢，函數式很多高級的操作，SQL是沒有的。
比如我要計算半結構中上下級關系，lamdba復用性就跟不上了。
這么多年SparkSQL跟hive在半結構化進程中發展緩慢，很大一部分就是因為半結構化轉換邏輯具復合實現難度太大!
當然有了SQL on lambda，我們的狀態管理自由了，總體來說算是進步很大了。。。

所以，我們總結一下SQL on lambda的缺 陷.

1. 數據處理邏輯 的復合性。
   數據處理邏輯的復合很大程度上取決于狀態的復合，在SQL一定的狀態復合機制下，SQL on lambda會有較大成功的概率，因為一方面它吸收了OLAP模型，另一方面引入了半結構化與函數式處理機制，在一定程度上能很高效的解決問題
2. SQL與映射函數式模型的不一致性
   它的函數式功能還處于基礎階段，傳統的函數式采用了sequence的映射機制，沒有完善的狀態復合功能。對于沒有復合狀態的傳統函數式，想在半結構轉換中組合狀態，難度真不是一般的大啊！
3. SQL與函數式的融入性
   對于函數式處理深層級結構的自由靈活編碼方式，在SQL也不一定能成功地融入進去。當然非常值得人期待。

發展:
由于函數式在商業模式中仍處于起步階段，這種風險小，效果顯示的方式會被 大多數數據引擎所接受。
像很早之前presto查詢引擎就率先加入了此陣列，不難想像，傳統OLAP也會慢慢轉移。

第七代，半結構實時SQL引擎KSQL，數據倉庫革命者，實時數倉之領軍者！

第七代引擎簡單是厲害得不行，前面有Kafka流式隊列的長久考驗，再之后有Kafka Streams流式狀態的技術突破，再加上samza流式引擎在商業應用上的廣泛成熟。KSQL集一人之力，成功吸收之，并開創了第七代半結構實時SQL引擎。

它的偉大之處在于哪里呢?

1. 模式化。傳統的流式平臺模式性很差，很大一部分狀態由外部系統管理 。而KSQL在流式引擎存儲底層就集成了模式。模式分為兩種，一種是表Table，一種是流Stream，兩者相輔相成，直接接成到了Kafka存儲中去了！采用avro格式來實現半結構化數據結構的統一性，在整個引擎上達到了高度的簡化與靈活性。
2. 狀態化。KSQL的狀態處理模式非常帥氣逼人。對于嚴格一次，KAFKA本身就有topic+offset來進行區分。對于狀態的更新， kafka底層存儲rocksdb直接 支持，就是那無敵的Table模式！狀態還可以復合，表上再建表，開創了強大的undo機制！
3. UDF/UDAF支持。KSQL的UDF/UDAF狀態模型非常簡單，成功吸收了HIVE的經驗，但是又拋棄了很多復雜的機制。利用UDF/UDAF進行擴展，沒難度！
4. SQL支持。KSQL采用了熟悉的SQL模型，非常輕易地實現了窗口管理狀態。
5. 流式join處理。KSQL由于底層的Table與Stream模型，Stream-Streamg, Table-Table, Stream-Table都支持！

這樣一來，KSQL要開創實時半結構數據的先行，太了不起了！
你可能要問，KSQL與SQL on lambda最大的優勢在于哪里?

1. KSQL采用了流式模型，能夠很方便與函數式最新技術transducer結束，達到數據處理模式的高度一致性！ transducer模型可以復合狀態！當然SQL on transducer的批量引擎也是一個發展方向。
2. KSQL對于非累計明細數據處理有著極大的優勢。比如算UV，KSQL得計算所有明細數據，而KSQL的實時模型可以達到響應式效果。隨著數據處理復雜度的提升，越來越多地非累計型計算會越來越多，以前OLAP解決不了的問題KSQL現在也可以處理了！

當然，實時引擎的發展不可避免有著它需要處理的問題。

1. 流式狀態處理的復雜度
   前面所學的簡單的流式狀態已不再話下，自然也證明了KSQL的強大性。
   但是新的變態需求還是不斷顯現的， 特別是對于非累計明細計算來說，UV是比較簡單的概念 ，以此為例。
   本人自創了一套明細-統計分離法，對于如何標準化得融入引擎，仍在大量嘗試階段
   a. 非累計明細之任意時間段難題。（比如要計算任意時間段的UV訪問數量）
   對于每一條數據，都要更新所有的歷史范圍的數據。
   比如從2018-01-01開始 ，接著2018-01-02，
   在2018-01-03的時候，對于所有的日期{2018-01-01, 2018-01-02, 2018-01-03}的任意日期明細計算都要進行更新。
   b. 非累計明細之維度組合難題。（比如要計算各種平臺組合下的UV訪問數據 )
   比如有三個平臺 [A,B,C], 我們對于不同的組合就要分別計算, [A, B], [A, C], [B, C], [A, B, C], A, B, C...
   c. 非累計明細之度量值漂移。（比如對用戶訪問時長進行分組統計，用戶的時長一直累計，有可能從一個組漂移到另一個組，當出現這種情況的時候則需要撤消先前維度的值，新增新維度的值）
   例 子還有很多，后面會寫文章專門討論明細-統計分離法。在此不再多訴。
2. 流式SQL引擎的靈活性
   由于SQL在目錄來看已經不屬于關系型數據庫，本質上來說是一種數據處理的語法表達，與XML有著相似的功能。
   由于此種背景，SQL中的各種子循環，以及explode操作的結合性，以及未來模式的演化性，都具有極大的不確定性。
   SQL作為一種數據表達語言，是否能真正適應未來的數據引擎需求，還是說更底層的transducer，或者 datalog之類的引擎日益發展壯大，成為新一代標準。這個自然是未來來經驗了。當前，SQL還是無敵的。

發展:
按前面所描述的來說，流式引擎在實時數據倉庫中會慢慢發揮具大的作用。
其中三點特別值得注意 ，一是半結構化SQL模式與復合性多層級函數式技術(lens, transducer)的深度結合，另一種是對于非累計明細的狀態標準化，第三種是新型流式引擎的出現。。。

終級挑戰: 新一代函數式引擎SQL on transducer

transducer是我非常喜歡的一個技術，也是應用非常廣。當前也積極在研究SQL解析器，試圖集成transducer功能。
如果能將SQL引擎在解析器上面集成transducer，那么它的威力是相互可怕的。
最近比較忙，這里對具體技術不做過多講解，后續將會更新。

不經意間多次提到了transducer功能。那么我們下一步講解的主題就是:

三：transducer重演SQL老大哥之路， 熱血青春，讓數據世界布滿函數式的腳步，無處不在！