型可能会提升（比如SMALLINT提升到INT或者BIGINT 等），表达式的结果被提升到下一个较大的类型，比如TINYINT 乘以 INT 产生的结果的类型会是BIGINT）。当两个数相乘时，为了避免精度丢失，操作数和表达式结果都会被解释成DOUBLE 类 型。如果用户想把表达式结果转换成其他类型，需要用CAST 函数转换。 %：取模操作符。返回左操作数除以右操作数的余数。左操作数和右操作数都必须是整型。 作业运行失败，在远端存储中产生的 临时目录，以及已经生成的文件不会被删除，需 要用户手动删除。 如果 Export 作业运行成功，在远端存储中产生的 目录，根据远端存储的文件系统语义，可能会保 留，也可能会被清除。比如在百度对象存储（BOS）中，通过 rename 操作将一个目录中的最后一个文件移走后，该目录也 会被删除。如果该目录没有被清除，用户可以手动清除。 Export 作业只会导出 Base 表的数据，不会导出物化视图的数据。 与非 chunked 上传两种方式。对于非 chunked 方式，Header 中必须包含 来标识上 传内容的长度，以保证数据的完整性。 Header 中建议包含 ，这样可以在某些出错场景下避免不必要的数据传输。 命令的目标 有两种方式： 1. 指向 FE 的 HTTP 协议端口。这种方式，FE 会直接将请求做 307 转发到随机的一个 BE 节点。最终请求和数据直接和 这个 BE

Doris简介及特点 Doris是基于MPP架构的OLAP引擎，主要整合了Google Mesa（数据模型）、Apache Impala（MPP Query Engine）和Apache ORCFile （存储格式，编码和压缩）的技术。 Doris的系统架构如下，主要分为FE和BE两个组件，FE主要负责查询的解析、编译、优化、调度 和元数 据管理；BE主要负责查询的执行和数据存储。关于Doris的更多技术细节，可参考其官方文档。 准实时场景下的应用 离线业务分析大多基于T+1的离线数据，但在营销活动场景下，外卖团队往往需要当日的实时数 据进行业务变化的监控与分析，通常情况下会采用实时流计算来实现。 外卖实时业务监控有如下特点： 避免分钟级的生产波动影响，业务上10、15分钟准实时数据可以满足分析需要。 实时数据需要与离线数据进行日环比与周同比的比对。 订单业务需要事件时间，体验业务需要生产时间，业务对齐逻辑复杂。 不同业务线需求差异大，指标需要良好扩展性。

缺乏统一管理， 4 这使得数据管理和使用的难度都变高。  Dataset 与物理位置绑定，应用层无法进行透明优化，如果 Doris 引擎出现负载较 高的情况，无法通过降低用户查询避免集群负载过高报错的问题。 数据架构 3.0 针对指标和标签定义口径不统一，数据使用和管理难度较高的问题，我们继续对架构进行升 级。数据架构 3.0 主要的变化是引入了专门的语义层，语义层的主要作用是将技术语言转 会发生变化。  对于实时新增标签/指标，我们基于名称 ID 的映射在 Doris 表中预先创建适量 ID 列，当标签/指标完成元信息录入后，直接将预留的 ID 分配给新录入的标签/指标， 避免在查询高峰期因新增标签/指标所引起的 Schema Change 开销对集群产生的 影响。经测试，用户在元信息录入后 10 分钟内就可以使用相应的数据。 值得关注的是，在社区近期发布的 1.2.0