【Golang】CSV、TSV、LTSV、Parquet、Excel 読み込み時に、前処理とバリデーションを行う nao1215/fileprep を作った話

nao1215/fileprep（前処理ライブラリ） を開発した理由

理由は、データが汚れているからです。

私は、過去に nao1215/csv ライブラリ（パブリックアーカイブ済み） を開発していました。nao1215/csv は、struct tag でバリデーションルールを指定すると、CSV ファイルの読込み後に「どの行のどのカラムが不正値なのか」を教えてくれます。

nao1215/csv を開発した理由は、「非エンジニアが渡してくる CSV データに誤りが多すぎるので、読み込み時にバリデーションする必要がある」と思い立ったのが、キッカケです。nao1215/csv を作成してから1年以上が経ち、当時と状況が変わってきました。

• 複数の表形式ファイルを扱う nao1215/filesql を開発
• 機械学習を学び、前処理（データ整形）の重要性に気づく

さらに、nao1215/filesql のバリデーション機能の弱さのせいで、会社で別プロジェクトメンバが戸惑っている姿を見て、「nao1215/filesql と統合でき、かつ前処理とバリデーションができるライブラリを作ろう」と思い立ちました。

nao1215/filesql に機能追加しなかった理由は、「データ整形とバリデーションだけしたい需要もあると考えたから」および「nao1215/filesql が巨大なライブラリになることを避けたから」です。

file + preprocess = fileprep とは

nao1215/fileprep は、struct tag を指定した構造体を用いて、ファイル読み込みを行うライブラリです。ファイル読み込み時に、前処理とバリデーションを行います。

主に、以下の特徴を持ちます。

• データ整形用の prep タグ
• データバリデーション用の validate タグ
• カラム名を指定する name タグ（通常、カラム名は自動推定）
• CSV、TSV、LTSV、Parquet、Excel および gzip, bzip2, xz, zstd をサポート
• 前処理／バリデーション時の入力は io.Reader、出力は前処理後の io.Reader、構造体スライス、前処理エラー／バリデーションエラー

io.Reader として出力することで、nao1215/filesql にそのまま受け渡せるメリットがあります。過去に作成した nao1215/csv は、読み込み結果を構造体スライスとして返していたので、nao1215/filesql にそのまま渡せませんでした。とは言え、nao1215/filesql を使わないユーザーもいる筈なので、構造体スライスを返す仕様も踏襲しました。

fileprep サンプルコード

実際にコードを見た方が理解しやすいと思われるので、以下に示します。

このサンプルコードは、前処理として、Name は前後にある空白を除去し、Email は空白除去と小文字化をしています。構造体フィールド名をスネークケースに変換したものが、カラム名となります。カラム名を明示したい場合はname タグを利用しますが、今回のサンプルでは登場しません。

package main

import (
    "fmt"
    "os"
    "strings"

    "github.com/nao1215/fileprep"
)

type User struct {
    Name  string `prep:"trim" validate:"required"`
    Email string `prep:"trim,lowercase"`
    Age   string
}

func main() {
    csvData := `name,email,age
  John Doe  ,JOHN@EXAMPLE.COM,30
Jane Smith,jane@example.com,25
`

    processor := fileprep.NewProcessor(fileprep.FileTypeCSV)
    var users []User

    // reader（返り値）: 前処理後の io.Reader
    // result（返り値）: 前処理とバリデーションの結果
    // users（引数）: processor.Process() 後は、前処理後のデータが追加されている。
    reader, result, err := processor.Process(strings.NewReader(csvData), &users)
    if err != nil {
        fmt.Printf("Error: %v\n", err)
        return
    }

    fmt.Printf("Processed %d rows, %d valid\n", result.RowCount, result.ValidRowCount)

    for _, user := range users {
        fmt.Printf("Name: %q, Email: %q\n", user.Name, user.Email)
    }
}

Output:

Processed 2 rows, 2 valid
Name: "John Doe", Email: "john@example.com"
Name: "Jane Smith", Email: "jane@example.com"

タグ一覧

go-playground/validatorを参考に、validate タグを設計しています。なお、バリデーションロジックは一致していません。

タグのカスタマイズ性は、意図的に持たせていません。つまり、ユーザー指定のタグ名に、ユーザー指定の関数を定義するような機能はありません。そこまで複雑な前処理とバリデーションが必要な場合、nao1215/fileprep が適していない気がします。

前処理タグ (prep)

基本的な前処理

文字列変換

文字フィルタリング

パディング

高度な前処理

バリデーションタグ (validate)

基本的なバリデータ

文字種バリデータ

数値比較バリデータ

文字列バリデータ

文字列内容バリデータ

フォーマットバリデータ

ネットワークバリデータ

クロスフィールドバリデータ

最後に：鉄は熱いうちに打つ

nao1215/fileprep の発想に辿り着いたのは、23時でした。

ワンオペが続くので、開発タイミングに迷いました。しかし、平日にゆるゆる開発すると、次第にモチベーションが失せていくので、休日での開発を決意しました。朝方までカタカタ作業していました。昼間、吐き気と疲労感に悩まされました。でも、リリースまでこじつけられて良かったです。

filesql、fileprep のような file + α 系のライブラリ、圧倒的に名前が決めやすいので、これからも増やしていく可能性があります。最近は、「ライブラリ API は可能な限りシンプルに」「標準パッケージ、標準機能に寄せる」と考えながら、設計していますが……あまりフィードバックが得られていません。今回は、struct tag という概念は分かりやすかったと思いますが、各タグの使い方は理解しづらいだろうなと推測しています。