1. 拷打项目 -— 略
2. 有什么高吞吐写入的组件(doris，ck。。)
3. 为什么支持高吞吐呢(LSM，写缓存，多节点)
4. clickhouse不适合哪些场景(join，高频微批写入，高qps)
5. clcikhouse和doris适合点查吗，为什么?
6. 如何保证数据质量
7. 哪些操作会引起shuffle、
8. 进程和线程的区别
9. tcp为什么能保证数据稳定(三次握手四次挥手)，还有什么吗
10. 进程里面的堆和栈有什么区别

答案如下

2. 高吞吐写入的组件（Doris、ClickHouse等）

考察知识点

主流存储/OLAP组件的写入性能特性、高吞吐设计核心逻辑（并行化、IO优化、异步处理）、场景适配差异、组件选型权衡依据

参考回答

高吞吐写入组件需突破“磁盘IO瓶颈”“网络传输限制”“并发竞争冲突”三大核心问题，主流组件覆盖实时流、批量ETL、KV存储等场景，具体特性如下：

（1）ClickHouse（CH）——实时高吞吐写入标杆

• 写入性能：单节点实时写入吞吐量可达100万-200万条/秒（Row格式，单条数据100B），分布式集群（10个Shard）支持1000万-2000万条/秒；批量导入Parquet文件时，吞吐量可达500MB-1GB/秒，是实时分析场景的首选。
• 核心设计（支撑高吞吐）：
  • MergeTree存储引擎：
    1. 写入流程：数据先写入内存（MemTable，默认大小64MB），内存中按“排序键”（如dt+user_id）有序存储，避免随机写；当MemTable达到阈值或满足时间条件（30分钟），异步刷盘为“不可变Part文件”——刷盘过程为纯顺序写，磁盘IO效率最大化（HDD顺序写速度100MB/秒，SSD可达500MB/秒）。
    2. 后台Compaction：独立线程定期合并小Part文件（如将100个100MB Part合并为1个10GB Part），减少文件数量（避免后续查询多文件扫描），且合并过程不阻塞新写入。
  • Shard+Partition并行架构：
    1. 分布式表按Shard（分片）分布在不同节点，每个Shard内按时间/业务维度分Partition（如日分区）；多客户端可同时写入不同Shard/Partition，无锁竞争（如10个客户端写入10个Shard，并行度=节点数），吞吐随节点数线性扩展。
  • 轻量级协议与低开销：
    1. 支持TCP原生协议，写入请求无需复杂解析（无事务日志同步、无元数据频繁更新），客户端发送数据后快速返回（单次写入响应时间<1ms），适合高频次写入。
• 适用场景：实时日志写入（用户行为日志、监控指标）、高频交易数据存储（股票行情、支付流水）、秒级延迟的实时分析（实时GMV监控、用户路径追踪）。
• 典型案例：某电商平台用ClickHouse存储实时用户行为日志，单日写入量120TB，15个Shard支撑1500万条/秒写入，下游对接实时看板，延迟<2秒，满足“大促实时流量监控”需求。

（2）Apache Doris——准实时批量高吞吐

• 写入性能：单节点Stream Load（实时写入）吞吐量30万-80万条/秒，Broker Load（批量导入HDFS数据）吞吐量200MB-500MB/秒；分布式集群（10个BE节点）支持300万-800万条/秒，兼顾批量与准实时场景。
• 核心设计（支撑高吞吐）：
  • Partition+Bucket双层并行：
    1. 按时间/业务维度分Partition（如日分区），每个Partition内按“分桶键”（如user_id%100）分100个Bucket，每个Bucket对应一个BE节点的存储单元；写入时按“Partition+Bucket”并行（100个Bucket可同时写入100个BE节点），分散IO压力，避免单节点过载。
  • 多导入方式适配场景：
    1. Stream Load：对接Kafka实时流，支持每秒多次小批量写入（配置batch_size=1000，避免小文件），适合准实时报表（T+0.5）；
    2. Broker Load：批量导入Hive/Spark产出的Parquet文件，通过“分片读取+并行写入”，TB级数据导入耗时<1小时，适合离线ETL同步；
    3. Routine Load：自动消费Kafka Topic数据，按配置批次（如10万条/批）批量写入，减少中间组件依赖（无需Flink/Spark转发）。
  • 内存缓冲+批量刷盘：
    1. 写入数据先暂存于BE节点的内存缓冲区（默认1GB），累计到阈值后批量刷盘为“Segment文件”（列存格式），单次刷盘可写入1GB数据——IO次数比单条写入减少1万倍（对比单条100B数据，1GB需1000万条，单次刷盘替代1000万次IO）。
• 适用场景：准实时业务报表（T+0.5）、每日批量ETL数据导入（业务库全量同步）、兼顾写入吞吐与查询灵活性的场景（如多维度报表分析）。
• 典型案例：某金融机构用Doris存储每日交易流水（单日50TB），通过Broker Load从HDFS批量导入，支撑“每日资产负债报表”“客户交易明细查询”，导入延迟<40分钟，查询响应<5秒，满足监管合规要求。

（3）Apache Kafka——实时流数据缓冲中枢

• 写入性能：单分区写入吞吐量10万-50万条/秒（单条消息1KB），多分区（100个分区）集群支持1000万-5000万条/秒；单节点磁盘写入速度可达200MB-500MB/秒（SSD），是实时流数据的“必经之路”。
• 核心设计（支撑高吞吐）：
  • 日志追加写入（纯顺序写）：
    1. 每个Topic的分区对应一个“日志文件”，数据按时间顺序追加写入，无任何随机写操作（磁盘顺序写速度是随机写的10-100倍）；即使是HDD磁盘，单分区顺序写吞吐量也可达20万条/秒。
  • 分区并行与副本机制：
    1. Topic分多个分区，每个分区分布在不同Broker节点，多生产者可同时写入不同分区（如100个生产者写入100个分区，并行度最大化）；
    2. 副本机制（默认3副本）确保数据可靠性：仅Leader副本接收写入，Follower副本异步同步数据（同步延迟<10ms），不阻塞写入流程（对比同步副本，吞吐提升3-5倍）。
  • 生产者缓存与批量发送：
    1. 生产者客户端默认开启缓存（batch.size=16KB），数据累计到缓存阈值或满足时间阈值（linger.ms=10）后批量发送至Broker，减少网络请求次数（批量发送比单条发送吞吐提升10-100倍）；
    2. 支持Snappy/Gzip压缩，减少网络传输量（压缩率3-5倍），进一步提升吞吐（如1KB消息压缩至200B，单分区吞吐从10万条/秒提升至50万条/秒）。
• 适用场景：实时流数据缓冲（APP埋点日志、IoT设备上报）、分布式系统解耦（业务系统→Kafka→数仓/实时计算）、高吞吐数据流转发（Flink/Spark Streaming的数据源）。
• 典型案例：某短视频平台用Kafka接收用户实时互动日志（点赞、评论、播放），单日写入量600TB，1200个分区支撑4500万条/秒写入，下游对接Flink实时计算（实时推荐）与ClickHouse（历史日志分析），延迟<500ms。

（4）Apache HBase——KV型数据高吞吐写入

• 写入性能：单节点写入吞吐量5万-20万条/秒（单条数据1KB），分布式集群（10个RegionServer）支持50万-200万条/秒；适合TB-PB级KV数据存储，支持随机读写。
• 核心设计（支撑高吞吐）：
  • LSM-Tree（日志结构合并树）：
    1. 写入流程：数据先写入WAL（Write-Ahead Log，确保崩溃后可恢复），再写入内存（MemStore，默认128MB）；MemStore满后异步刷盘为HFile（不可变文件，顺序写）；
    2. 后台Compaction：合并小HFile为大文件，删除过期/重复数据（如更新操作产生的旧数据），避免磁盘碎片化，且合并过程不阻塞写入。
  • Region分片与负载均衡：
    1. 表按RowKey范围分为多个Region（如RowKey前缀0-9分10个Region），每个Region由一个RegionServer管理；HMaster自动将Region均衡分配到不同RegionServer，避免单个节点写入压力过大（如某Region写入量过高时，自动拆分并迁移）。
  • 批量写入API：
    1. 支持PutList批量写入API，一次请求可写入多条数据（如1000条/批），减少RPC请求次数（批量写入比单条写入吞吐提升5-10倍）；
    2. 支持异步写入模式（setAsync(true)），客户端无需等待服务器确认，进一步提升并发能力。
• 适用场景：KV型数据实时写入（用户画像标签、设备状态记录）、随机读写业务（订单状态查询、用户积分查询）、时序数据存储（传感器历史数据）。
• 典型案例：某物联网平台用HBase存储设备实时状态数据（每秒15万条设备上报），单表150个Region，支撑“设备在线状态查询”“历史数据回溯”，写入延迟<100ms，查询延迟<50ms，满足“设备监控实时性”需求。

（5）Apache Hive（离线批量高吞吐）

• 写入性能：基于Spark/MapReduce的批量插入（INSERT OVERWRITE）吞吐量可达100MB-300MB/秒（ORC格式），适合TB级离线数据写入；单条插入性能差（不适合实时场景）。
• 核心设计（支撑高吞吐）：
  • 分布式计算框架支撑：
    1. 写入操作基于Spark/MapReduce执行，通过多Task并行写入HDFS（如100个Map Task同时写入不同分区），利用分布式计算的并行能力提升吞吐（100个Task并行写入，吞吐比单Task提升80-90倍）。
  • 列存格式优化：
    1. 支持ORC/Parquet列存格式，写入时自动压缩（ORC压缩率3-5倍），减少磁盘IO量；列存格式的批量写入效率比行存格式（Text）高2-3倍（无需写入无用列数据）。
  • 分区与分桶：
    1. 按时间/业务维度分区（如dt=20240901），写入时仅操作目标分区，避免全表扫描；分桶表（如按user_id分100桶）可进一步提升批量写入的并行度。
• 适用场景：离线ETL数据写入（业务库每日全量同步到Hive ODS层）、批量报表数据生成（每日销售汇总表写入）、非实时的大数据量存储（历史日志归档）。

补充注意要点

• 吞吐与实时性权衡：ClickHouse/Kafka适合“高吞吐+低延迟”（延迟<1秒），Doris/HBase适合“高吞吐+准实时”（延迟1-60秒），Hive适合“高吞吐+离线”（延迟小时级），需根据业务延迟需求选型（如实时监控选ClickHouse，每日报表选Hive）；
• 数据格式影响：写入Parquet/ORC列存压缩格式比Text格式吞吐高30%-50%，且节省3-5倍存储，高吞吐场景需优先选择；
• 集群扩展边界：ClickHouse/Kafka通过增加Shard/分区线性提升吞吐（如Kafka分区数从100增至200，吞吐接近翻倍），但需注意“分区/Shard过多导致的管理 overhead”（如Kafka分区数超1000，元数据管理压力增大）；
• 硬件适配：SSD磁盘比HDD更适合高吞吐场景（顺序写速度提升3-5倍），高吞吐集群建议配置SSD；同时需确保网络带宽充足（如万兆网卡，避免网络成为瓶颈——1万条/秒1KB消息需100Mbps带宽，100万条/秒需10Gbps带宽）。

3. 高吞吐写入组件支持高吞吐的原因（LSM、写缓存、多节点等）

考察知识点

高吞吐写入的底层技术原理（IO优化、并行化、异步处理）、核心设计模式（LSM-Tree、写时复制）、分布式扩展逻辑、性能瓶颈突破手段

参考回答

高吞吐写入的核心矛盾是“磁盘随机写性能低”与“高并发写入需求”的冲突，组件通过“转化IO类型、并行化处理、异步解耦”三大技术路径突破瓶颈，具体原理如下：

（1）LSM-Tree（日志结构合并树）：将随机写转化为顺序写

• 问题本质：磁盘的随机写性能极差（HDD随机写IOPS约100-200，SSD约1万-10万），而顺序写性能极高（HDD顺序写约100MB/秒，SSD约500MB/秒-1GB/秒）；传统B+树存储（如MySQL InnoDB）需随机写更新索引（如插入数据时调整B+树节点），无法支撑高吞吐。
• LSM-Tree核心设计：
  • 分层存储架构：
    1. 内存层（MemTable）：写入数据先存入内存（如ClickHouse的MemTable、HBase的MemStore），内存中采用有序数据结构（红黑树、跳表），插入复杂度O(log n)，速度比磁盘快1000倍；
    2. 磁盘层（SSTable/HFile）：当内存层达到阈值（如ClickHouse 64MB、HBase 128MB），异步刷盘为“不可变磁盘文件”（SSTable/HFile），刷盘过程为纯顺序写（无需修改已有数据，仅追加新文件）；
    3. 合并层（Compaction）：后台独立线程定期合并磁盘层的小文件为大文件（如将10个100MB的SSTable合并为1个1GB的SSTable），同时删除过期/重复数据（如更新操作产生的旧数据），优化后续查询性能（减少文件扫描数量）。
  • 如何支撑高吞吐：
    1. 写入时仅操作内存，避免直接与磁盘随机写交互，写入响应时间<1ms（如HBase写入内存后立即返回，无需等待刷盘）；
    2. 刷盘与合并均为异步执行，不阻塞新的写入请求（如ClickHouse刷盘时，新数据仍可写入内存）；
    3. 案例：HBase采用LSM-Tree后，写入吞吐比传统B+树数据库（如MySQL）提升5-10倍，单节点可支撑20万条/秒写入；ClickHouse的MergeTree（LSM变体）进一步优化，单节点吞吐达200万条/秒。
• 典型组件应用：ClickHouse（MergeTree）、HBase（标准LSM-Tree）、RocksDB（嵌入式LSM存储，被Flink/Kafka用于状态存储）。

（2）写缓存（内存缓冲）：减少磁盘IO次数

• 核心逻辑：高吞吐写入的瓶颈不仅是IO速度，还有IO次数（单次IO的“寻址时间”占比高——HDD寻址时间约5-10ms，SSD约0.1-0.5ms，多次小IO的总耗时远大于单次大IO）；通过内存缓存暂存写入数据，批量刷盘可将“多次小IO”转化为“单次大IO”，IO效率提升10-100倍。
• 典型实现方式：
  • 组件级缓存（内置缓存）：
    1. Kafka生产者缓存：默认配置batch.size=16KB（缓存阈值）、linger.ms=10（时间阈值），数据累计到16KB或等待10ms后，批量发送至Broker；若业务可接受稍高延迟（如50ms），将batch.size调至64KB，吞吐可提升3-5倍（如单分区吞吐从10万条/秒增至30万条/秒）；
    2. Doris BE内存缓冲：写入数据先暂存于BE节点的内存缓冲区（默认1GB），累计到阈值后批量刷盘为Segment文件；单次刷盘可写入1GB数据，对比“单条100B数据写入”，IO次数减少1万倍（1GB需1000万条，单次刷盘替代1000万次IO），IO效率提升50倍；
    3. ClickHouse MemTable：内存缓存默认64MB，刷盘时一次性写入64MB数据（顺序写），磁盘IO利用率达90%以上（HDD顺序写速度100MB/秒，64MB仅需0.64秒，无寻址开销）。
  • 应用级缓存（业务层缓存）：
    1. 业务系统写入前，先在本地缓存数据（如用Redis缓存1000条数据后批量写入ClickHouse），减少与存储组件的交互次数；
    2. 案例：某APP埋点系统通过本地缓存（每1000条批量发送），将ClickHouse写入吞吐从10万条/秒提升至50万条/秒，同时减少99%的网络请求（从10万次/秒降至100次/秒）。
• 风险控制与优化：
  • 数据可靠性：缓存数据需配合“WAL（预写日志）”确保不丢失（如HBase写入前先写WAL，MemStore崩溃后可从WAL恢复数据；Kafka Leader副本写入后立即刷盘，避免内存数据丢失）；
  • 缓存阈值配置：阈值过小会导致频繁刷盘（如Doris缓冲设为100MB，会频繁触发刷盘，IO压力集中），过大则会导致刷盘时IO峰值过高（如设为10GB，刷盘时占用全部磁盘带宽），通常建议配置为64MB-1GB（根据内存大小调整）；
  • 缓存淘汰策略：部分组件支持缓存淘汰（如RocksDB的MemTable满后，按LRU淘汰旧数据），但高吞吐场景通常优先保证写入，淘汰策略仅作为应急手段。

（3）多节点/分区并行：分散写入压力

• 核心逻辑：单节点的CPU、内存、磁盘IO、网络带宽均有物理上限（如单节点磁盘IO上限200MB/秒、网络带宽上限1GB/秒），通过“多节点分布式部署+数据分区”，将写入压力分散到多个节点，吞吐随节点数线性扩展（理想情况下，10个节点吞吐=单节点×10）。
• 典型实现方式：
  • 数据分区（横向拆分）：
    1. Kafka分区：Topic按“分区键”（如user_id%100）分为100个分区，每个分区对应一个Broker节点；多生产者可同时写入不同分区（如100个生产者写入100个分区），总吞吐=单分区吞吐×分区数（100个分区×50万条/秒=5000万条/秒）；
    2. Doris分桶：表按“分桶键”（如user_id%100）分100个Bucket，每个Bucket对应一个BE节点；写入时按分桶键哈希路由到对应BE节点，100个BE节点可同时写入，吞吐=单BE吞吐×BE节点数（100个BE×8万条/秒=800万条/秒）；
    3. ClickHouse Shard：分布式表按“Shard键”（如user_id%10）分10个Shard，每个Shard部署在不同节点；写入时按Shard键路由到对应节点，10个节点可并行写入，吞吐=单节点吞吐×Shard数（10个Shard×200万条/秒=2000万条/秒）。
  • 节点负载均衡：
    1. Kafka分区重分配：当某Broker节点负载过高（如分区数过多、磁盘使用率超80%），可通过kafka-reassign-partitions.sh工具将部分分区迁移到其他节点，平衡负载；
    2. HBase Region均衡：HMaster定期检查RegionServer的负载（Region数量、写入量、内存使用率），自动将负载高的Region拆分并迁移到负载低的节点（如某RegionServer有50个Region，其他节点仅20个，HMaster会迁移15个Region过去）；
    3. Doris BE动态扩容：新增BE节点后，通过“数据均衡”工具（ALTER SYSTEM BALANCE DATA）将部分Bucket迁移到新节点，无需停止服务，实现无缝扩容（扩容后吞吐随节点数线性提升）。
• 关键设计原则：
  • 分区键选择：需选择“分布均匀”的字段（如user_id、order_id），避免分区倾斜（如按“地区”分区，某地区数据占比80%，导致对应节点负载过高，吞吐无法提升）；
  • 并行度匹配：分区数/Shard数需匹配节点数（如10个节点，分区数设为100-200，确保每个节点有10-20个分区，充分利用CPU/IO资源——若分区数=节点数，单节点仅1个分区，CPU核心无法充分利用）。

（4）顺序写优化：最大化磁盘IO效率

• 核心逻辑：磁盘的顺序写性能是随机写的10-100倍，高吞吐组件均通过“强制顺序写”设计，避免任何随机写操作，具体优化如下：
  • 日志追加写入：
    1. Kafka：每个分区对应一个日志文件，数据按时间顺序追加写入，无任何随机写（即使是数据删除，也仅标记“墓碑”，不修改原文件，后续合并时删除）；
    2. HBase：MemStore刷盘生成的HFile是顺序写文件，后续合并HFile也是生成新的顺序写文件，不修改原有文件（对比B+树，需随机修改索引节点，效率差10倍）；
  • 避免索引随机更新：
    1. ClickHouse MergeTree：索引信息（稀疏索引）随数据刷盘时一起写入，不单独更新索引文件（传统B+树需随机更新索引节点，如插入数据时调整树结构）；
    2. Doris：前缀索引（按排序键前缀建立，如前36字节）随数据写入时生成，无需后续修改，避免索引随机写（前缀索引查询时直接定位数据块，无需全表扫描）。
• 效果验证：某测试环境中，HDD磁盘随机写吞吐量仅1万条/秒，而顺序写吞吐量可达20万条/秒，提升20倍；SSD磁盘随机写吞吐量10万条/秒，顺序写可达200万条/秒，提升20倍——顺序写是高吞吐的“基石”。

（5）异步处理：解耦写入与后续操作

• 核心逻辑：写入操作仅完成“数据接收与暂存”，将“刷盘、合并、副本同步”等耗时操作异步执行，避免客户端等待，提升并发写入能力（客户端无需等待耗时操作完成，可立即发送下一批数据）。
• 典型实现：
  • 异步刷盘：
    1. ClickHouse：数据写入MemTable后立即返回“成功”，刷盘操作由后台FlushThread异步执行（刷盘耗时1秒，不影响后续写入）；
    2. Kafka：生产者发送数据后，仅需等待Leader副本写入内存（耗时<1ms）即可返回，刷盘由Broker后台线程（log.flush.interval.messages控制）异步执行（刷盘耗时100ms，不阻塞生产者）。
  • 异步合并：
    1. HBase：MemStore刷盘生成小HFile后，合并操作由CompactionThread异步执行（合并10个100MB HFile耗时10秒，不阻塞新的写入）；
    2. ClickHouse：Part文件合并由MergeThread异步执行，合并过程中不影响数据读取与写入（合并时新数据仍可写入新Part）。
  • 异步副本同步：
    1. Kafka：Leader副本接收写入后立即返回，Follower副本通过“拉取”方式异步同步数据（同步延迟<10ms），避免“同步等待”导致的吞吐下降（若同步副本，吞吐会下降3-5倍）；
    2. Doris：BE节点写入数据后，副本同步由后台线程（replica_sync_thread_num控制）异步执行，不阻塞写入响应（同步延迟<50ms，不影响业务）。
• 权衡：异步处理会牺牲“强一致性”（如Kafkaacks=1时，Leader副本崩溃可能导致数据丢失），但可通过“副本机制”（如acks=all）平衡可靠性与吞吐——业务需根据需求选择（如金融场景选acks=all，日志场景选acks=1）。

补充注意要点

• 技术组合效应：高吞吐组件通常结合多种技术（如ClickHouse=MergeTree+Shard并行+异步刷盘），单一技术难以支撑超高吞吐；例如，仅用LSM-Tree的单节点组件，吞吐上限为20万条/秒，结合多节点并行后可提升至2000万条/秒；
• 数据一致性保障：异步/并行写入需配合一致性机制（如WAL、副本、原子提交），避免数据丢失或不一致（如Doris批量导入时，先写临时目录，导入完成后原子替换元数据，确保数据可见性一致——要么全可见，要么全不可见）；
• 硬件依赖：即使组件设计优秀，若硬件瓶颈未突破（如HDD磁盘、百兆网卡），仍无法达到高吞吐；高吞吐场景需配套SSD磁盘（顺序写速度提升3-5倍）、万兆网卡（避免网络瓶颈）、大内存（如128GB+，支撑更大缓存）服务器。

4. ClickHouse不适合的场景（Join、高频微批写入、高QPS等）

考察知识点

ClickHouse的设计局限性、不同场景下的性能瓶颈、与其他组件的场景适配差异、替代方案选型逻辑

参考回答

ClickHouse的核心定位是“单表大数据量快速分析”，受限于“Immutable存储”“简单分布式架构”“弱Join优化”等设计，在以下场景中存在明显短板，不建议作为首选：

（1）复杂多表Join场景（尤其是大表Join）

• 问题表现：
  • 两表均为10亿级数据时，Join查询耗时可达5-30分钟（远超Doris的10-30秒、Spark SQL的5-15分钟）；
  • 易出现数据倾斜（某Join Key对应数据量占比30%），导致单个Task耗时过长（如其他Task耗时10秒，倾斜Task耗时10分钟），拖慢整体查询；
  • 多表Join（3表及以上）时，查询计划优化差，易出现“笛卡尔积”或“全表扫描”，导致查询崩溃（内存溢出）。
• 底层原因：
  • Join实现方式单一且低效：
    1. 仅支持“嵌套循环Join（Nested Loop Join）”和“哈希Join（Hash Join）”，不支持“排序合并Join（Sort-Merge Join）”——Sort-Merge Join适合大表Join（通过排序减少比较次数，内存占用低），而Hash Join需将小表加载到内存构建哈希表，若小表超过内存大小（如10GB小表），会触发磁盘溢出（性能骤降100倍）；
    2. 分布式Join需通过“数据重分布”（Shuffle）实现：将两表按Join Key哈希到相同节点，网络传输量大（如10亿条数据Join，需传输500GB数据），且无自动负载均衡（某节点接收数据量超其他节点5倍，成为瓶颈）。