你以为大家选Doris是因为性能？其实是因为懒

一臻数据

发布于 2025-06-19 12:51:44

1830

文章被收录于专栏：一臻数据一臻数据

一臻数据

Apache Doris x AI及个人随笔，同时也欢迎大家投稿，共建共进❗️

135篇原创内容

公众号

❝下午三点，某个WX群里突然炸了锅。 "又双叒叕要换OLAP引擎了？我真的累了..." "上次从Hive迁到ClickHouse才多久？现在又要搞Doris？" "求求了，能不能让我们安安静静写代码，别折腾了..." 看到这些消息，我突然意识到一个有趣的现象：这些年大中小厂疯狂追捧Doris，表面上说是因为性能强悍，背地里大家都心知肚明——其实就是懒得折腾了。

懒得学新语法的程序员心声

记得第一次接触ClickHouse，还是比较痛苦的...那些奇怪的语法就像学习一门外语。

-- ClickHouse的奇葩写法
SELECT * FROM table FINAL WHERE id = 
-- 这个FINAL是什么鬼？

再看看Elasticsearch，好家伙，JSON套JSON的查询语句能把人绕晕：

{
  "query": {
    "bool": {
      "must": [
        {"match": {"title": "search"}}
      ]
    }
  }
}

数据分析师小王抱怨道："我就想查个数据，为什么要学这么多奇奇怪怪的语法？我的脑子又不是垃圾桶！"

这时候Doris出现了，像个贴心的老朋友："嗨，用MySQL语法就行了。"

什么？还能这样？大伙的眼睛都亮了。

你看，支持MySQL协议意味着什么？意味着你之前学的SQL知识一点都不浪费，意味着现有的工具和连接器都能直接用，意味着新人培训成本几乎为零。

这不是懒是什么？这是高级的懒——用最少的学习成本获得最大的收益。

懒得搭建复杂架构的运维之痛

某互联网公司的运维小李，桌子上放着三个咖啡杯，眼睛布满血丝。

"这套大数据架构真的要命！"

他对着电脑屏幕自言自语："Kafka负责数据流，Spark处理计算，Hive做数据仓库，Presto跑查询，Redis做缓存...我感觉自己像个马戏团的杂技演员，要同时转十几个盘子。"

每个组件都有自己的脾气：

• Kafka集群挂了，消息积压如山

• Spark任务莫名其妙就失败了

• Hive查询慢得像蜗牛爬行

• Presto内存不够直接OOM

组件之间的版本兼容性更是一个大坑

"有没有一个东西能把这些都搞定？"小李看着天花板，发出了灵魂拷问。

Doris好像听到了祈祷声一样出现了："我一个就够了。"

存储？我有列式存储。

计算？我有MPP架构。

实时分析？我天生支持。

多数据源查询？我的联邦查询了解一下。

运维复杂度从10个组件降到1个，这种多合一的懒真的太爽了。

懒得写ETL的数据工程师觉醒

数据工程师老张最害怕的就是老板突然跑过来说："张工，我们需要把MySQL、MongoDB、还有那个什么Elasticsearch的数据关联起来做个报表。"

传统做法是什么？写ETL脚本，把各种数据源的数据抽取出来，转换格式，然后加载到数据仓库里。

这个过程就像做菜一样繁琐：

1. 从MySQL里捞数据（像洗菜）2. 清洗转换格式（像切菜）3. 导入到Hive（像下锅炒）4. 建立各种索引（像调味）5. 写查询SQL（像摆盘）

每次需求变更，这个流程都要重新来一遍。老张经常加班到半夜，就为了搞定这些数据管道。

"能不能让我直接查，不要这么多中间步骤？"老张望着窗外的星空，做着不切实际的梦。

Doris的多源数据目录功能听到了老张的心声："你可以直接查MySQL、Hive、Elasticsearch...想查什么查什么，不用导来导去。"

-- 直接跨数据源查询，就是这么简单
SELECT 
    u.name,
    o.total_amount,
    l.action_time
FROM mysql_catalog.user_db.users u
JOIN hive_catalog.order_db.orders o ON u.id = o.user_id
JOIN es_catalog.log_index.user_logs l ON u.id = l.user_id
WHERE o.create_time >= '2024-01-01'

这种跨界的懒让老张感动得差点哭了。