巨人肩膀
改版通知

巨人肩膀网站已全新改版。若您仍依赖旧站功能或数据，欢迎联系我们，我们会协助处理。联系我们

← 返回专栏列表

几道常见面试问题总结二

ckckck2025年1月10日12 浏览

1：OLTP与OLAP的区别？

1. 数据主要应用

OLTP vs OLAP

2. 数据内容

OLTP vs OLAP

3. 性能要求

OLTP vs OLAP

总结

OLTP vs OLAP

2：数据湖、数据仓库、数据中台、湖仓一体、混合架构之间的区别？

数据架构对比
数据架构对比
数据架构对比

3：Routing Load 调优与降低磁盘IO

1. 任务调度周期

  • max_batch_interval：通过缩短任务调度周期加速数据消费。但更小的任务调度周期可能会带来更多的CPU资源消耗。任务调度周期最小值为5s。

2. 任务并行度

  • max_routine_load_task_concurrent_num 和 desired_concurrent_number：在partition数量和BE数量较多时，可以通过设置较大的该参数来加速任务执行。但更大的并行度可能会带来更多的CPU资源消耗。
  • 单个routine load任务会根据kafka topic partition数、BE数等被拆分为若干个子任务，分发至多个BE执行。任务并行度取决于Job配置desired_concurrent_num、可用BE数、FE配置、topic partition数和max_routine_load_task_concurrent_num的最小值。

3. 任务批量大小

  • routine_load_task_consume_second：通过增大单次读取持续时间加速数据消费。
  • max_routine_load_batch_size：通过增大单次读取的数据量加速数据消费。
  • 根据日志判定当前的批量参数设置是否过小。正常情况下，日志的left_bytes字段应该>=0，表示一次读取的数据量还未超过max_routine_load_batch_size上限。否则，说明max_routine_load_batch_size过小。

4：Flink CDC 1.x 与 2.x 的区别

  • 一致性通过加全局锁保证：全量 + 增量读取的过程需要保证所有数据的一致性，因此需要通过加锁保证。但加锁在数据库层面上是一个十分高危的操作。
  • 单并发任务同步，不支持水平扩展：Flink CDC 底层是基于 Debezium，架构是单节点，因此只支持单并发。在全量阶段读取阶段，如果表非常大（亿级别），读取时间在小时甚至天级别，用户不能通过增加资源去提升作业速度。
  • 不支持断点续传：全量读取阶段不支持 checkpoint，因此会存在一个问题：当我们同步全量数据时，假设需要5个小时，当我们同步了4小时的时候作业失败，这时候就需要重新开始，再读取5个小时。
  • 并发读取：全量数据的读取性能可以水平扩展。
  • 全程无锁：不对线上业务产生锁的风险（全局锁退化为表级锁）。
  • 断点续传：支持全量阶段的 checkpoint。
  • MySQL CDC 支持动态加表。
  • 分片算法优化。

CDC 2.0 无全局锁如何保证一致性？

  • 一个SourceReader包含多个chunk，一致性包括：
    • 一个chunk内部的一致性。
    • 一个SourceReader里，多个chunk的一致性。
  • chunk读取：记录binlog（低水位）=> 开始读取，得到数据 => 放到一个buffer里（等待修正）=> 再次查看binlog（高水位）=> 如果高水位 > 低水位，说明读取期间有变化 => 获取变化的binlog，修正读取的数据 => 单个Chunk中的数据一致性。
  • SourceReader内部多个Chunk的一致性：取多个chunk之间最大的高水位，每个chunk去补足自己的高水位到最大高水位之间的数据 => 所有的chunk都同步到了同一个进度。

关于 serverId

  • 配置 server-id 在 MySQL 服务器中，每个 slave 都有一个唯一的 server-id，用于区分来自不同的 slave 的 MySQL binlog。因此，在需要进行 CDC 操作时，需要为 MySQL 服务器配置 server-id。
  • 配置 job：每个 job 都需要配置一个独立的 replication slot，用于表示连接到 master 的客户端。当订阅某个表时，可以为该表创建一个新的 replication slot。

5：Presto 与 ClickHouse 的缺点

Presto 缺点

  • 没有容错性：不支持单个query内部执行容错。
  • 不支持事务：不是数据库，不进行数据存储，不支持在线事务。
  • 内存限制：基于内存计算，当内存空间不足时，不会将一部分结果保存到磁盘上，直接查询失败，不适合大表的join操作。
  • 并行限制：多个task并行在worker节点进行计算，当其中一台worker计算缓慢，会让整个query流程效率变慢。
  • 并发限制：因为全内存操作+内存限制，能同时处理的数据量有限，因而导致并发能力不足。
  • 维护性：数据关联组件多、维护成本高。
  • 查询性能：相较于doris、starrocks等MPP数据库，查询性能一般。
  • 缺少 Bitmap 数据类型：在标签计算方面存在一些不足。

ClickHouse 缺点

  • 不支持事务。
  • 缺少完整的UPDATE DELETE操作。
  • 部分技术支持待完善。
  • 不支持BIOB DOCUMENT 类型数据。
  • 不支持高并发。
  • 不支持二级索引。
  • 有限的SQL支持。
  • 不支持窗口功能。
  • 元数据管理需要人工干预维护。
  • 多表join效率性能比较低。

6：StarRocks/Doris Bitmap索引与Bloom Filter索引的使用场景和限制

Bitmap索引

适应场景

  1. 非前缀过滤。
  2. 多列过滤Filter。
  3. 人群圈选，精确去重等。

优点

  • 对于基数较低，值大量重复的列，使用Bitmap索引能够减少查询的响应时间。
  • Bitmap索引所占的存储空间通常只有索引数据的一小部分，更节省存储空间。
  • 支持为多个列创建Bitmap索引，提高多列查询的效率。

限制

  • Bitmap索引适用于可使用等值条件查询或[NOT] IN范围查询的列。
  • 主键模型和明细模型中所有列都可以创建Bitmap索引；聚合模型和更新模型中，只有维度列（即Key列）支持创建Bitmap索引。
  • Bitmap索引不适用更新频繁的列，不适合列基数较高的场景。
  • 不支持对Float、Double、Decimal类型的列建Bitmap索引。

Bloom Filter索引

适应场景

  1. 非前缀列过滤。
  2. 高基数列。
  3. 查询需对某列高频过滤，且查询条件是in和=。
  4. 非Tinyint、Float、Double、DECIMAL类型的列。

优点

  • Bloom filter索引可以快速判断表的数据文件中是否可能包含要查询的数据，如果不包含就跳过，从而减少扫描的数据量。
  • Bloom filter底层实现是通过bitmap+多个hash函数来实现的，空间效率和时间效率都比较高，但有一定的误判率。

限制

  • 主键模型和明细模型中所有列都可以创建Bloom filter索引；聚合模型和更新模型中，只有维度列（即Key列）支持创建Bloom filter索引。
  • 不支持为TINYINT、FLOAT、DOUBLE和DECIMAL类型的列创建Bloom filter索引。
  • Bloom filter索引只能提高包含in和=过滤条件的查询效率。

7：Doris/StarRocks的几种Join场景和限制

BucketShuffleJoin

  • 优点：
    • 降低网络与内存开销，使一些Join查询具有更好的性能。
    • 对于表的数据分布方式没有侵入性，对用户透明。
    • 可以为Join Reorder提供更多可能的优化空间。

BucketShuffleJoin的规划规则

  • 只生效于Join条件为等值的场景。
  • 在等值Join条件之中包含两张表的分桶列。
  • 左表的分桶列的类型与右表等值join列的类型需要保持一致。
  • 只作用于Doris原生的OLAP表。
  • 对于分区表，需要尽量使用where条件使分区裁剪的策略能够生效。

ColocationJoin

  • 优点：适合几张表按照相同字段分桶，并高频根据相同字段Join的场景。

ColocationJoin限制条件

  • Colocate Table必须是OLAP类型的表。
  • 同一CG内的表的分桶键的类型、数量和顺序完全一致，并且桶数一致。
  • 同一个CG内所有表的所有分区的副本数必须一致。
  • 同一个CG内所有表的分区键，分区数量,分区列的类型可以不同。

RuntimeFilter

  • 优点：旨在为某些Join查询在运行时动态生成过滤条件，减少扫描的数据量，避免不必要的I/O和网络传输，从而加速查询。

RuntimeFilter查询选项

  • runtime_filter_type：包括Bloom Filter、MinMax Filter、IN predicate、IN Or Bloom Filter、Bitmap Filter。
  • runtime_filter_mode：用于调整Runtime Filter的下推策略。
  • runtime_filter_wait_time_ms：左表的ScanNode等待每个Runtime Filter的时间。
  • runtime_filters_max_num：每个查询可应用的Runtime Filter中Bloom Filter的最大数量。
  • runtime_bloom_filter_min_size：Runtime Filter中Bloom Filter的最小长度。
  • runtime_bloom_filter_max_size：Runtime Filter中Bloom Filter的最大长度。
  • runtime_bloom_filter_size：Runtime Filter中Bloom Filter的默认长度。
  • runtime_filter_max_in_num：如果join右表数据行数大于这个值，我们将不生成IN predicate。

RuntimeFilter的规划规则

  • 只支持对join on clause中的等值条件生成Runtime Filter。
  • 不支持将Runtime Filter下推到left outer、full outer、anti join的左表。
  • 不支持src expr或target expr是常量。
  • 不支持src expr和target expr相等。
  • 不支持src expr的类型等于HLL或者BITMAP。
  • 目前仅支持将Runtime Filter下推给OlapScanNode。
  • 不支持target expr包含NULL-checking表达式。
  • 不支持target expr中的列（slot）无法在原始表中找到某个等价列。
  • 不支持列传导。
  • Target expr和src expr的类型必须相等。
  • 不支持PlanNode.Conjuncts生成的Runtime Filter下推。

Doris Join调优建议

  1. 在做Join的时候，尽量选择同类型或者简单类型的列。
  2. 尽量选择Key列进行Join。
  3. 大表之间的Join，尽量让它Colocation。
  4. 合理的使用Runtime Filter。
  5. 涉及到多表Join的时候，需要去判断Join的合理性。

8：几款数据湖产品选型对比

数据湖产品对比
数据湖产品对比
end