You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@doris.apache.org by ji...@apache.org on 2022/12/14 10:32:04 UTC
[doris-website] branch master updated: BestPractice_Kwai
This is an automated email from the ASF dual-hosted git repository.
jiafengzheng pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/doris-website.git
The following commit(s) were added to refs/heads/master by this push:
new 280e7894841 BestPractice_Kwai
280e7894841 is described below
commit 280e7894841aa09755aae6d00020b716ac7568a5
Author: jiafeng.zhang <zh...@gmail.com>
AuthorDate: Wed Dec 14 18:31:51 2022 +0800
BestPractice_Kwai
BestPractice_Kwai
---
blog/BestPractice_Kwai.md | 178 ++++++++++++++++++++
.../BestPractice_Kwai.md | 181 +++++++++++++++++++++
static/images/Kwai/en/kv.png | Bin 0 -> 442743 bytes
static/images/Kwai/en/page_1.png | Bin 0 -> 27315 bytes
static/images/Kwai/en/page_2.png | Bin 0 -> 42814 bytes
static/images/Kwai/en/page_3.png | Bin 0 -> 149336 bytes
static/images/Kwai/en/page_4.png | Bin 0 -> 63176 bytes
static/images/Kwai/en/page_5.png | Bin 0 -> 51498 bytes
static/images/Kwai/en/page_6.png | Bin 0 -> 61437 bytes
static/images/Kwai/en/page_7.png | Bin 0 -> 51386 bytes
static/images/Kwai/en/page_8.png | Bin 0 -> 56820 bytes
static/images/Kwai/zh/1.png | Bin 0 -> 77980 bytes
static/images/Kwai/zh/2.png | Bin 0 -> 191089 bytes
static/images/Kwai/zh/3.png | Bin 0 -> 167018 bytes
static/images/Kwai/zh/4.png | Bin 0 -> 88103 bytes
static/images/Kwai/zh/5.png | Bin 0 -> 46722 bytes
static/images/Kwai/zh/6.png | Bin 0 -> 61400 bytes
static/images/Kwai/zh/7.png | Bin 0 -> 45673 bytes
static/images/Kwai/zh/8.png | Bin 0 -> 56144 bytes
static/images/Kwai/zh/kv.png | Bin 0 -> 442743 bytes
20 files changed, 359 insertions(+)
diff --git a/blog/BestPractice_Kwai.md b/blog/BestPractice_Kwai.md
new file mode 100644
index 00000000000..2fe1a306cc9
--- /dev/null
+++ b/blog/BestPractice_Kwai.md
@@ -0,0 +1,178 @@
+---
+{
+ 'title': 'Best Practice in Kwai: Apache Doris on Elasticsearch',
+ 'language": "en'
+ 'summary': "This article mainly focuses on the practice of Apache Doris on Elasticsearch (DOE) in Kwai's business.Kwai’s commercial report engine provides advertisers with real-time query service for multi-dimensional analysis reports. And it also provides query service for multi-dimensional analysis reports for internal users. The engine is committed to dealing with high-performance, high-concurrency, and high-stability query problems in multi-dimensional analysis report cases. Afte [...]
+ 'date': '2022-12-14',
+ 'author': 'Xiang He',
+ 'tags': ['Best Practice'],
+}
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+> Author: Xiang He, Head Developer of Big Data, Commercialization Team of Kwai
+
+
+
+# 1 About Kwai
+
+## 1.1 Kwai
+Kwai(HKG:1024) is a social network for short videos and trends. Discover funny short videos, contribute to the virtual community with recordings, videos of your life, playing daily challenges or likes the best memes and videos. Share your life with short videos and choose from dozens of magical effects and filters for them.
+
+## 1.2 Kwai's Commercial Report Engine
+Kwai’s commercial report engine provides advertisers with real-time query service for multi-dimensional analysis reports. And it also provides query service for multi-dimensional analysis reports for internal users. The engine is committed to dealing with high-performance, high-concurrency, and high-stability query problems in multi-dimensional analysis report cases.
+
+# 2 Previous Architecture
+
+## 2.1 Background
+Traditional OLAP engines deal with multi-dimensional analysis in a more pre-modeled way, by building a data cube (Cube) to perform operations such as Drill-down, Roll-up, Slice, and Dice and Pivot. Modern OLAP analysis introduces the idea of a relational model, representing data in two-dimensional relational tables. In the modeling process, usally there are two modeling methods. One is to ingest the data of multiple tables into one wide table through Join; the other is to use the star [...]
+Both options have some pros and cons:
+
+Wide table:
+
+Taking the idea of exchanging space for time. The primary key of the dim-table is the unique ID to fill all dimensions, and multiple dimension data is stored in redundant storage. Its advantage is that it is convenient to query, unnecessary to associate additional dim-tables, which is way better. The disadvantage is that if there is a change in dimension data, the entire table needs to be refreshed, which is bad for high-frequency Update.
+
+Star Schema:
+
+Dimension data is completely separated from fact data. Dimension data is often stored in a dedicated engine (such as MySQL, Elasticsearch, etc.). When querying, dimension data is associated with the primary key. The advantage is that changes in dimension data do not affect fact data, which can support high-frequency Update operations. The disadvantage is that the query logic is relatively more complex, and multi-table Join may lead to performance loss.
+
+## 2.2 Requirement for an OLAP Engine
+
+In Kwai’s business, the commercial reports engine supports the real-time query of the advertising effect for advertisers. When building the report engine, we expect to meet the following requirements:
+- Immersive data: the original data of a single table increases by ten billion every day
+- High QPS in Query: thousand-level QPS on average
+- High stability requirements: SLA level of 99.9999 %
+
+Most importantly, due to frequent changes in dimension data, dim-tables need to support Update operations up to thousand-level QPS and further support requirements such as fuzzy matching and word segmentation retrieval.
+Based on the above requirements, we chose star schema and built a report engine architecture with Apache Druid and Elasticsearch.
+
+## 2.3 Previous Architecture: Based on Apache Druid
+
+We chose the combination of Elasticsearch and Apache Druid. In data import, we use Flink to pre-aggregate the data at minute-evel, and use Kafka to pre-aggregate the data at hour-level. In data query, the application initiates a query request through RE Front API, and Re Query initiates queries to the dim-table engine (Elasticsearch and MySQL) and the extension engine respectively.
+
+Druid is a timing-based query engine that supports real-time data ingestion and is used to store and query large amounts of fact data. We adopt Elasticseach based on those concerns:
+- High update frequency, QPS is around 1000
+- Support word segmentation and fuzzy search, which is suitable for Kwai
+- Supports high-level dim-table data, which can be directly qualified without adopting sub-database and sub-table just like MySQL database
+- Supports data synchronization monitoring, and has check and recovery services as well
+
+## 2.4 Engine of the Reports
+
+The report engine can be divided into two layers: REFront and REQuery. REMeta is an independent metadata management module. The report engine implements MEMJoin inside REQuery. It supports associative query between fact data in Druid and dimension data in Elasticsearch. And it also provides virtual cube query for upper-layer business, avoiding the exposion of complex cross-engine management and query logic.
+
+
+
+# 3 New Architecture Based on Apache Doris
+
+## 3.1 Problems Remained
+First, we came across a problem when we build the report engine. Mem Join is single-machine with serial execution. When the amount of data pulled from Elasticsearch exceeds 100,000 at a single time, the response time is close to 10s, and the user experience is poor. Moreover, using a single node to execute large-scale data Join will consume a lot of memory, causing Full GC.
+
+Second, Druid's Lookup Join function is not so perfect, which is a big problem, and it cannot fully meet our business needs.
+
+## 3.2 Database Research
+
+So we conducted a survey on popular OLAP databases in the industry, the most representative of which are Apache Doris and Clickhouse. We found out that Apache Doris is more capable of Join between large and wide tables. ClickHouse can support Broadcast memory-based Join, but the performance is not good for the Join between large and wide tables with a large data volume. Both Doris and Clickhouse support detailed data storage, but the capability for concurrency of Clickhouse is low. On t [...]
+
+From this point of view, Doris can better improve the performance of Join and is much better in other aspects such as migration cost, horizontal expansion, and concurrency. However, Elasticsearch has inherent advantages in high-frequency Update.
+
+It would be an ideal solution to deal with high-frequency Upate and Join performance at the same time by building engines through Doris on Elasticsearch.
+
+## 3.3 Good Choice: Doris on Elasticsearch
+
+What is the query performance of Doris on Elasticsearch?
+
+First of all, Apache Doris is a real-time analytical database based on MPP architecture, with strong performance and strong horizontal expansion capability. Doris on Elasticsearch takes advantage on this capability and does a lot of query optimization. Secondly, after integrating Elasticsearch, we have also made a lot of optimizations to the query:
+- Shard-level concurrency
+- Automatic adaptation of row and column scanning, priority to column scanning
+- Sequential read, terminated early
+- Two-phase query becomes one-phase query
+- Broadcast Join is especially friendly for small batch data
+
+
+
+## 3.4 Doris on Elasticsearch
+
+### 3.4.1 Data Link Upgrade
+
+The upgrade of the data link is relatively simple. In the first step, in Doris we build a new Olap table and configure the materialized view. Second, the routine load is initiated based on the Kafka topic of the previous fact data, and then real-time data is ingested. The third step is to ingest offline data from Hive's broker load. The last step is to create an Elasticsearch external table through Doris.
+
+
+
+### 3.4.2 Upgrades of the Report Engine
+
+
+
+Note: The MySQL dim-table associated above is based on future planning. Currently, Elasticsearch is mainly used as the dim-table engine
+
+Report Engine Adaptation
+- Generate virtual cube table based on Doris's star schema
+- Adapt to cube table query analysis, intelligent Push-down
+- Gray Release
+
+# 4 Online Performance
+
+## 4.1 Fact Table Query Performance Comparison
+
+Druid
+
+
+
+Doris
+
+
+
+99th percentile of response time:
+Druid: 270ms, Doris: 150ms and which is reduced by 45%
+
+## 4.2 Comparison of Cube Table Query Performance in Join
+
+Druid
+
+
+
+Doris
+
+
+
+99th percentile of response time:
+Druid: 660ms, Doris: 440ms and which is reduced by 33%
+
+## 4.3 Benefits
+
+- The overall time consumption of 99 percentile is reduced by about 35%
+- Resource saving about 50%
+- Remove the complex logic of MemJoin from the report engine; Realize through DO(in the case of large query: dim-table results exceed 100,000, performance improvement exceeds 10 times, 10s to 1s)
+- Richer query semantics (Mem Join is relatively simple and does not support complex queries)
+
+# 5 Summary and Plans
+
+In Kwai's commercial business, Join queries between dimension data and fact data is very common. After using Doris, query becomes simple. We only need to synchronize the fact table and dim-table on a daily basis and Join while querying. By replacing Druid and Clickhouse with Doris, Doris basically covers all scenarios when we use Druid. In this way, Kwai's commercial report engine greatly improves the aggregation and analysis capabilities of massive data. During the use of Apache Doris, [...]
+
+Although the Doris on Elasticsearch has fully meet our requirement, Elasticsearch external table still requires manual creation. However, Apache Doris recently released the latest version V1.2.0. The new version has added Multi-Catlog, which provides the ability to seamlessly access external table sources such as Hive, Elasticsearch, Hudi, and Iceberg. Users can connect to external tables through the CREATE CATALOG command, and Doris will automatically map the library and table informati [...]
+
+
+# Contact Us
+
+Apache Doris Website：http://doris.apache.org
+
+Github：https://github.com/apache/doris
+
+Dev Email：dev@doris.apache.org
diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/BestPractice_Kwai.md b/i18n/zh-CN/docusaurus-plugin-content-blog/BestPractice_Kwai.md
new file mode 100644
index 00000000000..14eb7a044c4
--- /dev/null
+++ b/i18n/zh-CN/docusaurus-plugin-content-blog/BestPractice_Kwai.md
@@ -0,0 +1,181 @@
+---
+{
+ 'title': 'Doris on Es在快手商业化的最佳实践',
+ 'language": "zh'
+ 'summary': "快手商业化报表引擎为外部广告主提供广告投放效果的实时多维分析报表在线查询服务，以及为内部各商业化系统提供多维分析报表查询服务，致力于解决多维分析报表场景的高性能、高并发、高稳定的查询问题。早期Druid on Es的架构含有诸多弊端，通过调研我们选择了Doris on Es的数仓解决方案。使用Doris 之后，查询变得简单。我们仅需要按天同步事实表和维表，在查询的同时 Join即可。通过Doris替代Druid、Clickhouse的方案，基本覆盖了我们使用Druid 时的所有场景，大大提高了海量数据的聚合分析能力。在Apache Doris的使用过程中，我们还发现了一些意想不到的收益：例如，Routine Load和 Broker Load的导入方式较为简单，提升了查询速度；数据占用空间大幅降低；Doris支持MySQL协议，方便了数据分析师自助取数绘图等。",
+ 'date': '2022-12-14',
+ 'author': '贺祥',
+ 'tags': ['最佳实践'],
+}
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+> 作者：贺祥，数据架构高级工程师，快手商业化团队
+
+
+
+# 1 关于快手
+
+## 1.1 快手
+
+快手（HKG: 1024）是一个短视频和潮流社交网络。发现有趣的短片，通过生活中的录音、视频、玩日常挑战或喜欢最好的动效模版和视频来为虚拟社区做出贡献。用短视频分享生活，并从数十种神奇的效果和滤镜中选择喜欢的方式。
+
+## 1.2 快手商业化报表引擎
+
+快手商业化报表引擎为外部广告主提供广告投放效果的实时多维分析报表在线查询服务，以及为内部各商业化系统提供多维分析报表查询服务，致力于解决多维分析报表场景的高性能、高并发、高稳定的查询问题。
+
+# 2 初期架构
+
+## 2.1 需求背景
+
+传统 OLAP 引擎应对多维分析时更多是以预建模的方式，通过构建数据立方体（Cube）对事实数据进行下钻、上卷、切片、切块等操作。现代 OLAP 分析引入了关系模型的理念，在二维关系表中描绘数据。而在建模过程中，往往有两种建模方式，一是采用宽表模型、将多张表的数据通过 Join 写入进一张宽表中，另一种方式是采用星型模型、将数据表区分为事实表和维度表、查询时对事实表与维度表进行 Join 。
+以上两种方案各有部分优缺点：
+
+宽表模型：
+
+采取空间换时间的思路，理论上都是维表主键为唯一 ID 来填充所有维度，冗余存储了多条维度数据。其优势在于查询时非常方便，无需关联额外维表，性能表现更佳。其弊端在于如果有维度数据变化，需要对全表数据进行重刷，无法支撑高频的 Update。
+
+星型模型：
+
+维度数据与事实数据完全分离，维度数据往往用专门的引擎存储 (如 MySQL、Elasticsearch 等)，查询时通过主键关联查询维度数据，其优势在于维度数据变化不影响事实数据、可支持高频 Update 操作。其弊端在于查询逻辑相对更复杂，且多表 Join 可能导致性能受损。
+
+## 2.2 业务需求
+
+在快手的业务场景中，商业化报表引擎承载了外部广告主实时查询广告投放效果的需求，在构建报表引擎时，我们期望可以满足如下要求：
+- 超大数据量：单表原始数据每天增量百亿
+- 查询高 QPS：平均 QPS千级别
+- 高稳定性要求：在线服务要求稳定性4个9
+最为重要的是，由于维度数据经常发生变更，维度表需要支持高达上千 QPS 的 Update 操作，同时还要进一步支持模糊匹配、分词检索等需求。
+基于以上需求，我们选择了星型模型来建模，并以 Apache Druid 和 Elasticsearch 为核心构建了早期的报表引擎架构。
+
+## 2.3 初期架构：基于Apache Druid的架构
+
+我们选择了引擎结合的方式，用Elasticsearch适配Druid引擎来实现。在数据写入阶段，我们通过Flink对数据进行分钟级预聚合，利用Kafka对数据进行小时级别的数据预聚合。在数据查询中，App端发起查询需求，对RE Front统一接口进行查询，Re Query根据引擎适配，向维表引擎（Elasticsearch和MySQL）及扩展引擎分别发起查询。
+
+Druid则是一款基于时序的查询引擎，支持数据实时摄入，用来存储和查询大量的事实数据。而选用Elasticsearch作为维度数据存储引擎，主要是因为如下原因：
+- 支持高频实时更新，可以支撑上千 QPS的 Update操作
+- 支持分词模糊检索，适用于快手的业务
+- 支持量级较高的维表数据，不用像MySQL数据库一样做分库分表才能满足
+- 支持数据同步监控，同时拥有检查和恢复的服务
+
+## 2.4 报表引擎
+
+报表引擎架构整体分为REFront 和 REQuery两层，REMeta为独立的元数据管理模块。报表引擎在REQuery内部实现MEM Join。支持Druid引擎中的事实数据与ES引擎中的维度数据做关联查询。为上层业务提供虚拟的cube表查询。屏蔽复杂的跨引擎管理查询逻辑。
+
+
+
+## 3 基于Apache Doris的架构
+
+## 3.1 架构遗留的问题
+
+首先，我们在使用报表引擎时，发现了这样的一个问题。Mem Join是单机实现与串行执行，到单次从ES中拉取的数据量超过10W时，响应时间已经接近10s，用户体验差。而且单节点实现大规模数据Join处理，内存消耗大，有Full GC风险。
+
+其次，Druid的Lookup Join了功能不够完善是一个较大的问题，不能完全满足真实业务需求。
+
+## 3.2 选型调研
+
+于是我们对业界常见的 OLAP 数据库进行了调研，其中最具代表性的为 Apache Doris和 Clickhouse。在进一步的调研中我们发现，Apache Doris在大宽表Join的能力更强。ClickHouse能够支持 Broadcast 基于内存的Join，但是对于大数据量千万级以上大宽表的Join，ClickHouse 的性能表现不好。Doris 和 Clickhouse 都支持明细数据存储，但Clickhouse支持的并发度较低，相反Doris支持高并发低延时的查询服务，单机最高支持上千QPS。在并发增加时，线性扩充FE和BE即可支持。而Clickhouse的数据导入没有事务支持功能，无法实现exactly once语义，对标准sql的支持也是有限的。相比之下，Doris提供了数据导入的事务支持和原子性，Doris 自身能够保证不丢不重的订阅 Kafka 中的消息，即 Exactly-Once 消费语义。ClickHouse使用门槛高、运维成本高和分布式能力弱，需要较多的定制化和较深的技术实力也
是另一个难题，Doris则不同，只有FE、BE两个核心组件，外 [...]
+
+由此看来Doris可以比较好的提升Join的性能，在迁移成本、横向扩容、并发程度等其他方面也比较优秀。不过在高频Update上，Elasticsearch具有先天的优势。
+
+通过 Doris 创建 ES 外表的方式来同时应对高频Upate和Join性能问题，会是比较理想的解决方案。
+
+## 3.3 Doris+Doris on ES完美配合
+
+Doris on ES 的查询性能究竟如何呢？
+
+首先，Apache Doris 是一个基于MPP 架构的实时分析型数据库，性能强劲、横向扩展能力能力强。Doris on ES构建在这个能力之上，并且对查询做了大量的优化。其次，在这些之上，融合Elasticsearch的能力之后，我们还对查询功能做出了大量的优化：
+- Shard级别并发
+- 行列扫描自动适配，优先列式扫描
+- 顺序读取，提前终止
+- 两阶段查询变为一阶段查询
+- Join场景使用Broadcast Join，对于小批量数据Join特别友好
+
+
+
+## 3.4 基于Doris on Elasticsearch的架构实现
+
+### 3.4.1 数据链路升级
+
+数据链路的升级适配比较简单。第一步，由Doris构建新的Olap表，配置好物化视图。第二步，基于之前事实数据的kafka topic启动routine load，导入实时数据。第三步，从Hive中通broker load导入离线数据。最后一步，通过Doris创建Es外表。
+
+
+
+### 3.4.2 报表引擎适配升级
+
+
+
+注：上图关联的mysql维表是基于未来规划，目前主要是ES做维表引擎
+
+报表引擎适配
+- 抽象基于Doris的星型模型虚拟cube表
+- 适配cube表查询解析，智能下推
+- 支持灰度上线
+
+# 4 线上表现
+
+## 4.1 查询响应时间
+
+### 4.1.1 事实表查询表现对比
+
+Druid
+
+
+
+Doris
+
+
+
+99分位耗时Druid大概为270ms，Doris为150ms，延时下降45%
+
+### 4.1.2 Join场景下cube表查询表现对比
+
+Druid
+
+
+
+Doris
+
+
+
+99分位耗时Druid大概为660ms，Doris为440ms，延时下降33%
+
+### 4.1.3 收益总结
+
+- P99整体耗时下降35%左右
+- 资源节省50%左右
+- 去除报表引擎内部Mem Join的复杂逻辑，下沉至Doris通过DOE实现，在大查询场景下(维表结果超过10W，性能提升超过10倍，10s->1s)
+- 更丰富的查询语义(原本Mem Join实现比较简单，不支持复杂的查询)
+
+# 5 总结与未来规划
+
+在快手商业化业务里面，维度数据与事实数据Join查询是非常普遍的。使用Doris 之后，查询变得简单。我们仅需要按天同步事实表和维表，在查询的同时 Join即可。通过Doris替代Druid、Clickhouse的方案，基本覆盖了我们使用Druid 时的所有场景，大大提高了海量数据的聚合分析能力。在Apache Doris的使用过程中，我们还发现了一些意想不到的收益：例如，Routine Load和 Broker Load的导入方式较为简单，提升了查询速度；数据占用空间大幅降低；Doris支持MySQL协议，方便了数据分析师自助取数绘图等。
+
+尽管Doris on ES的解决方案比较成功的满足了我们的报表业务，ES外表映射仍然需要手工建表。但Apache Doris于近日完成了最新版本V1.2.0的发布，新版本功能新增了Multi-Catlog，提供了无缝接入Hive、ES、Hudi、Iceberg 等外部数据源的能力。用户可以通过 CREATE CATALOG 命令连接到外部数据源，Doris 会自动映射外部数据源的库、表信息。如此一来，以后我们就不需要再手动创建Es外表完成映射，大大节省了开发的时间成本，提升了研发效率。而全面向量化、Ligt Schema Change、Merge-on-Write、Java UDF等其他新功能的实现，也让我们对Apache Doris有了全新的期待。祝福Apache Doris！
+
+
+# 联系我们
+
+官网：http://doris.apache.org
+
+Github：https://github.com/apache/doris
+
+dev邮件组：dev@doris.apache.org
diff --git a/static/images/Kwai/en/kv.png b/static/images/Kwai/en/kv.png
new file mode 100644
index 00000000000..6299a05bb36
Binary files /dev/null and b/static/images/Kwai/en/kv.png differ
diff --git a/static/images/Kwai/en/page_1.png b/static/images/Kwai/en/page_1.png
new file mode 100644
index 00000000000..4560c1702ac
Binary files /dev/null and b/static/images/Kwai/en/page_1.png differ
diff --git a/static/images/Kwai/en/page_2.png b/static/images/Kwai/en/page_2.png
new file mode 100644
index 00000000000..cb6bf49658a
Binary files /dev/null and b/static/images/Kwai/en/page_2.png differ
diff --git a/static/images/Kwai/en/page_3.png b/static/images/Kwai/en/page_3.png
new file mode 100644
index 00000000000..af853d729aa
Binary files /dev/null and b/static/images/Kwai/en/page_3.png differ
diff --git a/static/images/Kwai/en/page_4.png b/static/images/Kwai/en/page_4.png
new file mode 100644
index 00000000000..15914ca460a
Binary files /dev/null and b/static/images/Kwai/en/page_4.png differ
diff --git a/static/images/Kwai/en/page_5.png b/static/images/Kwai/en/page_5.png
new file mode 100644
index 00000000000..700eefb5c5a
Binary files /dev/null and b/static/images/Kwai/en/page_5.png differ
diff --git a/static/images/Kwai/en/page_6.png b/static/images/Kwai/en/page_6.png
new file mode 100644
index 00000000000..03918b1f1b3
Binary files /dev/null and b/static/images/Kwai/en/page_6.png differ
diff --git a/static/images/Kwai/en/page_7.png b/static/images/Kwai/en/page_7.png
new file mode 100644
index 00000000000..0cb21358a83
Binary files /dev/null and b/static/images/Kwai/en/page_7.png differ
diff --git a/static/images/Kwai/en/page_8.png b/static/images/Kwai/en/page_8.png
new file mode 100644
index 00000000000..b45e90ad5a2
Binary files /dev/null and b/static/images/Kwai/en/page_8.png differ
diff --git a/static/images/Kwai/zh/1.png b/static/images/Kwai/zh/1.png
new file mode 100644
index 00000000000..eded7d32b2f
Binary files /dev/null and b/static/images/Kwai/zh/1.png differ
diff --git a/static/images/Kwai/zh/2.png b/static/images/Kwai/zh/2.png
new file mode 100644
index 00000000000..1636261ba93
Binary files /dev/null and b/static/images/Kwai/zh/2.png differ
diff --git a/static/images/Kwai/zh/3.png b/static/images/Kwai/zh/3.png
new file mode 100644
index 00000000000..f3c561cca42
Binary files /dev/null and b/static/images/Kwai/zh/3.png differ
diff --git a/static/images/Kwai/zh/4.png b/static/images/Kwai/zh/4.png
new file mode 100644
index 00000000000..8e63610d20c
Binary files /dev/null and b/static/images/Kwai/zh/4.png differ
diff --git a/static/images/Kwai/zh/5.png b/static/images/Kwai/zh/5.png
new file mode 100644
index 00000000000..8c821ec6706
Binary files /dev/null and b/static/images/Kwai/zh/5.png differ
diff --git a/static/images/Kwai/zh/6.png b/static/images/Kwai/zh/6.png
new file mode 100644
index 00000000000..51d7d02b6d6
Binary files /dev/null and b/static/images/Kwai/zh/6.png differ
diff --git a/static/images/Kwai/zh/7.png b/static/images/Kwai/zh/7.png
new file mode 100644
index 00000000000..e2a0527113b
Binary files /dev/null and b/static/images/Kwai/zh/7.png differ
diff --git a/static/images/Kwai/zh/8.png b/static/images/Kwai/zh/8.png
new file mode 100644
index 00000000000..efe2bf5c6d7
Binary files /dev/null and b/static/images/Kwai/zh/8.png differ
diff --git a/static/images/Kwai/zh/kv.png b/static/images/Kwai/zh/kv.png
new file mode 100644
index 00000000000..6299a05bb36
Binary files /dev/null and b/static/images/Kwai/zh/kv.png differ
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@doris.apache.org
For additional commands, e-mail: commits-help@doris.apache.org