Doris表改造这件事，为什么有人秒完工，有人却要拆房重建？

"你说这事儿奇怪不奇怪，同样是改Doris表结构，小李那边几秒钟就搞定了，我这边却要停服务好几个小时，老板都快疯了。"  老张的困惑，其实揭示了一个很多技术人都会遇到的问题：为什么同样是Schema变更，差别竟然这么大？ 答案就藏在Apache Doris的设计哲学里。

装修房子的两种境界

Schema变更这事，真就像是装修房子。

你要给房子换个门牌号，或者重新刷个墙，这叫"轻装修"。房子还是那个房子，结构没变，住户可以正常生活，顶多就是刷墙的时候有点油漆味，得散散味。

你要拆掉承重墙，重新规划房间布局，这叫"重装修"。这时候住户必须搬出去，整个房子都要重新来过，时间长，成本高，风险大。

Doris的Schema变更也是这个道理。

轻量级Schema Change，就是那种"轻装修"。

你要给表加个新列，删个不重要的列，或者给列改个名字，这些操作都不需要动到数据本身。就像给房子换门牌号一样，几秒钟就能搞定，数据库该跑还跑，用户该访问还访问。

重量级Schema Change，就是"重装修"。

你要改列的数据类型，重新排列列的顺序，这就需要把所有数据重新组织一遍。就像拆掉承重墙重新布局，数据要被重新写一遍，存储空间会翻倍，时间从几分钟到几天都有可能。

秒级完工的秘密

小李能秒级完工，是因为他知道什么时候该"轻装修"。

他们公司的用户行为分析表，需要新增一个"用户来源渠道"字段。

这是典型的轻量级操作 —— 给表加一个Value列。

ALTER TABLE user_behavior ADD COLUMN source_channel VARCHAR() DEFAULT "unknown";

这行代码执行的时候，Doris只是在元数据层面记录了一个信息："这个表现在有个新列叫source_channel。"

原来的数据文件一个字节都不用动，新数据写入的时候带上这个字段就行了。正如在门口贴个新门牌号，房子本身不用改。

老张就没这么幸运了。

拆房重建的代价

老张的情况比较复杂。他们要把订单表里的金额字段从FLOAT改成DECIMAL，保证财务计算的精度。

ALTER TABLE order_info MODIFY COLUMN amount DECIMAL(,);

这就是重量级操作了。

Doris接到这个指令后，心里也是一万个无奈："xd，你这是要我把所有的FLOAT数据重新按DECIMAL格式存一遍啊。"

重量级操作的过程就像拆房重建：

Doris会在后台启动一个专门的任务，逐个处理表的每个tablet。每个tablet都要重新读取原始数据，按新的数据类型重新编码，写入新的数据文件。

最要命的是，为了保证数据一致性，转换期间新写入的数据要同时写到新tablet和旧tablet里。

这就是传说中的"双写"现象，完成数据转换后，旧 tablet 会被删除，新 tablet 将取而代之。

聪明的选择

真正聪明的DBA，会在设计表结构的时候就考虑好Schema变更的问题。

小王就是这样的聪明人。他们公司刚上线一个新的电商系统，设计商品表的时候，小王特意把价格字段定义成了DECIMAL类型，虽然当时只需要存整数。

"万一以后要支持小数呢？现在改比以后改要轻松得多。"

事实证明小王的远见。三个月后产品经理果然提出要支持0.01元的定价，其他公司可能要停服务改数据类型，小王这边连眉头都没皱一下。

还有个细节很多人不知道👇

重量级Schema变更启动后，你可以用这个命令查看进度：

mysql > SHOW ALTERTABLECOLUMN\G;
*************************** 1. row ***************************
        JobId: 20021
    TableName: tbl1
   CreateTime: 2019-08-05 23:03:13
   FinishTime: 2019-08-05 23:03:42
    IndexName: tbl1
      IndexId: 20022
OriginIndexId: 20017
SchemaVersion: 2:792557838
TransactionId: 10023
        State: FINISHED
          Msg:
     Progress: NULL
      Timeout: 86400
1 row in set (0.00 sec)

好比装修工程的进度表，你能看到当前状态是RUNNING还是FINISHED，完成了多少百分比。

如果中途发现不对劲，还能取消：

CANCEL ALTER TABLE COLUMN FROM table_name;

但是取消也有代价，已经转换的部分会被丢弃，就像装修装到一半停工，前面的工作都白做了。

结语

数据库Schema设计，反映的是一个团队对业务理解的深度。

那些一上来就要求"完美"Schema的团队，往往在后续的迭代中付出更大的代价。

那些在设计阶段就考虑到未来变更可能性的团队，往往能在快速迭代中保持技术优势。

Doris的轻量级和重量级Schema变更机制，其实给了我们一个重要启示：不是所有的改变都需要付出同样的代价，关键是要理解哪些改变是"换门牌号"，哪些改变是"拆房重建"。

在当下快速变化的时代，能够低成本适应变化的系统，往往比一开始就"完美"的系统更有价值。

技术如此，商业如此，人生亦如此，你觉得呢？