parquet-optimization
성능을 위한 Parquet 파일 최적화
Parquet 파일은 적절한 최적화 없이는 느려지고 비대해질 수 있습니다. 이 스킬은 Parquet 작업을 사전에 분석하고 압축, 인코딩, 로우 그룹 크기, 통계에 대한 개선 사항을 제안하여 쿼리 성능을 극대화하고 저장 비용을 최소화합니다.
下载技能 ZIP
在 Claude 中上传
前往 设置 → 功能 → 技能 → 上传技能
开启并开始使用
测试它
正在使用“parquet-optimization”。 I'm writing Parquet files with AsyncArrowWriter but didn't set any special properties. What am I missing?
预期结果:
AsyncArrowWriter를 사용하고 있지만 명시적인 WriterProperties를 설정하지 않았네요. 프로덕션 워크로드에서는 다음을 추가하는 것을 고려하세요:
- Compression: ZSTD(3)는 낮은 CPU 오버헤드로 3-4배 압축을 제공합니다
- Row Group Size: 100MB 비압축(100_000_000 rows)은 더 나은 predicate pushdown을 가능하게 합니다
- Statistics: EnabledStatistics::Page는 DataFusion이 관련 없는 로우 그룹을 건너뛰도록 합니다
이 설정은 보통 쿼리 성능을 2-5배 개선하고 저장 비용을 줄입니다.
正在使用“parquet-optimization”。 My Parquet queries scan the entire file even when I only need 3 columns. How do I fix this?
预期结果:
컬럼 프로젝션이 누락되었습니다. ProjectionMask를 사용해 필요한 컬럼만 읽으세요:
```rust
let projection = ProjectionMask::roots(&schema, vec![0, 2, 5]);
let builder = ParquetRecordBatchStreamBuilder::new(reader)
.await?
.with_projection(projection);
```
이는 불필요한 컬럼 읽기를 제거해 와이드 테이블에서 10배 이상의 속도 향상을 제공할 수 있습니다.
安全审计
安全All static findings are false positives. The 37 'external_commands' detections are markdown code formatting backticks in SKILL.md (a documentation file). The 3 'weak cryptographic algorithm' detections are misclassifications of compression algorithms (ZSTD, Snappy) as cryptographic algorithms. This is a documentation-only skill with no executable code.
高风险问题 (1)
中风险问题 (1)
质量评分
你能构建什么
프로덕션 파이프라인을 최적화하는 데이터 엔지니어
데이터 엔지니어가 매일 수백만 레코드를 S3에 쓰는 파이프라인을 구축하고 있습니다. 이 스킬은 최적의 쿼리 성능을 위해 ZSTD 압축, 100MB 로우 그룹, 통계 활성화를 제안합니다.
쿼리 속도를 개선하는 분석가
분석가가 느린 Parquet 쿼리를 발견합니다. 이 스킬은 스캔 비용을 줄이고 응답 시간을 개선하기 위해 누락된 컬럼 프로젝션과 배치 크기 튜닝을 식별합니다.
성능 문제를 디버깅하는 개발자
개발자가 대용량 Parquet 파일을 읽을 때 OOM 오류를 확인합니다. 이 스킬은 스트리밍 패턴, 로우 그룹 필터링, 메모리를 고려한 배치 크기 조정을 권장합니다.
试试这些提示
I'm writing Parquet files using the Rust arrow parquet crate. What settings should I use for production?
Should I use Snappy or ZSTD for my Parquet files? The data is accessed frequently for analytics queries.
My Parquet queries are slow even though I have a powerful cluster. What Parquet-level settings could improve predicate pushdown?
I need to process 50GB Parquet files without running out of memory. What patterns should I use?
最佳实践
- 프로덕션 데이터 레이크의 기본값으로 ZSTD(3) 압축을 사용하세요 - 압축률과 CPU 오버헤드의 균형이 좋습니다
- S3 스캔과 조건절 푸시다운 효율을 최적화하려면 100MB-1GB 로우 그룹을 목표로 하세요
- 스캔 중 관련 없는 로우 그룹을 쿼리 엔진이 건너뛸 수 있도록 페이지 수준 통계를 활성화하세요
避免
- 기본 압축 설정을 사용함 - 접근 패턴에 따라 항상 ZSTD 또는 Snappy를 지정하세요
- 작은 Parquet 파일(<10MB)을 많이 쓰는 것 - 과도한 메타데이터 오버헤드를 만들고 쿼리를 느리게 합니다
- 대용량 파일을 읽을 때 모든 배치를 메모리에 수집하는 것 - 대신 스트리밍 패턴을 사용하세요