Koheesio - Nikeのデータパイプライン構築向けフレームワークをオープンソース化

• 効率的なデータパイプラインを構築するためのPythonフレームワーク
• モジュール化とコラボレーションを促進し、シンプルで再利用可能なコンポーネントによって複雑なパイプラインを作れるようにする
• 複数のデータ処理ライブラリやフレームワークとシームレスに連携できるよう設計されている
• Pydanticを使用し、強力な型チェック、データ検証、設定管理を提供する
• 十分にテストされたコードと豊富な機能セットにより、予測可能なパイプライン実行を保証する

Koheesioと他ライブラリの違い

• データパイプライン、PySpark統合、データ変換、ETL処理、データ検証、および大規模データ処理に特化した設計
• あらゆる種類のデータ処理タスク向けにReader、Writer、Transformation機能を提供
• データエンジニアリングコミュニティ内でのコラボレーションとイノベーションを促進する

Koheesioの中核コンポーネント

• Step: Koheesioの基本作業単位で、データパイプラインにおける単一のタスクを表す。入力を受け取り、出力を生成する
• Context: タスクの環境を設定する構成クラス。タスク間で変数を共有し、環境に応じてタスクの動作を調整できる
• Logger: さまざまなレベルでメッセージを記録するクラス

[xguru]

Hacker Newsのコメント

• Nikeのデータエンジニアリングが実際にはどのようなものなのか気になる。LinkedInのプロフィールが原因で、低賃金の契約職の提案がよく届く。これらの役割は米国内で経験のある人を対象にしているが、報酬が低い。これらの役割は詐欺の可能性もある。
• このツールは、経験の浅い開発者が多い環境では役立つかもしれない。2〜3人の開発者がツールを作り、より大きなチームが単純なETL作業を行う。ツールチームには、新しい要件に対応しなければならない負担がある。
• 強い型付けはデータエンジニアリングの問題にとって妨げになる。動的言語はコードの複雑さや保守負担を減らすのに役立つ。型フレームワークに固執するのは、業界経験というより学術的経験に基づいている。
• ETL、Spark、Stormなどを扱ってきたが、このライブラリの価値提案が理解できない。データエンジニアリングの専門家ではないが、このツールの有用性には期待していた。
• このツールが何なのか、なぜ使うべきなのかについて、より良い説明が必要だ。リンクを参照。
• 数週間前にApache Beamを使ってデータパイプラインを書いた。Koheesioはいくつかの機能を共有しているが、Apache Beamのほうが優れている。
• Luigiに似ている。よい！
• CloudQueryを確認してみることを勧める。ArrowベースのELTフレームワークだ。（作者本人）
• Koheesioは他のライブラリとは競合しないと言っているが、実際には競合している。ワークフローオーケストレーションは成熟したカテゴリだ。Pythonを使っていることは大きな利点ではない。
• dltライブラリを見たことがあるのか気になる。Pythonで使いやすいELを提供している。Koheesioとdltの違い、および相互補完の可能性が気になる。