Compétences data-engineering-data-pipeline
📦

data-engineering-data-pipeline

Risque faible

スケーラブルなデータパイプラインを構築

本番環境向けデータパイプラインの設計は複雑でエラーが発生しやすいものです。このスキルでは、ETL、ストリーミング、レイクハウスシステムに対する実証済みのアーキテクチャパターンと実装ガイダンスを提供します。

Prend en charge: Claude Codex Code(CC)
📊 71 Adéquat
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

Activez et commencez à utiliser

Tester

Utilisation de "data-engineering-data-pipeline". MySQLからSnowflakeへの日次顧客データ同期用のバッチパイプラインを設計

Résultat attendu:

アーキテクチャ：増分ロードを使用するELTパターン。コンポーネント：(1) ウォーターマークカラム'updated_at'を使用して抽出、(2) S3ステージングに生データをロード、(3) dbtでSnowflake内で変換、(4) dbtテストで検証、(5) Slack経由で障害時にアラート。主な考慮事項：遅れて到着するデータの処理、再試行ロジックの実装、行数の変動の監視。

Utilisation de "data-engineering-data-pipeline". ストリーミングパイプラインでスキーマ進化をどのように処理しますか？

Résultat attendu:

ストラテジー：互換性チェック付きのスキーマレジストリを使用。追加変更の場合はデフォルト値を使用。破壊的変更の場合は、移行中にデュアルライトを実装。ツール：Kafka用のConfluent Schema Registry、mergeSchemaオプションを使用したDelta Lakeスキーマ進化。デプロイ前に常に後方互換性をテスト。

Audit de sécurité

Risque faible
v1 • 2/24/2026

All static analyzer findings are false positives. The skill is documentation-only, providing architectural guidance and educational code examples. No executable code, external commands, or security risks detected. Safe for publication.

1
Fichiers analysés
204
Lignes analysées
3
résultats
1
Total des audits
Problèmes à risque faible (3)
SKILL.md:3SKILL.md:28SKILL.md:39SKILL.md:42SKILL.md:94SKILL.md:167
Static Analyzer False Positives - Weak Cryptographic Algorithm
Static analyzer flagged lines 3, 28, 39, 42, 94, and 167 as containing weak cryptographic algorithms. Review confirms these are false positives - the flagged lines contain architectural terms (ETL/ELT, Lambda, Kappa) and documentation headers, not cryptographic code.
SKILL.md:124-159
Static Analyzer False Positive - External Command Execution
Static analyzer flagged line 124 as Ruby/shell backtick execution. Review confirms this is a Python code example showing batch ingestion patterns, not shell command execution.
SKILL.md:49SKILL.md:116SKILL.md:184
Static Analyzer False Positives - Reconnaissance Patterns
Static analyzer flagged lines 49, 116, and 184 as system/network reconnaissance. Review confirms these are data pipeline terminology (metadata tracking fields, partitioning strategies, monitoring alerts), not reconnaissance activity.
Audité par: claude

Score de qualité

38
Architecture
100
Maintenabilité
87
Contenu
50
Communauté
84
Sécurité
91
Conformité aux spécifications

Ce que vous pouvez construire

新規パイプ��インアーキテクチャの設計

スプレッドシートからモダンなデータスタックへ移行するスタートアップ向けに、ゼロから完全なデータパイプラインを設計します。

ストリーミング移行ストラテジー

Kafkaとストリーミング処理フレームワークを使用して、既存のバッチパイプラインをリアルタイムストリーミングアーキテクチャに変換します。

データ品質フレームワークの実装

Great Expectationsとdbtテストを使用して、自動アラート機能付きの包括的なデータ品質チェックを実装します。

Essayez ces prompts

基本的なパイプライン設計 
PostgreSQLから毎日データを抽出し、変換して、データウェアハウスにロードするデータパイプラインを構築する必要があります。どのアーキテクチャを使用すべきで、主要なコンポーネントは何ですか？
ストリーミングアーキテクチャの選択 
アプリケーションから大量のイベントデータが生成されており、ほぼリアルタイムの分析が必要です。1分間に100万イベントのユースケースで、LambdaアーキテクチャとKappaアーキテクチャを比較してください。
データ品質の実装 
Great Expectationsを使用してオーダーテーブルのデータ品質チェックを実装する方法を教えてください。オーダーIDの一意性、顧客IDの非NULL、正のオーダー金額を検証する必要がありま��。
コスト最適化の���ビュー 
月次のデータパイプラインコストが2倍になりました。アーキテクチャをレビューし、SLAを維持しながらコストを削減する具体的な推奨事項を提供してください。現在のスタック：Airflow、Spark、S3、Redshift。

Bonnes pratiques

  • アーキテクチャパターンを選択する前に、データソース、データ量、レイテンシ要件、ターゲットシステムを評価
  • データセット全体を再処理しないように、ウォーターマークカラムを使用した増分処理を実装
  • 各パイプラインステージでデータ品質ゲートを追加し、検証失敗時に自動アラートを設定

Éviter

  • 特定のデータ量と速度要件に適合させずに本番環境のパターンをコピー
  • ビジネスニーズとチームの能力ではなくトレンドに基づいてアーキテクチャを選択
  • 監視、可観測性、運用手順より機能を優先

Foire aux questions

リアルタイム分析にLambdaアーキテクチャとKappaアーキテクチャのどちらを使用すべきですか？
複雑な集計を行うバッチの正確性と低レイテンシのビューの両方が必要な場合はLambdaを選択してください。リプレイ機能で十分な、より単純なストリームのみの処理の場合はKappaを選択してください。Kappaは運用の複雑さを軽減できますが、堅牢なストリーミング処理インフラストラクチャが必要です。
ストリーミングパイプラインで遅れて到着するデータをどのように処理しますか？
遅延のしきい値を定義するために、ウォーターマークを使用したイベント時間処理を使用してください。再処理可能な遅延データ用にサイド出力を実装します。重要なデータの場合、見逃したレコードを修正するために定期的に実行されるバッチ修正ジョブを維持してください。
データレイクストレージにどのファイル形式を使用すべきですか？
圧縮と述語プッシュダウンを持つ列指向分析ワークロードにはParquetを使用してください。Delta LakeまたはIcebergは、Parquetの上にACIDトランザクション、スキーマ進化、タイムトラベルを追加します。トランザクションとメタデータ管理の必要性に基づいて選択してください。
変換にdbtとSparkのどちらを使用すべきですか？
データウェアハウスでSQLベースの変換を行うには、組み込みのテストとドキュメントメントを備えたdbtを使用してください。大規模なデータ処理、Python/Scalaを必要とする複雑な変換、またはウェアハウスにロードする前にデータレイクで作業する場合にはSparkを使用してください。
ストリーミングで正確に1回の処理をどのように実現しますか？
べき等シンクとトランザクション処理を組み合わせてください。アトミックライトにはKafkaトランザクションを使用し、復旧にはチェックポイント状態を使用し、べき等操作を設計してください。データベースの場合は、重複を防ぐために一意制約付きのアップサート操作を使用してください。
データパイプラインに不可欠な監視メトリクスは何ですか？
追跡項目：ステージごとの処理済みおよび失敗したレコード、エンドツーエンドのレイテンシ、データの鮮度、パイプライン成功率、リソース利用率。SLA違反、エラーレートの急増、データ品質の失敗に対してアラートを設定。障害が発生する前に容量問題を特定するためにトレンドを監視。

Détails du développeur

Auteur

sickn33

Licence

MIT

Dépôt

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/data-engineering-data-pipeline

Réf

main

Structure de fichiers

📄 SKILL.md