须要确保下界和上界都是可比较 的字符，可以使用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操作

Duplicate 明细模型进行了对比 ，相较于 Unique 模型和 Duplicate 模型，Aggregate 聚合模型满足我们部分列更新的场景需求： Aggregate 聚合模型可以支持多种预聚合模式，可以通过 REPLACE_IF_NOT_NULL 的方式实 现部分列更新。数据写入过程中，Doris 会将多次写入的数据进行聚合，最终用户查询时， 返回一份聚合后的完整且正确的数据。 另外两种数 于增减列的操作不需要修改数据文件，只需要修改 FE 中的元数据，从而可以实现毫秒级的 Schame Change 操作。同时开启 Light Schema Change 功能的数据表也可以支持列名的 修改，这与我们的需求十分匹配，后续我们也会及时升级到最新版本。 写入优化 接着我们在数据写入方面也进行了调整优化，这里几点小经验与大家分享：  Flink 预聚合：通过主键 ID 预聚合，减少写入压力。（前文已说明，此处不再赘述） 基于圈选结果，需要支持标签和指标的明细查询。 经过调研，我们最终采用了 Doris on ES 的解决方案来实现以上要求，将 Doris 的分布式 查询规划能力和 ES 的全文检索能力相结合。Doris on ES 主要查询模式如下所示： SELECT tag, agg(metric) FROM Doris 10 WHERE id in (select id from Es where tagFilter)

的数据生产成本较高和查询效率偏低的问题，他们通过引入Apache Doris引擎优化生产方案，实 现了低成本生产与高效查询的平衡。并以此分析不同业务场景下，基于Kylin的MOLAP模式与基于 Doris引擎的ROLAP模式的适用性问题。希望能对大家有所启发或者帮助。 本文侧重于以Doris引擎为“发动机”的数仓生产架构的改进与思考。在开源的大环境下，各种数据 引擎百花齐放，但由于业务的复杂性与多样 织机构的变化是一个绕不开的技术问题。此外，商家品类、类型等其它维度也存在变化维的问题 。如下图所示： 数据生产面临的挑战 数据爆炸，每日使用最新维度对历史数据进行回溯计算。在Kylin的MOLAP模式下存在如下问题： 历史数据每日刷新，失去了增量的意义。 每日回溯历史数据量大，10亿+的历史数据回溯。 数据计算耗时3小时+，存储1TB+，消耗大量计算存储资源，同时严重影响SLA的稳定性。 预计 算与管理成本较高。ROLAP需要强大的关系型DB引擎支撑。长期以来，由于传统关系型DBMS的 数据处理能力有限，所以ROLAP模式受到很大的局限性。随着分布式、并行化技术成熟应用，MP P引擎逐渐表现出强大的高吞吐、低时延计算能力，号称“亿级秒开”的引擎不在少数，ROLAP模式 可以得到更好的延伸。单从业务实际应用考虑，性能在千万量级关联查询现场计算秒开的情况下 ，已经可以覆盖到很多应用场景，具备应