Doris的表模型和三家餐厅的故事

❝

上周一位用户苦着脸跟我说："我们公司的数据查询慢得要命，每次老板要个报表，我都得提前半天准备，生怕系统卡死。" 

这让我想起了另一个场景。去年我去一家餐厅吃饭，点餐后等了40分钟才上菜。 老板解释说："我们什么菜都现做，保证新鲜。"听起来很好，可我饿得前胸贴后背了。

Doris数据表模型的选择，也像这餐厅的经营模式一般。选对了，客人满意，老板赚钱；选错了，客人跑光，老板倒闭。

三家餐厅的故事

有这么一个故事：在D街上，开了三家餐厅，老板都姓张。

原汁原味餐厅

张老大开了一家原汁原味餐厅。

每位客人点的每道菜，他都详细记录在案：几点几分，谁点的，什么菜，多少钱。哪怕同一桌客人点了三份宫保鸡丁，他也要分别记录三次。

客人想查自己的消费记录？没问题，从第一筷子到最后一粒米，清清楚楚。

这就是Doris的明细模型。每一条数据都原原本本保存，一条不少，一条不改。

适合那些需要追根溯源的场景：用户行为分析、审计日志、交易流水等
。你若是想知道用户在6月25日下午6点6分到底点击了什么？明细模型告诉你：点的就是那个红色按钮。

客户专属餐厅

张老二开了一家客户专属餐厅。

每个客人都有专属座位，编号固定。老客户来了，直接坐老位置，点的菜会覆盖上次的记录。张老二只记住每个客户最新的喜好。

今天你点了麻婆豆腐，明天又点了回锅肉？那就只记录回锅肉。

这就是Doris的主键模型。每个主键只保留最新的数据，旧数据自动被覆盖。

电商平台的用户资料、CRM系统的客户信息、实时更新的库存数据，都适合这种模式。

若用户改了手机号？系统自动更新，不会出现两个号码并存的尴尬。

数据驱动餐厅

张老三最聪明，开了一家数据驱动餐厅。

他不关心谁点了什么，只关心结果：今天一共卖了多少份宫保鸡丁？营业额多少？客流量如何？

他的记录本上只有汇总数据：宫保鸡丁50份，营收3000元，客人总数120人。

这就是Doris的聚合模型。原始数据进来就被聚合，只保留汇总结果。

财务报表、销售仪表盘、流量统计，这些场景的核心是汇总，不是明细。老板问："这个月销售额多少？"聚合模型秒答。

选择的智慧

三种模式，各有千秋。关键是搞清楚自己到底要什么。

小李是某电商公司的数据架构师。他跟我分享了一次"血的教训"。

"去年我们做用户画像项目，我脑子一热，选了聚合模型。想着可以提升查询性能，多好！"小李苦笑道，"上线一个月后，业务方找我：'小李啊，我想看看某个用户的具体购买轨迹。'我傻眼了，聚合模型只有汇总数据，哪来的用户轨迹？"

项目重做，小李换成了明细模型。"现在想要什么维度的分析都能做，就是查询慢一点。但至少不用重头再来。"

另一位朋友老王就聪明多了。他负责一个实时风控系统，用户状态变化频繁。"我直接选主键模型，写时合并。用户的风险等级一更新，系统立马反映。查询速度也快，一举两得。"

还有一个有趣的案例👇

某新闻网站的数据团队，原本用明细模型存储文章阅读数据。每次统计热门文章排行榜，都要扫描几千万条记录，慢得要命。

后来他们增加了一张聚合模型表，专门存储文章的阅读汇总数据。文章ID作为Key，阅读量用SUM聚合。从此，热门排行榜查询从30秒缩短到0.3秒！

经过无数次踩坑，他们总结出选择Doris表模型的三条铁律：

第一条：业务需求决定一切

需要查明细？选明细模型。需要更新数据？选主键模型。只要汇总结果？选聚合模型。

听起来废话，但很多人就是想不明白这个道理。

第二条：性能和功能不可兼得

明细模型功能最全，性能中等。聚合模型性能最好，功能受限。主键模型介于两者之间。

鱼和熊掌，很难兼得。

第三条：选定就是终身

Doris的表模型一旦确定，无法修改。选错了只能推倒重来。

所以前期设计马虎不得，宁可多花时间思考，也不要事后后悔。

结语

写完，我想起了一句话：世界上没有完美的解决方案，只有最适合的选择。

很多技术人都有完美主义情结，总想找到一个万能模型解决所有问题。

但现实是，Doris的表模型当前只给了你三把钥匙，每把都能开不同的门。硬要用一把钥匙开所有门，只会把锁搞坏。

那么，你的Doris表模型选对了吗？