星環科技自研技術，加速大資料從持久化、統一化、資產化、業務化到生態化

從2013年成立開始，星環科技就專注於大資料基礎技術與企業資料業務的更好結合，同時面對中國更為複雜的資料應用場景，研發了多種更貼合國內大資料應用需求的大資料管理技術，在大資料技術領域有多項基礎技術突破。星環科技在堅持技術自研的道路上，創造了多個突破性 的技術成果，本篇介紹星環科技大資料技術。

— 星環科技大資料技術概述—

為了應對新的資料業務化需求，解決原有的技術問題，星環科技重新設計大資料技術棧，建立一個高度統一的資料平臺，能夠有效的解決大資料的4個V問題，打通大資料價值輸出的技術鏈條，從而加速大資料從持久化、統一化、資產化、業務化到生態化的價值路徑，這就是星環科技大資料3.0技術體系。

星環科技2015年即實現了基於Hadoop的分散式分析型資料庫，是第一個 支援完整的SQL標準、儲存過程、分散式事務的分散式分析型資料。同年推出低延時流計算引擎，在業界率先推出StreamSQL的SQL語言擴充套件，降低流應用開發的難度，同時推出延時低於5ms的計算引擎，遠低於Spark Streaming的計算延時。2017年在業內率先推出基於Docker和Kubernetes的大資料雲服務，實現大資料產品更好的跨平臺和雲化能力，是業內最早採用Kubernetes技術的廠商，而Cloudera到了2020年Q3才完成相關的研發工作。2018年釋出支援萬億級圖點和邊資料的分散式圖資料庫，提供了強大的圖分析與儲存能力，加速了認知智慧的計算。同年釋出基於快閃記憶體的新一代分散式分析資料庫，基於Raft協議和快閃記憶體自研的新一代列式儲存，能夠顯著的提升互動式分析效能，滿足資料倉儲和全量資料互動式分析的場景要求。

— 設計考量與總體架構  —

在設計之初，我們定義新一代的大資料技術必須具有以下特點： （1）統一融合的資料平臺，取代混合架構目前的企業資料業務架構中，往往需要包含資料湖、資料倉儲、資料集市、綜合搜尋等不同資料系統，很多企業採用複雜的混合架構，不僅產生龐大的資料冗餘，也嚴重限制了資料應用的時效性。新的大資料平臺需要能一站式的滿足所有需求，應對從快速響應到海量分析的各層級需求，淘汰混合架構的模式。 （2）開發方式的融合，SQL作為統一介面SQL作為經過歷史檢驗的結構化查詢語言，具有龐大的使用者群和靈活性，而以往透過API開發的方式存在應用相容性差、開發難度高等問題。新一代大資料平臺需要使用SQL來支援全部功能，包括資料倉儲、線上交易、搜尋引擎、時空資料庫等，降低開發者門檻，加快產品開發與上線速度。 （3）大資料雲化，推進大資料普惠化雲端計算的彈性和隨處接入可以讓更多的資料業務和開發者使用大資料技術，因此新的大資料技術需要能夠提供雲化的能力。在硬體層面上，大資料平臺對CPU、GPU、網路、儲存等資源進行統一管理和調配，基於容器技術實現雲上的大資料應用統一部署，平臺租戶按需申請大資料的技術和產品。 （4）大資料與應用生態的融合，支撐資料業務化和業務資料化資料業務化是大資料技術最終的價值體現，在資料層面上，平臺所有資料統一儲存，建立統一的資料倉儲與資料資產目錄，各業務部門根據需求呼叫；在模型層，透過建立模型市場，租戶訓練好的模型可以選擇一鍵釋出至模型市場，其他租戶直接呼叫。在應用層，平臺內使用者可將業務驗證過的應用釋出至企業級應用市場，共享給其他使用者，所有執行的應用被統一管理。為了滿足企業對大資料的更高的融合要求，同時能夠支撐新型的資料儲存和計算要求，星環科技整體上重新設計了大資料技術棧，同時儘量保證各個層級之間由通用的介面來打通，從而保證後續的可擴充套件性，避免了Hadoop技術的架構缺點，同時逐步完成了大資料基礎技術的自主研發，經過7年多的發展，整體技術棧已經基本完成了自研過程。

上圖是星環科技大資料技術棧的邏輯架構圖。自下而上，底層是可以管理和排程各種計算任務的資源排程層，我們選擇基於Kubernetes技術來打造。隨著資料應用的發展，計算任務不僅僅只是MapReduce，還可能是Spark、深度學習，甚至是MPI類的高效能運算任務，也可以是彈性的資料應用，因此專門為Hadoop設計的YARN就無法滿足需求。透過對Kubernetes和大資料底層的創新，我們的資源排程層不僅可以支撐各種計算任務，還可以與雲端計算底層打通，解決大資料雲化的問題。

為了更好的適應未來的資料儲存與分析的需求，支撐各種新的儲存引擎，我們抽象出了統一儲存管理層，能夠插拔不同的儲存引擎來實現對不同型別的資料的儲存、檢索和分析的請求。未來針對某些特定的應用可能都會有專用的分散式儲存引擎來支撐，在使用統一的分散式塊儲存管理層之後，架構師們只需要設計一個單機版本的儲存引擎或者檔案系統，並接入儲存管理層，就可以實現一個分散式儲存引擎，支援分散式事務、MVCC、索引、SQL表示式下推等功能，這樣可以極大的降低儲存開發的複雜度。

在塊儲存管理層之下就是各個資料庫核心或儲存，包括用於分析型資料庫的列式儲存、NoSQL的Bigtable、打造搜尋引擎的全文索引、面向圖計算的圖儲存引擎等，這些引擎接收上層的執行計劃，然後生成對儲存層的scan/put/write/事務等操作，完成特定的處理任務。

在儲存層之上就是統一的計算引擎層，我們選擇了基於DAG的計算模式來支援大資料的各種計算。相對於MPP模式，DAG計算能夠更好的適合大規模叢集之間的各種通訊和計算任務，並且有更高的可擴充套件性，能夠滿足包括圖計算、深度學習在內的多迭代的計算特性，同時透過程式碼生成等技術，也可以將效能最佳化到非常接近native程式碼的水平。

最上面是統一的開發介面層，對分析資料庫、交易資料庫等，我們透過標準的SQL開發介面提供給開發者，降低資料開發和分析的複雜度。此外，透過完善的SQL最佳化器設計，可以做到無需特殊的最佳化，SQL業務也能有非常高的效能，甚至比直接API級程式設計更好，而無需瞭解底層架構的細節。對於圖資料庫，我們提供Cypher語言介面，而最佳化器系統則全部複用SQL最佳化器。此外，開發介面層還提供了統一的事務處理單元，從而保證資料開發都有完整的事務保證，確保資料的ACID。

— 開發介面層  —

統一的開發介面層的核心是SQL編譯器、最佳化器和事務管理單元，它可以提供給開發者比較好的資料庫體驗，無需基於底層API來做業務開發，保證對傳統業務的支援程度，還可以更好的最佳化業務。

不同於傳統的大資料SQL引擎（如Hive），我們重新設計了SQL編譯器，它包含了三個Parser，可以從SQL、儲存過程或者Cypher語句生成語義表示式，以及一個分散式事務處理單元。一個SQL經過Parser處理後，會再經過4組不同的最佳化器來生成更優的執行計劃，最終將執行計劃推送給向量化的執行引擎層。

• lRBO（Rule-Based Optimizer）根據已有的專家規則進行最佳化，不同的儲存引擎或者資料庫開發者會提供專門的最佳化規則，目前我們已經積累了數百條最佳化規則。其中，最有效的最佳化規則都是針對IO相關的最佳化，如過濾下推、隱式過濾條件摺疊、基於分割槽或分桶的IO最佳化、Partition消除、多餘欄位消除等技術，將SQL中能夠節省掉的各種IO操作盡最大可能的消除，從而提升整體效能。
• ISO（Inter SQL Optimizer）用於儲存過程內部的最佳化，當一個儲存過程裡面有多個SQL存在類似的SQL查詢或分析的時候，它可以將這些操作合併在一起，從而減少不必要的計算任務或者SQL操作。為了讓儲存過程有較好的效能，PL/SQL解析器會根據儲存過程中的上下文關係來生成SQL DAG，然後對各SQL的執行計劃進行二次編譯，透過物理最佳化器將一些沒有依賴關係的執行計劃進行合併從而生成一個最終的物理執行計劃DAG。因此，一個儲存過程被解析成一個大的DAG從而stage之間可以大量併發執行，避免了多次執行SQL的啟動開銷並保證了系統的併發效能。
• MBO（Materialize-Based Optimizer）是基於物化檢視或Cube的最佳化器，如果資料庫中已經有物化檢視或Cube已構建好，而SQL操作能夠基於這個物化物件來最佳化的話，MBO就會生成對相應的物化物件的操作，從而減少計算量。
• CBO（Cost-Based Optimizer） 即基於成本的最佳化器，它會根據多個潛在的執行計劃的IO成本、網路成本和計算成本來選擇一個最優 的執行計劃，而成本的估算則來自後設資料服務。在未來，我們還計劃引入機器學習的能力，透過對歷史執行SQL的統計資訊的有效分析，生成更加健壯的執行計劃。一些非常有效的最佳化規則包括多表Join順序調優、JOIN型別選擇、任務併發度控制等。

SQL編譯器和最佳化器對大資料技術棧非常關鍵，正如我們在前序章節的分析結論，它是能夠決定整個技術的生態建設能否成功的關鍵。除了SQL介面外，分散式事務和介面對大資料技術棧也是非常關鍵的組成。可以複雜的系統架構和容錯設計下保證資料的一致性，以及有多種事務隔離級別的支援，從而能夠擴充資料庫去支撐更多的應用。

— 計算引擎層  —

我們的執行引擎選擇了基於DAG的模式，此外為了有更好的執行效率，我們使用量化執行引擎技術來加速資料處理。量化執行引擎即每次計算對批次的資料進行處理，而不是逐個記錄。對列式的資料儲存，向量執行引擎有非常高的提速效果。另外與學術界很多研究進展相似，星環科技也採用的是同一個計算引擎支援實時計算和離線計算，從而更好支援流批統一的業務場景。 在解決資料庫的計算效能的可擴充套件性的方法上，目前主流的計算框架有兩種，一種是基於MPP（Massive Parallel Processing）的加速方式，另一種是基於DAG（Directed Acyclic Graph）。整體上來看，基於MPP的方式在容錯性、可擴充套件性和對業務的適配上靈活性不足，不能滿足我們對未來多樣化的資料服務支撐的需求，因此我們選擇了基於DAG的計算模式，同時在它的基礎上深度最佳化執行效能，既能支援更多樣化的資料計算需求，也能夠獲得極好的效能。

技術點	MPP	DAG
SQL編譯	依賴單機資料庫的SQL能力	自研SQL編譯器
資料儲存	Share nothing架構	共享分散式儲存架構
後設資料資訊	比較有限的meta資訊，全域性的計算任務的最佳化有難度	有全域性的meta資訊，可以更好地協調executor之間的資料通訊、任務啟停
Shard內效能	本地庫的執行速度高，理論上是DAG的上限	可以透過執行器、Codegen等技術來最佳化效能
容錯性	依賴各個資料庫完成切分任務，因此容錯性不足	共享資料儲存，Task的設計上可以簡單、有冪等性，更好容錯
資料通訊效能	依賴資料分佈來減少資料通訊的效能損耗，因此不靈活	依賴全域性的資料元資訊來減少通訊的效能損耗，更加靈活
核心優勢	最佳化器成熟，本地執行效能更好	靈活性、容錯性更高，能夠更好的減少資料通訊消耗
架構問題	總體效能依賴業務特性和資料分佈部分MPP的可擴充套件性還需要提高	SQL、事務、最佳化器等仍需持續改進，基本逼近MPP的效能

從2018年開始，企業對實時計算的需求的增長非常迅速，此外由於實時計算多是生產系統，相對於分析系統在技術上也有更高的要求，包括：

• 高併發：瞬間高併發的資料操作或者分析
• 低延時：要求毫秒級的處理響應時間
• 準確性：資料不丟不重、業務高可用
• 業務連續性：線上對接生產的資料業務

為了能夠系統的適應業務需求，我們放棄了對Spark或者Flink等開源方案，而是完整的設計了整個的實時計算產品。首先，我們重新設計了流計算引擎的計算模式，保證其對資料流的計算延時能夠低至5毫秒級別，同時必要完整的設計了整個資料通路，確保其資料的不丟不重，以及整個鏈路的安全性。

此外，在計算模式上，流資料不僅可以跟其他時間視窗的資料進行復雜計算，還需要跟歷史資料（持久化在各種資料庫中的資料）進行計算，因此我們引入了CEP引擎(Complex Event Processing Engine)，能夠對多個輸入事件進行計算，執行包括複雜模式的匹配和聚合計算等，也支援各種滑動視窗類計算，同時也可以與歷史資料或持久化資料進行關聯計算。對於複雜的應用業務，我們設計了規則引擎（Rule Engine）來處理業務規則，並且可以相容其他規則引擎設計的業務規則，從而可以實現複雜的業務規則。最後為了更好的應對業務指標，我們也在流引擎中增加了基於記憶體的分散式快取，用於加速資料指標的高速儲存和讀取，同時支援資料的訂閱與釋出。

在SQL模型層，我們定義了StreamSQL的SQL語言擴充套件，新增了Stream、Stream Application和Stream Job等物件。一個Stream用於接收從一個資料來源傳來的資料，可以是直接接收，也可以對資料進行一定的轉換操作。一個Stream Job定義了具體的流上的資料操作邏輯，如規則匹配邏輯、實時ETL邏輯等。一個Stream Application是一組業務邏輯相關的Stream Job的組合。

— 分散式塊儲存管理層  —

統一的分散式塊儲存管理層，是我們對新一代大資料技術做的重大改造。資料的一致性是分散式系統的根基，Paxos協議的出現在理論上保證其可行性，而之後更加簡潔的Raft協議在工程的實現上更加高效。而工程上多個開源分散式儲存在實現資料高可用和資料一致性的方式上也有不少的不足。譬如Cassandra在架構上能夠保證高可用，但是它會存在Replica資料不一致的問題，此外也無法支援事務性操作；HBase底層使用HDFS保證資料持久化和一致性，但是HMaster採用了主備的方式，切換過程可能比較長，因此有單點故障問題，不能保證可用性；Elasticsearch也類似，分割槽內資料的一致性在生產中也是一個問題。

隨著企業資料業務發展的深入，更多的專用儲存引擎的需求會被引入，譬如專門面向地理資訊的資料儲存與分析、圖資料、高維度特徵的儲存與計算等專用場景，再加上對現有的4大類NoSQL儲存的需求，針對每個場景去實現單獨的儲存引擎工作量非常大，也有重複造輪子問題。

為了解決這個問題，我們將各個分散式儲存的通用的部分抽象出來放在儲存管理層，包括資料的一致性、儲存引擎的最佳化介面、事務的操作介面、MVCC介面、分散式的後設資料管理、資料分割槽策略、容錯與災備策略等功能，透過自研的基於Raft的分散式控制層來協同各個角色。各個儲存引擎只需要實現其單機的儲存引擎，然後接入統一的儲存管理層就可以成為一個高可用的分散式儲存系統。

在實現上，我們使用Raft協議來做各個儲存之間的一致性保證，主要包括：

• 各個單機儲存組成的tablet副本之間的狀態機同步
• Master的選主和狀態機同步
• 事務協同組的選主和狀態機同步
• 儲存服務的恢復服務能力
• 其他管理運維能力

— 資源排程層  —

類似於作業系統的排程模組，資源排程層是整個大資料平臺能夠有效執行的關鍵技術。下圖是資源排程層的總體架構，底 層是Kubernetes服務，在其上層執行著我們自研的產品或服務。其中配置中心用於實時的收集和管理雲平臺內執行的服務的配置引數；物理資源池是透過各個資源池化後的邏輯資源；雲端儲存服務是基於本地儲存開發的分散式儲存服務，會持久化有狀態服務的資料，保證應用資料的最終持久化和系統災備能力；雲網路是自研的網路服務，提供應用和租戶類似VPC的網路能力。在此之上是雲排程系統，它接收應用的輸入，從配置中心、標籤中心、雲端儲存和網路服務中獲取實時的執行指標，從資源池中獲取資源的使用情況，從而根據執行時的資訊進行精準 的排程決策。排程系統之上就是各類的應用服務，包括大資料、AI、資料庫類，以及各種微服務，也就是雲平臺可以良好支撐的各種應用。

— 小結—

本篇介紹了星環科技大資料技術，未來星環科技將繼續完善這個新的大資料架構體系，增加更多的新型資料儲存與計算能力，同時完善資料業務化的技術拼圖，包括基於機器學習的資料治理、資料服務釋出等能力，進一步夯實資料與業務之間的技術缺口，讓大資料技術更好的發揮出價值。