data-lake-architect
Diseñar arquitectura de data lake escalable
Los data lakes requieren decisiones arquitectónicas cuidadosas sobre particionamiento, niveles de almacenamiento y diseño de esquema que impactan el rendimiento y el costo. Esta habilidad proporciona orientación experta para construir arquitecturas lakehouse escalables usando patrones y mejores prácticas modernas.
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「data-lake-architect」を使用しています。 We have 500GB of clickstream data per day and need to support queries filtering by date and event type. How should we partition?
期待される結果:
For high-volume clickstream data, I recommend Hive-style date partitioning with event_type as a secondary partition:
```
events/
├── year=2024/
│ ├── month=01/
│ │ ├── day=15/
│ │ │ ├── event_type=click/
│ │ │ │ └── part-*.parquet
│ │ │ ├── event_type=view/
│ │ │ │ └── part-*.parquet
│ │ │ └── event_type=purchase/
│ │ │ └── part-*.parquet
```
This enables efficient partition pruning for your date filters while supporting event_type filtering. Target 100MB-1GB per file after compression.
「data-lake-architect」を使用しています。 Should we use raw Parquet or Apache Iceberg for our new data platform?
期待される結果:
Choose based on your requirements:
**Use raw Parquet when:**
- Append-only workloads
- Stable schema
- Simple single-writer use cases
- Cost-sensitive (fewer metadata files)
**Use Iceberg when:**
- Schema evolves frequently
- Need ACID transactions
- Multiple concurrent writers
- Updates/deletes required
- Time travel for debugging needed
Based on your mention of schema changes and multiple services writing, Iceberg provides better operational characteristics despite higher metadata overhead.
セキュリティ監査
安全All 58 static findings are false positives. This is a documentation-only skill file containing markdown guidance. The flagged 'backticks' are markdown code delimiters, 'weak cryptographic algorithm' alerts misidentify hash partitioning examples as crypto code, and 'system reconnaissance' flags are benign data distribution patterns. No executable code or security risks present.
品質スコア
作れるもの
Diseñando un nuevo data lake desde cero
Los arquitectos que construyen un data lake por primera vez necesitan orientación sobre estructura de carpetas, particionamiento y niveles de datos para evitar rediseños costosos más adelante.
Optimizando el rendimiento de un data lake existente
Los equipos que experimentan consultas lentas o altos costos reciben recomendaciones para mejoras de particionamiento, tamaño de archivos y configuraciones de compresión.
Elegir entre formatos lakehouse
Las organizaciones que evalúan Iceberg, Delta Lake o Hudi necesitan orientación clara sobre compensaciones y criterios de selección para su caso de uso específico.
これらのプロンプトを試す
Estoy configurando un data lake para [caso de uso: p.ej., análisis de clickstream]. Esperamos [volumen] de datos por [período de tiempo] y necesitamos soportar consultas de [tipo de consulta]. ¿Qué diseño de almacenamiento y estrategia de particionamiento recomendarían?
Nuestro data lake tiene problemas de rendimiento con [patrón de consulta específico]. Actualmente particionamos por [estrategia actual] y vemos [síntoma: p.ej., millones de archivos pequeños, operaciones lentas de metadatos]. ¿Cómo deberíamos reestructurar nuestro particionamiento?
Necesitamos elegir un formato de tabla para [tipo de carga de trabajo]. Nuestros requisitos son: [requisito 1], [requisito 2], [requisito 3]. ¿Deberíamos usar Parquet puro o Iceberg? ¿Cuáles son las compensaciones?
Nuestros costos de almacenamiento del data lake son [métrica]. Tenemos [volumen] de [tipos de datos] abarcando [períodos de tiempo]. Recomienden una estrategia de almacenamiento por niveles y retención para reducir costos manteniendo el rendimiento de consultas.
ベストプラクティス
- Usar arquitectura de tres niveles (raw, procesado, curado) para separar preocupaciones y permitir reprocesamiento desde datos fuente
- Apuntar a 100MB-1GB por archivo y particionar por patrones de consulta, no por dimensiones de alta cardinalidad como user_id
- Implementar almacenamiento por niveles (caliente/templado/frío) con compresión apropiada (niveles ZSTD) para equilibrar rendimiento y costo
回避
- Particionar por dimensiones de alta cardinalidad como user_id, lo que crea millones de particiones tiny
- Saltar la compresión para almacenamiento en la nube, lo que aumenta costos de E/S y costos de transferencia de red
- Usar Parquet puro para cargas de trabajo que requieren cambios frecuentes de esquema o transacciones ACID