doris tips

doris tips

1 schema表格式字段长度

如果是数字+字母这种的长度等于hive sql里面  length(variable)的长度

如果是中文要占3-4个Char

2 表增加分区
可以通过脚本自己构造多个sql 语句
类似
ALTER TABLE example_db.my_table ADD PARTITION p20140102 VALUES [("20140101"), ("20140102"));

3 应用场景

Doris 场景 目前明确可支持的场景

• 聚合查询场景

  • 查询模式通常为select sum/max/min/count from group by

  • 数据特征一般为上游原始数据在Doris中聚合后数据量会数据量级的减少，利用Doris的聚合模型收益很高

  • 可以利用Rollup进一步提升聚合度

• 明细查询场景

  • 可以利用Doris的前缀索引或者bitmap索引实现点查或者小范围scan

  • 可以使用物化视图进行聚合查询，比Rollup更加灵活

• 灵活的多维过滤场景

  • 支持前缀索引进行谓词过滤，使用Rollup/物化索引可以灵活定制前缀索引

  • 支持bitmap索引作为二级过滤

• 从Hive以离线的方式T+1/灵活日期导入，自动编码bitmap字典，支持最多TB级别数据导入

• 从Kafka实时导入，参考峰值TPS在5w左右，和模型设计相关，具体上限需要实测。实时性目前弱于Druid

• 查询延迟 TP99 3~5s

• 查询QPS 单集群100以下

暂时无法支持的场景

• 数据导出Doris到其他存储介质，比如ToMySQL，ToHive(Coming soon)；大结果集（百万行）的导出性能很差

• 目前不支持除了Hive和Kafka之外其他数据源的导入

• 单次上游TB级别的数据导入，难以满足用户对于延时的要求

• 高QPS场景，比如单集群上万QPS；稳定的亚秒级（几百毫秒）响应

• 稳定性和可用性无法和MySQL相比，因此目前Doris的主要发力方向还是面向公司内部的分析场景；支持在线业务能力较弱，稳定性难以保障

• 异步长查询（20s以上，分钟级查询），建议使用Presto等Ad-hoc引擎

• 不支持需要Scan大量数据（几十GB）同时进行复杂计算（大数据量shuffle）的查询，未来可能通过SparkOnDoris解决

• 支持低频点更新/点删除，高频点更新对查询性能影响很大

• Doris只能通过Replace聚合模型通过导入批量数据实现对相同key的value列的更新，但是导入同一批次对于相同key有多个value列，更新顺序无法保证

• 基于任意时间窗口的聚合 *** 作

一定不支持的场景

• OLTP场景，类似MySQL一样的增删改查