用 Doris 驾驭大数据的无限可能

关键词：Doris、OLAP引擎、MPP架构、实时数仓、列存储、大数据分析、查询优化
摘要：在奶茶店老板发愁“怎么快速算清本周销量”、电商运营急着“实时看GMV变化”、游戏分析师想“弄明白用户为啥流失”的大数据时代，传统数据库要么查得慢，要么扛不住海量数据。Apache Doris（incubating）作为一款“为分析而生”的开源OLAP引擎，就像一把“大数据瑞士军刀”——既能装下TB级数据，又能在毫秒级给出答案，还支持实时更新。本文从奶茶店的真实痛点切入，用“拼乐高”“记账本”这样的生活比喻拆解Doris的核心概念（MPP、列存、实时性），用流程图讲清它的架构，再通过“奶茶店销售分析系统”的实战案例，手把手教你用Doris解决真实问题。读完这篇，你会明白：原来驾驭大数据，其实可以这么简单！

背景介绍

目的和范围

你有没有过这样的经历？打开Excel想算个月度销量，结果数据太多直接卡死；用MySQL查一张10亿行的表，等了10分钟还没结果；想实时看今天的GMV，却要等ETL任务跑2小时。这些都是大数据时代的“痛”——数据量越来越大，分析需求越来越急，但传统工具跟不上了。

本文的目的，就是帮你“治愈”这些痛：我们会用最接地气的例子讲清楚Doris是什么、为什么能解决这些问题；用一步一步的实战教你怎么用Doris搭建分析系统；最后告诉你它能解决哪些真实场景的问题。范围覆盖Doris的核心概念、架构原理、实战操作，以及常见应用场景，适合想入门大数据分析的新手，也适合想换工具的老司机。

预期读者

• 数据分析师：想快速从海量数据中挖 insights，不想等半天；
• 大数据工程师：想搭建实时数仓，替代慢得要死的Hive；
• 业务运营：想自己查数据，不用麻烦技术同学；
• 编程新手：想入门大数据，找一个“容易上手又强大”的工具。

文档结构概述

本文就像“做奶茶”的流程：

1. 备原料（背景介绍）：先讲清楚大数据分析的痛点，为什么需要Doris；
2. 认工具（核心概念）：用生活比喻拆解Doris的“秘诀”——MPP、列存、实时性；
3. 搭机器（架构原理）：看Doris的“内部构造”，知道它怎么工作；
4. 做奶茶（实战案例）：手把手教你用Doris搭建奶茶店销售分析系统；
5. 卖奶茶（应用场景）：看Doris在电商、物流、游戏里的真实用法；
6. 清台面（总结思考）：回顾重点，留下问题让你接着想。

术语表

在开始之前，先把“黑话”变成“人话”，避免后面听不懂：

核心术语定义

• OLAP：联机分析处理，就是“快速回答复杂问题”的技术，比如“这个月哪个奶茶卖得最好？”“不同时段的销量变化？”（类比：超市的盘点系统，快速算清库存和销量）；
• MPP：大规模并行处理，就是“很多电脑一起算”，比如10台电脑一起查数据，比1台快10倍（类比：拼乐高时，你和朋友分工，每人拼一部分）；
• 列存储：把数据按“列”存，而不是按“行”存，比如“日期列”“产品名列”“销量列”分开存（类比：记账本里，把所有日期写在一页，所有产品写在另一页，查销量直接翻销量页）；
• 实时数仓：能实时接收数据、实时分析的仓库，比如奶茶卖一杯就立刻更新数据，马上能查到当前销量（类比：奶茶店的电子点单系统，点一杯更一杯）。

相关概念解释

• ETL：Extract-Transform-Load，就是“把数据从各个地方取出来、处理一下、存到仓库里”的过程，传统ETL很慢，比如要等一天才能看到昨天的数据；
• Predicate Pushdown：谓词下推，就是“在存储层先过滤数据”，比如查“2023-10-01的销量”，先把不是这天的数据过滤掉，再传给上层计算（类比：找奶茶时，先排除卖完的，不用全部看）；
• 哈希聚合：把相同key的数据放到一起计算，比如“所有珍珠奶茶的销量加起来”，用哈希值把珍珠奶茶的记录分到同一个“篮子”里，直接加（类比：整理玩具时，把所有乐高积木放一个箱子，所有拼图放另一个，统计数量更快）。

缩略词列表

• Doris：Apache Doris（incubating），本文的主角；
• OLAP：联机分析处理（Online Analytical Processing）；
• MPP：大规模并行处理（Massively Parallel Processing）；
• SQL：结构化查询语言（Structured Query Language），查数据的“普通话”。

核心概念与联系

故事引入：奶茶店老板的烦恼

我朋友小A开了家奶茶店，叫“茶里茶气”。最近他愁得睡不着觉——生意越来越好，数据越来越多，但想算点东西比登天还难：

• 想查“本周销量Top5的奶茶”，用Excel打开10万行的销售表，直接卡死；
• 想查“下午3-5点的销量变化”，用MySQL查，等了5分钟还没结果；
• 想实时看“今天卖了多少杯”，得等晚上关门后，把POS机的数据导到Excel里算，根本没法实时调整备货。

直到他遇到了Doris，这些问题全解决了：现在查Top5只要0.5秒，实时销量每秒更新，甚至能查“上周六雨天的珍珠奶茶销量”这样的复杂问题。

为什么Doris这么厉害？因为它抓住了大数据分析的三个“命门”：能装大量数据（像仓库）、算得快（像超级计算器）、能实时更（像直播）。接下来我们逐一拆解这些“命门”。

核心概念解释：Doris的三个“魔法”

核心概念一：Doris是什么？——“为分析而生的超级仓库”

如果把数据比作“奶茶原料”，那么Doris就是“奶茶店的中央厨房”：

• 它能存很多原料（TB级甚至PB级数据）；
• 它能快速加工原料（比如把“销量数据”变成“Top5奶茶”）；
• 它能实时更新原料（比如卖一杯奶茶，立刻把销量加1）。

简单来说，Doris是一款开源的MPP架构OLAP引擎，专门用来解决“海量数据快速分析”的问题。它的口号是“Let data speak faster”——让数据更快说话。

核心概念二：MPP架构——“很多小计算器一起算”

你有没有试过用一个计算器算1000道加法题？肯定很慢。但如果有10个计算器，每个算100道，是不是快多了？这就是MPP架构的原理。

Doris的MPP架构由三部分组成：

• Frontend（FE）：“接待员”，负责接收你的查询请求（比如“查本周Top5奶茶”），然后把请求分成很多小任务，分给后面的“计算员”；
• Backend（BE）：“计算员”，每个BE都是一台独立的电脑，负责存一部分数据，处理FE分给它的小任务，最后把结果汇总给FE；
• Metadata Service（元数据服务）：“管理员”，负责记录数据存在哪里、表的结构是什么，就像奶茶店的“库存台账”。

比如小A查“本周Top5奶茶”，FE会把“本周”这个条件拆成7天，每个BE处理1天的数据，算出当天的Top5，然后FE把所有BE的结果汇总，再算出整个星期的Top5。这样比一个BE处理所有数据快多了！

核心概念三：列存储——“记账本的聪明写法”

传统数据库（比如MySQL）是行存储，就是把每一行数据存在一起，比如“2023-10-01 珍珠奶茶 5杯 15元”这一行，所有数据都存在一个地方。而Doris是列存储，把每一列的数据存在一起，比如“日期列”存所有的2023-10-01、2023-10-02…，“产品列”存所有的珍珠奶茶、芋圆奶茶…，“销量列”存所有的5、3、8…。

为什么列存储更快？举个例子：小A想查“2023-10-01的总销量”，行存储需要把每一行都打开，看日期是不是2023-10-01，然后把销量加起来；而列存储直接打开“日期列”，找到所有2023-10-01的位置，再打开“销量列”，把对应的销量加起来——不用看其他列的数据，是不是快多了？

还有，列存储的压缩率更高。因为同一列的数据很像，比如“日期列”都是“2023-10-xx”，“产品列”都是“xx奶茶”，压缩软件（比如Snappy）能把它们压得很小，节省存储空间，也能让读取更快。

核心概念四：实时更新——“卖一杯记一杯”

传统数据仓库（比如Hive）是“批量更新”，比如每天晚上把当天的数据导进去，所以你只能看到昨天的结果。而Doris支持实时更新，比如奶茶店的POS机每卖一杯，就把数据传到Doris里，Doris立刻更新，你马上就能查到当前的销量。

Doris的实时更新靠主键模型实现：每个表有一个主键（比如“订单ID”），当新数据进来时，如果主键不存在，就插入；如果存在，就更新。比如订单ID是1001的奶茶卖了2杯，后来又加了1杯，Doris会把订单ID=1001的销量从2改成3，不用等批量处理。

核心概念之间的关系：像“奶茶店的团队”

Doris的四个核心概念（MPP、列存、实时更新、OLAP）就像奶茶店的团队：

• OLAP是“店长”，负责确定“要做什么分析”（比如查Top5奶茶）；
• MPP是“店员团队”，分工合作处理任务（每个店员处理一部分数据）；
• 列存是“工具”，比如勺子、杯子，让店员做事更快；
• 实时更新是“效率buff”，让店员不用等下班再干活，立刻处理新订单。

举个具体的例子：小A查“今天14:00-15:00的珍珠奶茶销量”：

1. OLAP确定要解决的问题：“今天下午2-3点的珍珠奶茶销量”；
2. MPP的FE把请求拆成“查14:00-14:30”和“查14:30-15:00”两个任务，分给两个BE；
3. 列存让每个BE直接打开“日期列”“时间列”“产品列”“销量列”，过滤出符合条件的记录；
4. 实时更新确保BE里的数据是最新的，比如14:59卖的奶茶已经存进去了；
5. 最后FE把两个BE的结果汇总，得出总销量，返回给小A。

核心概念原理和架构的文本示意图

Doris的架构就像“奶茶店的工作流程”：

1. 用户（小A）向FE（接待员）提出请求：“查今天14:00-15:00的珍珠奶茶销量”；
2. FE（接待员）看一下元数据服务（库存台账），知道“销售数据存在BE1和BE2里”；
3. FE把请求拆成两个小任务：“BE1查14:00-14:30的珍珠奶茶销量”“BE2查14:30-15:00的珍珠奶茶销量”；
4. BE1和BE2（计算员）用列存快速找到对应的销量数据，算出来；
5. BE1和BE2把结果返回给FE；
6. FE把结果汇总，返回给用户（小A）。

Mermaid 流程图：Doris的工作流程

核心算法原理 & 具体操作步骤

Doris之所以快，除了MPP和列存，还有很多“聪明的算法”。我们挑两个最核心的讲：谓词下推（Predicate Pushdown）和哈希聚合（Hash Aggregation）。

算法一：谓词下推——“先过滤再计算”

原理：把过滤条件“推”到存储层

比如小A想查“2023-10-01的总销量”，SQL语句是：

SELECT SUM(quantity) FROM sales WHERE date = '2023-10-01';

如果没有谓词下推，流程是：

1. BE把所有sales表的数据读出来（不管日期是什么）；
2. 把数据传给FE；
3. FE过滤出date='2023-10-01’的记录；
4. FE计算SUM(quantity)。

这样很慢，因为要读所有数据。而谓词下推的流程是：

1. FE把“date=‘2023-10-01’”这个条件传给BE；
2. BE在存储层直接过滤出date='2023-10-01’的记录；
3. BE计算SUM(quantity)；
4. BE把结果返回给FE。

这样快很多，因为BE只需要读符合条件的数据，不用读所有。

操作步骤：Doris如何实现谓词下推？

1. FE解析SQL：FE把SQL拆成“过滤条件”（WHERE date=‘2023-10-01’）和“聚合操作”（SUM(quantity)）；
2. FE生成执行计划：FE决定把过滤条件“推”给BE；
3. BE执行过滤：BE用列存储的优势，快速找到date列中等于’2023-10-01’的记录；
4. BE执行聚合：BE把过滤后的quantity列加起来；
5. FE汇总结果：如果有多个BE，FE把所有BE的结果加起来，返回给用户。

算法二：哈希聚合——“把相同的东西放一起算”

原理：用哈希值分组

比如小A想查“每个奶茶的总销量”，SQL语句是：

SELECT product_name, SUM(quantity) FROM sales GROUP BY product_name;

哈希聚合的流程是：

1. BE读取数据：BE读取sales表的product_name和quantity列；
2. 计算哈希值：对每个product_name计算哈希值（比如“珍珠奶茶”的哈希值是123，“芋圆奶茶”是456）；
3. 分组：把哈希值相同的记录放到同一个“桶”里（比如所有哈希值123的记录放桶1，456放桶2）；
4. 聚合：对每个桶里的quantity列求和（桶1的总和是珍珠奶茶的总销量，桶2是芋圆奶茶的）；
5. 返回结果：BE把每个桶的结果返回给FE。

这样比“先排序再分组”快很多，因为哈希计算很快，分组不用排序。

操作步骤：Doris如何实现哈希聚合？

1. FE解析SQL：FE识别出“GROUP BY product_name”和“SUM(quantity)”；
2. FE生成执行计划：FE决定用哈希聚合，把任务分给BE；
3. BE计算哈希值：BE对每个product_name计算哈希值；
4. BE分组聚合：BE把相同哈希值的记录分组，求和；
5. FE汇总结果：如果有多个BE，FE把每个BE的结果合并（比如BE1有珍珠奶茶的销量100，BE2有200，总销量是300）；
6. 返回结果：FE把最终结果返回给用户。

代码示例：用SQL验证算法效果

我们用Doris的SQL来验证这两个算法的效果。假设sales表有1亿行数据，date列有2023-10-01到2023-10-31的日期，product_name有10种奶茶。

验证谓词下推

先查没有过滤条件的总销量：

SELECT SUM(quantity) FROM sales;
-- 结果：100000000，耗时：5秒

再查有过滤条件的总销量：

SELECT SUM(quantity) FROM sales WHERE date = '2023-10-01';
-- 结果：3225806，耗时：0.1秒

明显快了很多，因为谓词下推过滤了大部分数据。

验证哈希聚合

查每个奶茶的总销量：

SELECT product_name, SUM(quantity) FROM sales GROUP BY product_name;
-- 结果：10行，耗时：0.5秒

如果用排序聚合（比如MySQL的GROUP BY），可能需要10秒以上，而Doris用哈希聚合只需要0.5秒。

数学模型和公式 & 详细讲解 & 举例说明

Doris的性能优势可以用数学公式量化，我们讲两个最关键的：列存压缩率和MPP并行加速比。

公式一：列存压缩率——让数据“变小”

列存的压缩率是指原始数据大小与压缩后数据大小的比值，公式是：
$$压缩率=\frac{原始数据大小}{压缩后数据大小}$$

比如原始数据大小是1TB（1024GB），压缩后是200GB，那么压缩率是：
$$压缩率=\frac{1024}{200}\approx 5.12$$

也就是说，压缩后的数据只有原来的1/5，读取速度自然快5倍。

为什么列存压缩率高？

因为同一列的数据相关性高（比如日期列都是“2023-10-xx”，产品列都是“xx奶茶”），而压缩算法（比如Snappy、LZ4）对相关性高的数据效果更好。相比之下，行存的数据相关性低（每一行有日期、产品、销量、价格，各不相同），压缩率只有2-3倍。

举例说明：

假设sales表的一行数据是：

• date: 2023-10-01（10字节）
• product_name: 珍珠奶茶（8字节）
• quantity: 5（4字节）
• price: 15（4字节）
• 行存总大小：10+8+4+4=26字节/行

如果有1亿行，行存总大小是：1亿 × 26字节 = 2.6GB。

列存的情况：

• date列：1亿个“2023-10-xx”，每个日期用Snappy压缩后平均1字节，总大小1亿×1=100MB；
• product_name列：10种奶茶，每个名字压缩后平均2字节，总大小1亿×2=200MB；
• quantity列：1-100的整数，压缩后平均1字节，总大小100MB；
• price列：10-30的整数，压缩后平均1字节，总大小100MB；
• 列存总大小：100+200+100+100=500MB。

压缩率是：2.6GB / 0.5GB = 5.2，和之前的公式计算一致。

公式二：MPP并行加速比——让计算“变快”

MPP的并行加速比是指单节点计算时间与多节点计算时间的比值，公式是：
$$加速比=\frac{单节点时间}{多节点时间}$$

假设单节点计算时间是T，用N个节点，每个节点处理1/N的数据，那么多节点时间是T/N，加速比是：
$$加速比=\frac{T}{T/N}=N$$

比如单节点查1亿行数据需要10秒，用10个节点，每个节点查1000万行，时间是1秒，加速比是10。

为什么加速比接近N？

因为MPP是无共享架构（Shared-Nothing），每个节点有自己的CPU、内存、存储，不用和其他节点抢资源。比如10个节点一起查数据，每个节点只处理自己的数据，没有竞争，所以时间几乎是单节点的1/10。

举例说明：

假设sales表有1亿行，单节点查“本周Top5奶茶”需要10秒。用10个节点，每个节点处理1000万行，时间是1秒，加速比是10。如果用20个节点，时间是0.5秒，加速比是20。

当然，实际情况中加速比会略低于N，因为FE要协调节点，节点之间要传输数据，但总体来说，MPP的加速比非常接近节点数。

公式三：实时更新延迟——让数据“变新”

实时更新的延迟是指数据从产生到可以查询的时间，公式是：
$$延迟=数据传输时间+数据处理时间+数据存储时间$$

Doris的实时更新延迟通常在毫秒级，比如POS机产生数据后，传输到Doris需要10ms，Doris处理需要5ms，存储需要5ms，总延迟是20ms。也就是说，你在POS机点一杯奶茶，20ms后就能在Doris里查到这个订单。

为什么延迟这么低？

因为Doris用主键模型和内存合并：

• 主键模型：每个新数据进来，直接插入或更新，不用等批量处理；
• 内存合并：新数据先存在内存里，定期合并到磁盘，这样查询时不用等磁盘IO。

举例说明：
小A的奶茶店用POS机点单，每点一杯，POS机就把数据通过HTTP传给Doris。Doris收到数据后，先在内存里更新主键对应的记录，然后异步写入磁盘。用户查询时，Doris同时读取内存和磁盘的数据，合并后返回结果。这样延迟非常低，几乎实时。

项目实战：用Doris搭建奶茶店销售分析系统

现在我们手把手教你用Doris搭建小A的奶茶店销售分析系统。目标是：

1. 存储奶茶店的销售数据（日期、产品、销量、价格）；
2. 快速查询“本周Top5奶茶”“今日实时销量”“不同时段销量趋势”；
3. 用Python可视化分析结果。

开发环境搭建

步骤1：安装Doris（用Docker简化）

Doris的安装有点复杂，我们用Docker Compose来快速搭建。首先下载Docker Compose文件：

# docker-compose.yml
version: '3'
services:
  doris-fe:
    image: apache/doris:1.2.3-fe-nightly
    ports:
      - "8030:8030"
      - "9030:9030"
    volumes:
      - ./doris-fe:/opt/apache-doris/fe/doris-meta
    environment:
      - FE_SERVERS=fe1:172.20.0.2:9010
      - FE_ID=1
  doris-be:
    image: apache/doris:1.2.3-be-nightly
    ports:
      - "8040:8040"
    depends_on:
      - doris-fe
    volumes:
      - ./doris-be:/opt/apache-doris/be/storage
    environment:
      - BE_ADDR=172.20.0.3:9050
      - FE_SERVERS=fe1:172.20.0.2:9030

然后运行：

docker-compose up -d

这样就启动了一个FE（端口9030）和一个BE。

步骤2：连接Doris

用MySQL客户端连接Doris（因为Doris兼容MySQL协议）：

mysql -h 127.0.0.1 -P 9030 -u root -p
# 密码是空，直接回车

连接成功后，会看到Doris的欢迎信息：

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.1.0 Doris version 1.2.3

Copyright (c) 2000, 2023, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

步骤3：创建数据库和表

首先创建数据库：

CREATE DATABASE IF NOT EXISTS奶茶店;
USE奶茶店;

然后创建销售表（sales），用主键模型（支持实时更新）：

CREATE TABLE IF NOT EXISTS sales (
    order_id INT NOT NULL COMMENT '订单ID',
    date DATE NOT NULL COMMENT '日期',
    time TIME NOT NULL COMMENT '时间',
    product_name VARCHAR(50) NOT NULL COMMENT '产品名称',
    quantity INT NOT NULL COMMENT '销量',
    price DECIMAL(5,2) NOT NULL COMMENT '单价',
    PRIMARY KEY (order_id) -- 主键，用于实时更新
)
DUPLICATE KEY (date, product_name) -- 聚合的键
DISTRIBUTED BY HASH(order_id) BUCKETS 10 -- 用order_id哈希分桶，分成10个桶
PROPERTIES (
    "replication_num" = "1", -- 副本数，测试用1，生产用3
    "storage_format" = "COLUMN" -- 列存储
);

解释一下表的参数：

• PRIMARY KEY (order_id)：主键，确保每个订单唯一，支持实时更新；
• DUPLICATE KEY (date, product_name)：重复键，用于聚合查询，比如按日期和产品分组；
• DISTRIBUTED BY HASH(order_id) BUCKETS 10：用order_id哈希分桶，分成10个桶，每个BE处理一部分桶；
• storage_format = “COLUMN”：列存储，提高查询速度。

步骤4：导入测试数据

我们用CSV文件导入测试数据。首先创建CSV文件（sales.csv）：

order_id,date,time,product_name,quantity,price
1,2023-10-01,09:00:00,珍珠奶茶,2,15.00
2,2023-10-01,09:30:00,芋圆奶茶,3,16.00
3,2023-10-01,10:00:00,多肉葡萄,1,18.00
4,2023-10-01,10:30:00,珍珠奶茶,1,15.00
5,2023-10-01,11:00:00,杨枝甘露,2,17.00
...（可以加更多数据，比如10万行）

然后用Doris的Stream Load工具导入：

curl --location-trusted -u root: -T sales.csv -H "label: sales_load_20231001" -H "column_separator: ," http://127.0.0.1:8030/api/奶茶店/sales/_stream_load

解释一下参数：

• -u root:：用户名是root，密码是空；
• -T sales.csv：要导入的CSV文件；
• label: sales_load_20231001：导入任务的标签，用于重试；
• column_separator: ,：CSV的分隔符是逗号；
• http://127.0.0.1:8030/api/奶茶店/sales/_stream_load：导入的URL，格式是“FE地址/api/数据库/表/_stream_load”。

导入成功后，会返回JSON结果：

{
    "TxnId": 1001,
    "Label": "sales_load_20231001",
    "Status": "Success",
    "Message": "OK",
    "NumberTotalRows": 100000,
    "NumberLoadedRows": 100000,
    "NumberFilteredRows": 0,
    "NumberUnselectedRows": 0,
    "LoadBytes": 5242880,
    "LoadTimeMs": 1234
}

步骤5：查询测试数据

现在可以用SQL查询数据了：

1. 查“2023-10-01的总销量”：

SELECT SUM(quantity) FROM sales WHERE date = '2023-10-01';
-- 结果：比如1000

2. 查“2023-10-01的Top5奶茶”：

SELECT product_name, SUM(quantity) AS total_quantity
FROM sales
WHERE date = '2023-10-01'
GROUP BY product_name
ORDER BY total_quantity DESC
LIMIT 5;
-- 结果：珍珠奶茶（200）、芋圆奶茶（180）、多肉葡萄（150）、杨枝甘露（120）、椰果奶茶（100）

3. 查“2023-10-01 14:00-15:00的销量趋势”：

SELECT DATE_FORMAT(time, '%H:%i') AS minute, SUM(quantity) AS total_quantity
FROM sales
WHERE date = '2023-10-01' AND time BETWEEN '14:00:00' AND '15:00:00'
GROUP BY minute
ORDER BY minute;
-- 结果：14:00（10）、14:01（8）、...、14:59（12）

步骤6：用Python可视化分析

我们用Python连接Doris，查询数据，然后用matplotlib画图。

安装依赖库

pip install pymysql matplotlib

Python代码实现

import pymysql
import matplotlib.pyplot as plt

# 连接Doris
conn = pymysql.connect(
    host='127.0.0.1',
    port=9030,
    user='root',
    password='',
    db='奶茶店',
    charset='utf8mb4'
)

# 查询“2023-10-01 14:00-15:00的销量趋势”
sql = """
SELECT DATE_FORMAT(time, '%H:%i') AS minute, SUM(quantity) AS total_quantity
FROM sales
WHERE date = '2023-10-01' AND time BETWEEN '14:00:00' AND '15:00:00'
GROUP BY minute
ORDER BY minute;
"""

with conn.cursor() as cursor:
    cursor.execute(sql)
    result = cursor.fetchall()

# 处理结果
minutes = [row[0] for row in result]
quantities = [row[1] for row in result]

# 画图
plt.figure(figsize=(12, 6))
plt.plot(minutes, quantities, marker='o', linestyle='-', color='b')
plt.title('2023-10-01 14:00-15:00 销量趋势')
plt.xlabel('时间（分钟）')
plt.ylabel('销量（杯）')
plt.xticks(rotation=45)
plt.grid(True)
plt.tight_layout()
plt.show()

# 关闭连接
conn.close()

运行结果

运行代码后，会弹出一个折线图，显示14:00-15:00每分钟的销量变化。比如14:30是高峰期，销量15杯；14:45是低谷，销量5杯。小A可以根据这个趋势调整备货，比如14:20多煮点珍珠，14:40少做芋圆。

代码解读与分析

1. 连接Doris：用pymysql连接Doris，因为Doris兼容MySQL协议，所以可以用MySQL的客户端库；
2. 查询数据：执行SQL语句，获取每分钟的销量；
3. 处理结果：把结果中的时间和销量分别放到列表里；
4. 画图：用matplotlib画折线图，展示销量趋势；
5. 关闭连接：用完连接要关闭，避免资源泄漏。

这个代码很简单，但能帮小A快速看到数据的趋势，比Excel好用100倍！

实际应用场景

Doris不是“玩具”，它已经在很多大企业用起来了，比如阿里、字节、腾讯、美团。我们讲几个典型的应用场景：

场景一：电商实时GMV统计

GMV（成交总额）是电商的核心指标，运营需要实时看GMV的变化，比如“今天0点到现在的GMV是多少？”“哪个品类的GMV最高？”。

用Doris的解决方案：

1. 实时导入数据：用Flink把电商的订单数据实时传到Doris；
2. 创建GMV表：用主键模型，主键是订单ID，列包括订单时间、品类、金额；
3. 实时查询：用SQL查“最近1小时的GMV”“今天各品类的GMV Top5”；
4. 可视化：用Superset或Tableau把GMV实时展示在 Dashboard 上。

效果：运营能实时看到GMV变化，比如发现某个品类的GMV突然下降，立刻调整推广策略。

场景二：物流路径优化分析

物流企业需要分析“哪个路线的配送时间最长？”“哪个区域的投诉最多？”，从而优化路径。

用Doris的解决方案：

1. 批量导入数据：用DataX把物流的配送数据（订单ID、出发时间、到达时间、路线、投诉情况）导入Doris；
2. 创建配送表：用列存储，列包括订单ID、出发时间、到达时间、路线、投诉次数；
3. 复杂查询：用SQL查“近一个月配送时间最长的Top10路线”“近一周投诉最多的区域”；
4. 优化决策：根据查询结果，调整路线，比如把配送时间长的路线分成两段，增加快递员。

效果：物流企业的配送时间缩短了20%，投诉率下降了15%。

场景三：游戏用户行为分析

游戏公司需要分析“用户为什么流失？”“哪个关卡的通过率最低？”，从而优化游戏设计。

用Doris的解决方案：

1. 实时+批量导入：用Kafka把用户的行为数据（登录时间、关卡、失败次数、流失时间）实时传到Doris，用Hive把历史数据批量导入；
2. 创建用户行为表：用主键模型，主键是用户ID，列包括登录时间、关卡、失败次数、流失时间；
3. 用户流失分析：用SQL查“流失用户的最后一次行为是哪个关卡？”“失败次数超过5次的用户流失率是多少？”；
4. 游戏优化：根据查询结果，调整关卡难度，比如把通过率低的关卡降低难度，减少用户流失。

效果：游戏的用户留存率提高了10%，付费率提高了5%。

场景四：金融风险控制分析

金融企业需要分析“哪些用户有逾期风险？”“哪些交易是欺诈交易？”，从而降低风险。

用Doris的解决方案：

1. 实时导入数据：用Flink把用户的交易数据（交易时间、金额、地点、用户等级）实时传到Doris；
2. 创建风险控制表：用列存储，列包括交易ID、交易时间、金额、地点、用户等级、逾期情况；
3. 风险分析：用SQL查“近一周交易金额超过10万且用户等级低于3级的用户”“近一个月逾期次数超过3次的用户”；
4. 风险控制：根据查询结果，冻结高风险用户的账户，联系用户核实交易。

效果：金融企业的欺诈交易率下降了25%，逾期率下降了18%。

这些场景的共同点是：需要处理海量数据、需要快速分析、需要实时或近实时的结果，而Doris正好能满足这些需求。

工具和资源推荐

要学好Doris，需要一些工具和资源：

工具推荐

1. 客户端工具：MySQL Workbench（可视化连接Doris）、DBeaver（支持多种数据库，包括Doris）；
2. 数据导入工具：Flink（实时导入）、DataX（批量导入）、Kafka（流数据导入）；
3. 可视化工具：Apache Superset（开源，支持Doris）、Tableau（商业，功能强大）、Metabase（简单易用）；
4. 监控工具：Prometheus + Grafana（监控Doris的FE、BE状态）、Doris自带的Web UI（http://FE_IP:8030）。

资源推荐

1. 官方文档：Apache Doris 官方文档（https://doris.apache.org/zh-CN/docs/），最权威的资料；
2. 社区：Doris 中文社区（https://ask.doris.apache.org/），有问题可以在这里问；
3. 博客：阿里、字节的技术博客，比如《Apache Doris在阿里的实践》《字节跳动用Doris做实时数仓》；
4. 视频教程：B站上的Doris教程，比如《Apache Doris从入门到精通》。

未来发展趋势与挑战

Doris作为开源OLAP引擎的“后起之秀”，未来有很多发展方向，但也面临一些挑战。

未来发展趋势

1. 更强大的实时能力：支持更实时的流数据导入（比如毫秒级），支持更复杂的实时分析（比如实时窗口函数）；
2. 更好的云原生支持：支持Kubernetes部署，支持Serverless模式（按需付费），让用户不用自己管理集群；
3. 更智能的查询优化：用AI优化查询计划（比如自动选择 Join 方式、自动调整分桶数），让用户不用写复杂的SQL优化；
4. 更丰富的生态整合：支持更多的数据源（比如Elasticsearch、MongoDB），支持更多的计算框架（比如Spark、Presto）；
5. 更低的使用门槛：提供更简单的安装方式（比如一键部署），更友好的Web UI（比如可视化建表、可视化查询）。

面临的挑战

1. 处理超大规模数据：当数据量达到PB级时，Doris的查询性能会不会下降？需要优化存储和计算的 scalability；
2. 处理复杂查询：比如多表Join、嵌套子查询，Doris的性能会不会不如ClickHouse？需要优化查询优化器；
3. 稳定性和可靠性：作为开源项目，Doris的稳定性还有待提高，比如大规模集群的故障恢复时间；
4. 社区生态：相比ClickHouse、Presto，Doris的社区还比较小，需要更多的贡献者和用户。

不过，Doris的发展速度很快，社区也在快速增长，相信这些挑战都会慢慢解决。

总结：学到了什么？

核心概念回顾

1. Doris是什么？：为分析而生的开源MPP OLAP引擎，能存海量数据、快速分析、实时更新；
2. MPP架构：很多节点一起算，分工合作，提高速度；
3. 列存储：按列存数据，过滤快、压缩率高；
4. 实时更新：主键模型，卖一杯记一杯，延迟毫秒级；
5. 关键算法：谓词下推（先过滤再计算）、哈希聚合（分组快）。

概念关系回顾

Doris的核心概念就像“奶茶店的团队”：

• OLAP是“店长”，确定分析目标；
• MPP是“店员团队”，分工处理任务；
• 列存储是“工具”，让店员更快做事；
• 实时更新是“效率buff”，让店员实时处理新订单。

实战收获

我们用Doris搭建了奶茶店销售分析系统，学会了：

1. 安装Doris（用Docker）；
2. 创建数据库和表（主键模型、列存储）；
3. 导入数据（Stream Load）；
4. 查询数据（SQL）；
5. 可视化分析（Python + matplotlib）。

思考题：动动小脑筋

1. 思考题一：如果小A的奶茶店开了5家分店，怎么用Doris做跨分店的销售分析？（提示：在表中加“分店ID”列，分组查询时按“分店ID”分组）；
2. 思考题二：Doris怎么处理实时流数据？比如用Kafka传输POS机数据，怎么导入Doris？（提示：用Flink连接Kafka和Doris，实时读取Kafka的数据，写入Doris）；
3. 思考题三：Doris和ClickHouse的区别是什么？什么时候用Doris，什么时候用ClickHouse？（提示：Doris支持实时更新和更友好的SQL，ClickHouse的单表查询更快）；
4. 思考题四：如果Doris的查询速度变慢了，怎么优化？（提示：检查分桶数、索引、统计信息）。

附录：常见问题与解答

Q1：Doris需要多少台服务器？

A：测试环境用1台FE+1台BE就够了；生产环境建议用3台FE（高可用）+ 至少3台BE（负载均衡），具体数量根据数据量和查询量调整。

Q2：Doris支持哪些数据格式？

A：支持CSV、JSON、Parquet、ORC等常见格式，导入时可以用Stream Load、Broker