深度 | 一條查詢SQL的前世今生 —— ClickHouse 源碼閱讀

作者:逍凱,阿里雲數據庫實習開發工程師
注:以下分析基於開源 v19.15.2.2-stable 版本進行,社區最新版本代碼改動較大,但是總體思路是不變的。

一、 用戶提交一條查詢SQL背後發生了什麼

在傳統關係型數據庫中,SQL處理器的組件主要包括以下幾種:
• Query Parsing
負責進行詞法和語法分析,把程序從人類高可讀的格式(即SQL)轉化成機器高可讀的格式(AST,抽象語法樹)。
詞法分析指的是把SQL中的字符序列分解成一個個獨立的詞法單元——Token(<類型,值>)。
語法分析指的是從詞法分析器輸出的token中識別各類短語,並構造出一顆抽象語法樹。而按照構造抽象語法樹的方向,又可以把語法分析分成自頂向下和自底向上分析兩種。而ClickHouse採用的則是手寫一個遞歸下降的語法分析器。

• Query Rewrite
即通常我們說的"Logical Optimizer"或基於規則的優化器(Rule-Based Optimizer,即RBO)。
其負責應用一些啓發式規則,負責簡化和標準化查詢,無需改變查詢的語義。
常見操作有:謂詞和算子下推,視圖展開,簡化常量運算表達式,謂詞邏輯的重寫,語義的優化等。

• Query Optimizer
即通常我們所說的"Physical Optimizer",負責把內部查詢表達轉化成一個高效的查詢計劃,指導DBMS如何去取表,如何進行排序,如何Join。如下圖所示,一個查詢計劃可以被認爲是一個數據流圖,在這個數據流圖中,表數據會像在管道中傳輸一樣,從一個查詢操作符(operator)傳遞到另一個查詢操作符。

• Query Executor
查詢執行器,負責執行具體的查詢計劃,從存儲引擎中獲取數據並且對數據應用查詢計劃得到結果。
執行引擎也分爲很多種,如經典的火山模型(Volcano Model),還有ClickHouse採用的向量化執行模型(Vectorization Model)。

但不管是傳統的關係型數據庫,還是非關係型數據庫,SQL的解析和生成執行計劃過程都是大同小異的,而縱覽ClickHouse的源代碼,可以把用戶提交一條查詢SQL背後的過程總結如下:
1.服務端接收客戶端發來的SQL請求,具體形式是一個網絡包,Server的協議層需要拆包把SQL解析出來
2.Server負責初始化上下文與Network Handler,然後 Parser 對Query做詞法和語法分析,解析成AST
3.Interpreter的 SyntaxAnalyzer 會應用一些啓發式規則對AST進行優化重寫
4.Interpreter的 ExpressionAnalyzer 根據上下文信息以及優化重寫後的AST生成物理執行計劃
5.物理執行計劃分發到本地或者分佈式的executor,各自從存儲引擎中獲取數據,應用執行計劃
6.Server把執行後的結果以Block流的形式輸出到Socket緩衝區,Client從Socket中讀取即可得到結果


01接收客戶端請求

我們要以服務端的視角來出發,首先來看server.cpp大概做什麼事情:
下面只挑選重要的邏輯:
• 初始化上下文
• 初始化Zookeeper(ClickHouse的副本複製機制需要依賴ZooKeeper)
• 常規配置初始化
• 綁定服務端的端口,根據網絡協議初始化Handler,對客戶端提供服務

int Server::main()
{
// 初始化上下文
global_context = std::make_unique<Context>(Context::createGlobal());
global_context->setApplicationType(Context::ApplicationType::SERVER);

// zk初始化
zkutil::ZooKeeperNodeCache main_config_zk_node_cache([&] { return global_context->getZooKeeper(); });

//其他config的初始化
//...

//綁定端口,對外提供服務
auto address = make_socket_address(host, port);
socket.bind(address, /* reuseAddress = */ true);

//根據網絡協議建立不同的server類型
//現在支持的server類型有:HTTP,HTTPS,TCP,Interserver,mysql
//以TCP版本爲例:
create_server("tcp_port", [&](UInt16 port)
{
    Poco::Net::ServerSocket socket;
    auto address = socket_bind_listen(socket, listen_host, port);
    servers.emplace_back(std::make_unique<Poco::Net::TCPServer>(
        new TCPHandlerFactory(*this),
        server_pool,
        socket,
        new Poco::Net::TCPServerParams));
 });

//啓動server
for (auto & server : servers)
        server->start();

}`</pre>

客戶端發來的請求是由各自網絡協議所對應的 Handler 來進行的,server在啓動的時候 Handler 會被初始化並綁定在指定端口中。我們以TCPHandler爲例,看看服務端是如何處理客戶端發來的請求的,重點關注 TCPHandler::runImpl 的函數實現:
• 初始化輸入和輸出流的緩衝區
• 接受請求報文,拆包
• 執行Query(包括整個詞法語法分析,Query重寫,物理計劃生成和生成結果)
• 把Query結果保存到輸出流,然後發送到Socket的緩衝區,等待發送回客戶端

void TCPHandler::runImpl()
{
//實例化套接字對應的輸入和輸出流緩衝區
in = std::make_shared<ReadBufferFromPocoSocket>(socket());
out = std::make_shared<WriteBufferFromPocoSocket>(socket());

while (1){
    // 接收請求報文
    receivePacket();

    // 執行Query
    state.io = executeQuery(state.query, *query_context, false, state.stage, may_have_embedded_data);

    //根據Query種類來處理不同的Query
    //處理insert Query
    processInsertQuery();
    //併發處理普通Query
    processOrdinaryQueryWithProcessors();
    //單線程處理普通Query
    processOrdinaryQuery();
}

}`</pre>

那CK處理客戶端發送過來的Query的具體邏輯是怎樣的呢?
我們可以在dbms/src/Interpreters/executeQuery.cpp 中一探究竟:
具體邏輯在 executeQueryImpl 函數中,挑選核心的邏輯進行講解:

static std::tuple<ASTPtr, BlockIO> executeQueryImpl()
{
//構造Parser
ParserQuery parser(end, settings.enable_debug_queries);
ASTPtr ast;

//把Query轉化爲抽象語法樹
ast = parseQuery(parser, begin, end, "", max_query_size);

//生成interpreter實例
auto interpreter = InterpreterFactory::get(ast, context, stage);

// interpreter解析AST,結果是BlockIO
res = interpreter->execute();

//返回結果是抽象語法樹和解析後的結果組成的二元組
return std::make_tuple(ast, res);

}`</pre>

該函數所做的事情:
• 構建Parser,把Query解析成AST(抽象語法樹)
• InterpreterFactory根據AST生成對應的Interpreter實例
• AST是由Interpreter來解析的,執行結果是一個BlockIO,BlockIO是對 BlockInputStreamBlockOutputStream 的一個封裝。

總結:
• 服務端調用 executeQuery 來處理client發送的Query,執行後的結果保存在state這個結構體的io成員中。
每一條Query都會對應一個state結構體,記錄了這條Query的id,處理狀態,壓縮算法,Query的文本和Query所處理數據對應的IO流等元信息。
• 然後服務端調用 processOrdinaryQuery 等方法把輸出流結果封裝成異步的IO流,發送到回client。


02 解析請求(Parser)

CK選擇採用手寫一個遞歸下降的Parser來對SQL進行解析,生成的結果是這個SQL對應的抽象語法樹(AST),抽象語法樹由表示各個操作的節點(IAST)表示。而本節主要介紹Parser背後的核心邏輯:
詞法分析和語法分析的核心邏輯可以在parseQuery.cpp的 tryParseQuery 中一覽無餘。
該函數利用lexer將掃描Query字符流,將其分割爲一個個的Token, token_iterator 即一個Token流迭代器,然後parser再對Token流進行解析生成AST抽象語法樹。

我們可以看到,語法分析的核心就在於parser執行的parse方法。parse 方法具體的實現在 ParserQuery.cppparseImpl 中。

bool ParserQuery::parseImpl(Pos & pos, ASTPtr & node, Expected & expected)
{
ParserQueryWithOutput query_with_output_p(enable_explain);
ParserInsertQuery insert_p(end);
ParserUseQuery use_p;
ParserSetQuery set_p;
ParserSystemQuery system_p;

bool res = query_with_output_p.parse(pos, node, expected)
    || insert_p.parse(pos, node, expected)
    || use_p.parse(pos, node, expected)
    || set_p.parse(pos, node, expected)
    || system_p.parse(pos, node, expected);

return res;

}`</pre>

我們可以看到,這個方法粗略地把Query分爲了五種,但是本質上可以歸納爲兩種(第一種爲有結果輸出,對應show,select,create等語句;第二種爲無結果輸出,對應insert,use,set和與系統相關的語句(如exit))
• QueryWithOutput
• InsertQuery
• UseQuery
• SetQuery
• SystemQuery
每一種Query都自定義了其專屬的Parser,所以代碼邏輯是當接收到一個Query輸入的時候,會嘗試各種Query的Parser,直到成功爲止。
我們可以select語句對應的parser進行分析:
核心邏輯可以總結爲:
1.先給出select語句中可能出現的關鍵詞
2.在詞法分析生成的Token流中爬取這些關鍵詞
3.如果成功爬取,則 setExpression 函數會組裝該關鍵字對應的AST節點每一種SQL語句(如select,drop,insert,create)都有對應的AST類,並且分別包含了這些語句中特有的關鍵字。

bool ParserSelectQuery::parseImpl(Pos & pos, ASTPtr & node, Expected & expected)
{
//創建AST樹節點
auto select_query = std::make_shared<ASTSelectQuery>();
node = select_query;

//select語句中會出現的關鍵詞
ParserKeyword s_select("SELECT");
ParserKeyword s_distinct("DISTINCT");
ParserKeyword s_from("FROM");
ParserKeyword s_prewhere("PREWHERE");
ParserKeyword s_where("WHERE");
ParserKeyword s_group_by("GROUP BY");
ParserKeyword s_with("WITH");
ParserKeyword s_totals("TOTALS");
ParserKeyword s_having("HAVING");
ParserKeyword s_order_by("ORDER BY");
ParserKeyword s_limit("LIMIT");
ParserKeyword s_settings("SETTINGS");
ParserKeyword s_by("BY");
ParserKeyword s_rollup("ROLLUP");
ParserKeyword s_cube("CUBE");
ParserKeyword s_top("TOP");
ParserKeyword s_with_ties("WITH TIES");
ParserKeyword s_offset("OFFSET");

//...
//依次對Token流爬取上述關鍵字
ParserTablesInSelectQuery().parse(pos, tables, expected)

//根據語法分析結果設置AST的Expression屬性,可以理解爲如果SQL存在該關鍵字,這個關鍵字都會轉化爲AST上的一個節點
select_query->setExpression(ASTSelectQuery::Expression::WITH, std::move(with_expression_list));
select_query->setExpression(ASTSelectQuery::Expression::SELECT, std::move(select_expression_list));
select_query->setExpression(ASTSelectQuery::Expression::TABLES, std::move(tables));
select_query->setExpression(ASTSelectQuery::Expression::PREWHERE, std::move(prewhere_expression));
select_query->setExpression(ASTSelectQuery::Expression::WHERE, std::move(where_expression));
select_query->setExpression(ASTSelectQuery::Expression::GROUP_BY, std::move(group_expression_list));
select_query->setExpression(ASTSelectQuery::Expression::HAVING, std::move(having_expression));
select_query->setExpression(ASTSelectQuery::Expression::ORDER_BY, std::move(order_expression_list));
select_query->setExpression(ASTSelectQuery::Expression::LIMIT_BY_OFFSET, std::move(limit_by_offset));
select_query->setExpression(ASTSelectQuery::Expression::LIMIT_BY_LENGTH, std::move(limit_by_length));
select_query->setExpression(ASTSelectQuery::Expression::LIMIT_BY, std::move(limit_by_expression_list));
select_query->setExpression(ASTSelectQuery::Expression::LIMIT_OFFSET, std::move(limit_offset));
select_query->setExpression(ASTSelectQuery::Expression::LIMIT_LENGTH, std::move(limit_length));
select_query->setExpression(ASTSelectQuery::Expression::SETTINGS, std::move(settings));

}`</pre>

整個Parser的流程圖:


03 執行請求(Interpreter)

解釋器(Interpreter)負責從抽象語法樹中創建查詢執行的流水線,整條流水線以 BlockInputStreamBlockOutputStream 進行組織。比方說"select"是基於"from"的Block輸出流來進行選擇的,選擇後的結果也會以Block輸出流的形式輸出到結果。首先我們來看:
dbms/src/Interpreters/InterpreterFactory.cpp
每一種Query都會有對應的Interpreter,這個工廠方法就是根據AST的種類來實例化其對應的Interpreter,由其來具體執行對應AST的執行計劃:

<pre style="margin: 0px 0px 16px; padding: 16px; max-width: 100%; box-sizing: border-box; overflow-wrap: normal; overflow: auto; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 13.6px; background-color: rgb(246, 248, 250); border-radius: 3px; line-height: 1.45; caret-color: rgb(36, 41, 46); color: rgb(36, 41, 46); text-align: start; text-size-adjust: auto;">std::unique_ptr<IInterpreter> InterpreterFactory::get(ASTPtr & query, Context & context, QueryProcessingStage::Enum stage) { //舉個例子,如果該AST是由select語句轉化過來, if (query->as<ASTSelectQuery>()) { /// This is internal part of ASTSelectWithUnionQuery. /// Even if there is SELECT without union, it is represented by ASTSelectWithUnionQuery with single ASTSelectQuery as a child. return std::make_unique<InterpreterSelectQuery>(query, context, SelectQueryOptions(stage)); } }</pre>

我們就以 InterpreterSelectQuery 爲例,瞭解其實例化的核心邏輯:
InterpreterSelectQuery::InterpreterSelectQuery()
{
//獲取AST
auto & query = getSelectQuery();

//對AST做進一步語法分析,對語法樹做優化重寫
syntax_analyzer_result = SyntaxAnalyzer(context, options).analyze(
    query_ptr, source_header.getNamesAndTypesList(), required_result_column_names, storage, NamesAndTypesList());

//每一種Query都會對應一個特有的表達式分析器,用於爬取AST生成執行計劃(操作鏈)
query_analyzer = std::make_unique<SelectQueryExpressionAnalyzer>(
    query_ptr, syntax_analyzer_result, context,
    NameSet(required_result_column_names.begin(), required_result_column_names.end()),
    options.subquery_depth, !options.only_analyze);

}`</pre>

語法分析直接生成的AST轉化成執行計劃可能性能上並不是最優的,因此需要SyntaxAnalyzer對其進行優化重寫,在其源碼中可以看到其涉及到非常多 基規則****優化(rule based optimization) 的trick。
SyntaxAnalyzer會逐個針對這些規則對查詢進行檢查,確定其是否滿足轉換規則,一旦滿足就會對其進行轉換。

SyntaxAnalyzer::analyze()
{
// 剔除冗餘列
removeDuplicateColumns(result.source_columns);

 // 根據settings中enable_optimize_predicate_expression配置判斷是否進行謂詞下移
 replaceJoinedTable(node);

 // 根據settings中distributed_product_mode配置重寫IN 與 JOIN 表達式
 InJoinSubqueriesPreprocessor(context).visit(query);

 // 優化Query內部的布爾表達式
 LogicalExpressionsOptimizer().perform();

 // 創建一個從別名到AST節點的映射字典
 QueryAliasesVisitor(query_aliases_data, log.stream()).visit(query);

 // 公共子表達式的消除
 QueryNormalizer(normalizer_data).visit(query);

 // 消除select從句後的冗餘列
 removeUnneededColumnsFromSelectClause(select_query, required_result_columns, remove_duplicates);

 // 執行標量子查詢,並且用常量替代標量子查詢結果
 executeScalarSubqueries(query, context, subquery_depth);

 // 如果是select語句還會做下列優化:

 // 謂詞下移優化
 PredicateExpressionsOptimizer(select_query, settings, context).optimize();

 /// GROUP BY 從句的優化
 optimizeGroupBy(select_query, source_columns_set, context);

 /// ORDER BY 從句的冗餘項剔除
 optimizeOrderBy(select_query);

 /// LIMIT BY 從句的冗餘列剔除
 optimizeLimitBy(select_query);

 /// USING語句的冗餘列剔除
 optimizeUsing(select_query);

}`</pre>

這裏挑選幾個簡單介紹一下:
• 公共子表達式消除(Common Subexpression Elimination)
如果表達式x op y先前被計算過,並且從先前的計算到現在其計算表達式對應的值沒有改變,那麼 x op y 就稱爲公共子表達式。公共子表達式消除會搜索所有相同計算表達式的實例,並分析是否值得用保存計算值的單個變量來替換它們,以減少計算的開銷。
• 標量子查詢(Scala Subquery)的常量替換
標量子查詢就是返回單一值的子查詢,和公共子表達式消除相似,可以用常量來替換SQL中所有的標量子查詢結果以減少計算開銷。
• 謂詞下移(Predicate Pushdown)
把外層查詢塊中的WHERE子句的謂詞下移到較低層查詢塊如視圖,以儘可能把過濾數據的操作移動到靠近數據源的位置。提前進行數據過濾能夠大幅減少網絡傳輸或者內存讀取訪問的數據量,以提高查詢效率。
query_analyzer的作用可以理解爲解析優化重寫後的AST,然後對所要進行的操作組成一條操作鏈,即物理執行計劃,如:

<pre style="margin: 0px 0px 16px; padding: 16px; max-width: 100%; box-sizing: border-box; overflow-wrap: normal; overflow: auto; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 13.6px; background-color: rgb(246, 248, 250); border-radius: 3px; line-height: 1.45; caret-color: rgb(36, 41, 46); color: rgb(36, 41, 46); text-align: start; text-size-adjust: auto;">ExpressionActionsChain chain; analyzer.appendWhere(chain); chain.addStep(); analyzer.appendSelect(chain); analyzer.appendOrderBy(chain); chain.finalize();</pre>

上述代碼把where,select,orderby操作都加入到操作鏈中,接下來就可以從Storage層讀取Block,對Block數據應用上述操作鏈的操作。而執行的核心邏輯,就在對應Interpreter的 executeImpl 方法實現中,這裏以select語句的Interpreter來了解下讀取Block數據並且對block數據進行相應操作的流程。
<pre style="margin: 0px 0px 16px; padding: 16px; max-width: 100%; box-sizing: border-box; overflow-wrap: normal; overflow: auto; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 13.6px; background-color: rgb(246, 248, 250); border-radius: 3px; line-height: 1.45; caret-color: rgb(36, 41, 46); color: rgb(36, 41, 46); text-align: start; text-size-adjust: auto;">`void InterpreterSelectQuery::executeImpl(TPipeline & pipeline, const BlockInputStreamPtr & prepared_input)
{
// 對應Query的AST
auto & query = getSelectQuery();

 AnalysisResult expressions;
 // 物理計劃,判斷表達式是否有where,aggregate,having,order_by,litmit_by等字段
 expressions = analyzeExpressions(
            getSelectQuery(),
            *query_analyzer,
            QueryProcessingStage::FetchColumns,
            options.to_stage,
            context,
            storage,
            true,
            filter_info);

 // 從Storage讀取數據
 executeFetchColumns(from_stage, pipeline, sorting_info, expressions.prewhere_info, expressions.columns_to_remove_after_prewhere);

 // eg:根據SQL的關鍵字在BlockStream流水線中執行相應的操作, 如where,aggregate,distinct都分別由一個函數負責執行
 executeWhere(pipeline, expressions.before_where, expressions.remove_where_filter);

 executeAggregation(pipeline, expressions.before_aggregation, aggregate_overflow_row, aggregate_final);

 executeDistinct(pipeline, true, expressions.selected_columns);

}`</pre>

既然我們知道了執行計劃AnalysisResult(即物理執行計劃),接下來就需要從storage層中讀取數據來執行對應的操作,核心邏輯在 executeFetchColumns 中:核心操作就是從storage層讀取所要處理列的Block,並組織成BlockStream。

<pre style="margin: 0px 0px 16px; padding: 16px; max-width: 100%; box-sizing: border-box; overflow-wrap: normal; overflow: auto; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 13.6px; background-color: rgb(246, 248, 250); border-radius: 3px; line-height: 1.45; caret-color: rgb(36, 41, 46); color: rgb(36, 41, 46); text-align: start; text-size-adjust: auto;">void InterpreterSelectQuery::executeFetchColumns( QueryProcessingStage::Enum processing_stage, TPipeline & pipeline, const SortingInfoPtr & sorting_info, const PrewhereInfoPtr & prewhere_info, const Names & columns_to_remove_after_prewhere) { // 實例化Block Stream auto streams = storage->read(required_columns, query_info, context, processing_stage, max_block_size, max_streams) // 讀取列對應的Block,並且組織成Block Stream streams = {std::make_shared<NullBlockInputStream>(storage->getSampleBlockForColumns(required_columns))}; streams.back() = std::make_shared<ExpressionBlockInputStream>(streams.back(), query_info.prewhere_info->remove_columns_actions); }</pre>

讀取完Block Stream之後就是對其執行各種execute操作如 executeAggregation , executeWhere 操作,詳見 InterpreterSelectQuery::executeImpl 的代碼。因此Interpreter的處理過程可以總結爲:
• 對AST進行優化重寫
• 解析重寫後的AST並生成操作鏈(執行計劃)
• 從存儲引擎中讀取要處理的Block數據
• 對讀取的Block數據應用操作鏈上的操作
那我們讀取Block Stream並進行處理後,生成的結果如何寫回到storage層呢?我們這裏以insert語句的Interpreter來了解下:

<pre style="margin: 0px 0px 16px; padding: 16px; max-width: 100%; box-sizing: border-box; overflow-wrap: normal; overflow: auto; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 13.6px; background-color: rgb(246, 248, 250); border-radius: 3px; line-height: 1.45; caret-color: rgb(36, 41, 46); color: rgb(36, 41, 46); text-align: start; text-size-adjust: auto;">`BlockIO InterpreterInsertQuery::execute()
{
// table爲存儲引擎接口
StoragePtr table = getTable(query);
BlockOutputStreamPtr out;

// 從存儲引擎讀取Block Stream
auto query_sample_block = getSampleBlock(query, table);
out = std::make_shared<AddingDefaultBlockOutputStream>(
    out, query_sample_block, out->getHeader(), table->getColumns().getDefaults(), context);

//執行結果封裝成BlockIO
BlockIO res;
res.out = std::move(out);

}`</pre>

上面代碼中的StoragePtr實際上就是IStorage這個存儲引擎的接口

<pre style="margin: 0px 0px 16px; padding: 16px; max-width: 100%; box-sizing: border-box; overflow-wrap: normal; overflow: auto; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 13.6px; background-color: rgb(246, 248, 250); border-radius: 3px; line-height: 1.45; caret-color: rgb(36, 41, 46); color: rgb(36, 41, 46); text-align: start; text-size-adjust: auto;">using StoragePtr = std::shared_ptr<IStorage>;</pre>

無論是寫入還是讀取操作都是依靠底層存儲引擎(如MergeTree)的write和read接口來實現的,關於存儲引擎的細節實現這裏暫時不贅述,這裏我們只需要知道我們從存儲引擎接口中以流方式讀取Block數據,而結果組織成BlockIO流輸出。Interpreter的流程總結如下:


04 返回請求結果

TCPHandler::runImpl中,執行完executeQuery之後需要調用各種processQuery的方法來給client返回執行SQL後的結果。
我們以TCPHandler::processOrdinaryQuery爲例做簡單分析:

<pre style="margin: 0px 0px 16px; padding: 16px; max-width: 100%; box-sizing: border-box; overflow-wrap: normal; overflow: auto; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 13.6px; background-color: rgb(246, 248, 250); border-radius: 3px; line-height: 1.45; caret-color: rgb(36, 41, 46); color: rgb(36, 41, 46); text-align: start; text-size-adjust: auto;">`void TCPHandler::processOrdinaryQuery()
{
//把BlockStream封裝成異步的Stream,那麼從流中讀取數據將會是異步操作
AsynchronousBlockInputStream async_in(state.io.in);

while(true){
     Block block;
     //從IO流讀取block數據
     block = async_in.read();
     //發送block數據
     sendData(block);
}

}`</pre>

Server負責在sendData函數中把輸出結果寫入到套接字輸出緩衝區中,client只要從這個輸出緩衝區讀取就能夠得到結果。
<pre style="margin: 0px 0px 16px; padding: 16px; max-width: 100%; box-sizing: border-box; overflow-wrap: normal; overflow: auto; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 13.6px; background-color: rgb(246, 248, 250); border-radius: 3px; line-height: 1.45; caret-color: rgb(36, 41, 46); color: rgb(36, 41, 46); text-align: start; text-size-adjust: auto;">`void TCPHandler::sendData(const Block & block)
{
//初始化OutputStream的參數
initBlockOutput(block);

// 調用BlockOutputStream的write函數,把Block寫到輸出流
state.block_out->write(block);
state.maybe_compressed_out->next();
out->next();

}`</pre>

二、結語

瞭解ClickHouse背後SQL的查詢整個流程,不僅能讓數據庫使用者更清晰地認識到如何編寫最優化的SQL,也能夠讓數據庫內核開發者加深對數據庫體系結構的理解,提高開發效率。
本文並沒有涉及到太深入的技術細節,諸如向量化執行引擎,SIMD,基於llvm的動態代碼生成,類MergeTree存儲引擎等CK的技術細節也沒有提及,只是從宏觀角度給讀者介紹了執行SQL背後內核到底發生了什麼。後續我們會推出更多內核源碼解讀文章,敬請關注。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章