【ITニュース解説】🛡️ Data quality, SQL, duckdb and http_client on CI🦆

システム開発では、高品質なデータが非常に重要だ。誤ったデータや古いデータがシステムに混入すると、予期せぬエラーや誤った結果につながり、ビジネスに大きな影響を与える可能性がある。そのため、データがシステムに取り込まれる前や、システム内で利用される際に、その品質をしっかりと検証する仕組みが必要となる。

このデータ品質検証を、開発プロセスの中で自動的に行うのが継続的インテグレーション（CI）という考え方だ。CIとは、開発者がコードの変更を頻繁に共有リポジトリに統合し、そのたびに自動的にビルドやテストを実行することで、早期に問題を発見し、開発効率を高める手法を指す。このCIのパイプラインの中にデータ検証のステップを組み込むことで、データの品質を常に高いレベルで保つことができる。

しかし、検証すべきデータがインターネット上の外部リソースに依存している場合、話は少し複雑になる。例えば、システムがGitHubユーザーのアカウント情報を管理しているとして、そのユーザー名が実際にGitHub上に存在するかどうかを検証したい場合を考えてみよう。単にユーザー名の形式が正しいかを確認するだけでなく、そのユーザー名が有効なGitHubアカウントとして実在するかどうかを、GitHubのウェブサイトにアクセスして確認する必要がある。このようなウェブリソースに依存するデータの検証は、従来のデータベースの機能だけでは難しい課題だった。

この課題を解決するために、DuckDBとhttp_client拡張、そしてGitHub Actionsというツールが組み合わせて利用できる。

まず、DuckDBとは、非常に高速で軽量な分析用データベースだ。通常のデータベースとは異なり、サーバーを立てる必要がなく、アプリケーションに組み込んで使うことができるインメモリデータベースの一種だ。SQLというデータベースを操作するための標準的な言語を使ってデータを扱うことができ、手軽に利用できるのが特徴だ。

次に、http_client拡張とは、このDuckDBの機能を拡張するプラグインのようなものだ。通常、SQLはデータベース内のデータを操作するための言語だが、このhttp_client拡張をDuckDBに導入すると、SQLコマンドから直接インターネット上のウェブサイトにHTTPリクエストを送信し、その結果を取得できるようになる。これにより、データベースに格納された情報（今回の例ではGitHubユーザー名）を使って、対応するウェブサイト（GitHub）にアクセスし、そのウェブサイトの応答（HTTPステータスコードなど）をデータベース内で確認する、という一連の処理が可能になるのだ。

そして、GitHub Actionsは、GitHub上でコードのリポジトリと連携して、様々な自動化されたタスクを実行するための機能だ。これを使えば、例えばコードが変更されるたびに自動でテストを実行したり、アプリケーションをデプロイしたりするCIパイプラインを簡単に構築できる。このGitHub Actionsの仕組みの中に、DuckDBとhttp_client拡張を使ったデータ検証のステップを組み込むことで、ウェブリソースに依存するデータ品質のチェックを自動化できる。

具体的な手順を見てみよう。 まず、DuckDB上でhttp_client拡張をインストールし、利用可能にする。これはINSTALL http_client FROM community;とLOAD http_client;という簡単なSQLコマンドで実行できる。

次に、検証したいGitHubユーザー名を含むテーブルを作成する。例えば、person_gh_memberというテーブルに、社員のアカウント名と対応するGitHubのメンバー名を格納する。このテーブルには、存在するGitHubユーザー名と、意図的に間違ったGitHubユーザー名（タイプミスを想定）の両方を挿入しておく。

そして、このテーブルのデータを使って、各GitHubユーザー名が有効かどうかを確認するビューを作成する。ビューとは、実際のテーブルのデータに基づいて、仮想的なテーブルのように振る舞うもので、複雑なクエリの結果をあたかもテーブルのように扱える。このビューでは、GitHubのメンバー名から完全なGitHubのプロフィールページのURLを作成し、http_client拡張のhttp_get関数を使ってそのURLにアクセスする。http_get関数は、ウェブサイトへのリクエストのステータスコードを含む結果を返す。ウェブサイトへのアクセスが成功し、ページが正常に表示された場合、HTTPステータスコードは通常「200」となる。もしページが存在しない、またはアクセスに問題がある場合は、例えば「404」（ページが見つからない）のような別のステータスコードが返される。

このビューを参照することで、ステータスコードが「200」ではない行を簡単に特定できる。これによって、タイプミスなどで存在しないGitHubユーザー名がデータに含まれていることを自動的に検出できるのだ。この検出された問題のあるデータを「lint」（リンティング、コードやデータの品質チェック）するという。

さらに進んだ方法として、CHECK制約を持つ新しいテーブルを作成することもできる。CHECK制約とは、データベースのテーブルにデータを挿入または更新する際に、特定の条件を満たしているかどうかを自動的に検証する仕組みだ。例えば、lint_gh_handleというテーブルを作成し、そこにgh_status integer check (gh_status = 200)という制約を追加する。こうすることで、GitHubのステータスコードが200ではないデータはこのテーブルに挿入できなくなる。既存のperson_gh_memberテーブルのデータを検証しながら、このlint_gh_handleテーブルに挿入していくことで、自動的に検証済みで高品質なGitHubユーザー名データだけを蓄積できる。

このように、DuckDBとhttp_client拡張、そしてCIパイプラインに組み込むGitHub Actionsを組み合わせることで、ウェブリソースに依存するデータの品質検証を効率的かつ自動的に行い、システム全体のデータ品質を向上させることができる。これは、システムエンジニアが直面するデータ管理の課題に対し、強力な解決策を提供するものだと言える。