這是Facebook在FlinkForward2021上的一個talk, 主題如下
在前面的論文中分析了Facebook的實時計算引擎的設計和選型的考量，裡面提到了Facebook的實時計算引擎為了滿足易用性和效能不同維度的需求，研發了多套實時計算系統如Puma``Stylus``Swift分別使用SQL，C++，Swift來進行研發。但是多套引擎也帶來了很多問題，可選擇的引擎太多，不同的引擎的功能重疊，對使用者和對於引擎維度都有很大的成本。為了能讓使用者獲得一致性的體驗，其內部選擇將多套引擎整合成一套也就是XStream。
XStream架構分層
他有以下的一些特點
- 基於
Stylus的一個Native C++的執行引擎 - 基於統一的SQL語言，統一的流，批，互動式的查詢語言
- 使用解釋執行而不是編譯執行的模式
- 和presto/spark 共享使用了向量化的SQL執行引擎
SQL上使用標準的SQL2016的語法和Presto統一，並且做了Multi-tumble 和 Mulit-slide window的擴充工作
編譯執行的方式就是根據SQL生成的AST tree進行codegen，然後進行編譯執行。編譯執行的壞處主要是
- 每個pipeline都會生成一個binary檔案
- scale up down不友好
- 依賴問題
- 編譯時間較長
最終他們採用的是解釋執行的模式。由C++ worker解釋執行，一個作業只有一個binary，但是解釋執行的效率肯定沒有編譯執行的效率高，因此他們使用了以下手段來提速
- 使用列式儲存+向量化處理模式
- 利用simd指令加速
向量化提速用到了最近新起的velox的專案，它是一個C++向量化的SQL執行引擎，由Facebook開源，並在其內部用於Presto和Spark以及XStream的統一的執行時向量化加速，velox相關的可以參看這篇文章 Velox: 現代化的向量化執行引擎
整體的XStream架構，提供CoreSQL和DataFrame兩套api，編譯成LogicalPlan和Physical Plan。然後分發到local worker進行處理。Local planner將其翻譯成XStream operator, 然後利用Velox 來進行加速處理
Velox和XStream 編譯型和解釋型的對比資料
參考
https://www.youtube.com/watch?v=DNI54vc1ALQ&t=1158s&ab_channel=FlinkForward