须要确保下界和上界都是可比较 的字符，可以使用cast()函数。 使用说明：如果操作数是string类型时使用时，应该小心些。起始部分为上界的长字符串将不会匹配上界，该字符串比上界要 大。between 'A' and 'M'不会匹配‘MJ’。如果需要确保表达式能够正常work，可以使用一些函数，如upper(), lower(), substr(), trim()。 举例: 比较操作符 in操作符会和VALUE集合进行比较，如果可以匹配该集合中任何一元素，则返回TRUE。参数和VALUE集合必须是可比较的。所 有使用in操作符的表达式都可以写成用OR连接的等值比较，但是IN的语法更简单些，更精准，更容易让Doris进行优化。 举例： Like操作符 Like操作符 该操作符用于和字符串进行比较。_用来匹配单个字符，%用来匹配多个字符。参数必须要匹配完整的字符串。通常，把%放在 字符串的尾部更加符合实际用法。 百度智能云文档 SQL手册 9 正则表达式操作符 正则表达式操作符 判断是否匹配正则表达式。使用POSIX标准的正则表达式，^用来匹配字符串的首部,$用来匹配字符串的尾部，.匹配任何一个单 字符，*匹配0个或多个选项，+匹配1个多个选项，?表示分贪婪表示等等。正则表达式需要匹配完整的值，并不是仅仅匹配字 符串的部分内容。如果想匹配中间的部分，正则表达式的前面部分可以写成^.* 或者 .*。 ^和$通常是可以省略的。RLKIE操作

灵活度较高，数据分析师可对指标和标签自由组合和定义，但是不同的分 析师对同一数据的定义不尽相同、定义口径不一致，导致指标和标签缺乏统一管理， 4 这使得数据管理和使用的难度都变高。  Dataset 与物理位置绑定，应用层无法进行透明优化，如果 Doris 引擎出现负载较 高的情况，无法通过降低用户查询避免集群负载过高报错的问题。 数据架构 3.0 针对指标和标签定义口径不统一，数据使用和管理难度较高的问题，我们继续对架构进行升  对于业务来说，无需耗费过长时间考虑什么场景应选择哪个数据集使用，语义层对 标签和指标透明统一的定义提升了工作效率、降低了使用成本。 存在的问题： 从架构图可知，标签和指标等数据均处于下游位置，虽然标签与指标在语义层被显式定义， 但仍然无法影响上游链路，数仓层有自己的语义逻辑，加速层有自己的导入配置，这样就造 成了数据管理机制的割裂。 数据架构 4.0 在数据架构 3.0 的基础上， 于增减列的操作不需要修改数据文件，只需要修改 FE 中的元数据，从而可以实现毫秒级的 Schame Change 操作。同时开启 Light Schema Change 功能的数据表也可以支持列名的 修改，这与我们的需求十分匹配，后续我们也会及时升级到最新版本。 写入优化 接着我们在数据写入方面也进行了调整优化，这里几点小经验与大家分享：  Flink 预聚合：通过主键 ID 预聚合，减少写入压力。（前文已说明，此处不再赘述）

load 同步 本地文件，数据流 HTTP Insert into 同步 命令行 MySQL Spark Load 异步 Spark MySQL 最佳实践 04 使用案例 • 根据数据源所在位置选择导入方式。 选择合适的导入方式 • 使用 MySQL 协议定期提交和查看导入作业。 确定导入方式的协议 • 导入方式为同步或异步。 确定导入方式的类型 • 每一批次数据唯一且固定，保证 At-Most-Once