インフォマティカのCloud Data Profilingでデータプロファイリングしてみた（その２） ～さらにプロファイリングしてみた～

# 1. はじめに
以下の記事では、ほぼデフォルト設定でデータプロファイリングを行いました。

https://qiita.com/tsuru_/items/92f47e0be43196cdd57f

しかし、それでデータ品質の問題が全てわかるかと言うと実際にはそんなことはなくて、まだまだ問題が隠れたままになっていることの方が多いと思います。
そこで、この記事では、プロファイリング結果の見方と、プロファイリング結果からどのようにして問題を検出していくのかを見ていきたいと思います。

# 2. プロファイリング対象のデータについて

前回記事と同じく、CSVファイルの疑似顧客データを使います。
各カラムの想定は次の通りです。

| カラム名 | 想定 |
|:-|:-|
| No | 個人に割り当てられた一意の番号。数字型。 |
| last_name | 名前。文字列型。 |
| first_name | 名字。文字列型。 |
| phone | 電話番号（ハイフン等は含まない）。数値型。 |
| date_of_birth | 生年月日（yyyy/mm/dd形式）。文字列型。 |
| address | 都道府県名（「東京都」「千葉県」「大阪府」のように「都」「県」「府」も含む）。文字列型。 

なお、以下はCSVファイルの抜粋（ヘッダー行1行と、データ行3行）です。

```
No,last_name,first_name,phone,date_of_birth,address
1,紺野,理桜,0984531772,1945/05/04,沖縄県
2,高島,翔,09048227466,1953/12/05,熊本県
3,福元,浩秋,09088285042,1990/11/09,福島県
```

:::note warn
人名や電話番号は全て架空のものです。
また、記事を書くために、このデータには不正なデータをいくつか仕込んでいます。かなりわざとらしいところもありますが、その点はご容赦ください:bow:
:::

# 3. プロファイリング結果の見方と問題検出の流れ

これ以降ではカラムごとに見ていきます。
なお、前回記事で一度プロファイリングを実行しているため、最初にそのプロファイリング結果を見ることから始めます。そして、そのプロファイリング結果に気になるところがある場合は、設定変更して再度プロファイリングを行い、問題を検出していきます。

## 3.1 「No」カラム

サマリビューから確認します。
![2023-01-10-13-14-09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/3d719669-e0f5-9326-1a2b-c89d01b03fb6.png)
「NULLの行のパーセンテージ」がゼロなので、NULLの行はありません。そして、「個別の行のパーセンテージ」が100%で、「重複のある行のパーセンテージ」がゼロなので、値は重複していないことがわかります。

また、データ型を見ると、Integer(4)が100%なので、全て4桁で収まる数値だと判断できます。
![2023-01-10-13-33-28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/5b1dd885-cfda-2252-9163-db4367105abd.png)
念のため、パターンも確認しておきましょう。
![2023-01-10-13-37-11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/e8c001ee-dee1-bd8c-3f64-bc3ab2340665.png)
`9(4)`と`999`は、それぞれ4桁と3桁の数値を意味しています。

:::note info
 9は数字、Xは文字の意味で、`9(4)`は数字4桁のことです。数字も文字も3桁までは`999`や`XXX`と表示されますが、4桁以上は桁数がカッコ内に書かれます。
:::

しかし、`Others`という謎のパターンがあります。
これは**デフォルト設定だと全体で5％未満のパターンは`Others`と表示されてしまう**ためです。今回のプロファイリング対象のCSVファイルは3000件のデータですので、5%というと150件です。まあまあの量ですね。これが`Others`でまとめられてしまうのはちょっと困りそうです。
ですので、全て表示されるように設定を変更します。それでは何パーセントに変更すればいいのでしょうか？ 一概に何パーセントが良いとは言えないのですが、今回は1件しかなくても表示されるようにしたいと思います。3000件中の1件は0.0333...%ですので、それよりも小さい0.01%を設定します。

「スケジュール」タブを開き、少し下にスクロールすると「詳細オプション」に「パターンのしきい値の割合」というところがありますので、ここに0.01を設定します。
![2023-01-16-14-13-28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/8e5dafc3-96b0-61d9-c7d2-cb47c312b464.png)
設定を保存して、再度プロファイリングを実行しましょう。プロファイリング終了後、改めて確認すると以下のようになりました。
![2023-01-10-15-35-24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/303484a7-3fd0-01b6-b05e-364d4d0e81b8.png)
`Others`がなくなって、`99`と`9`が表示されています。これは、それぞれ2桁と1桁の数値ですので、最初から表示されていた`9(4)`と`999`も合わせて考えると、パターンからは1〜4桁の数値であることがわかります。
したがって、このカラムは

:o: NULLなし
:o: 重複なし
:o: 数値型（桁数は1～4）

ということがわかりました。
このカラムは特に問題なさそうです。


## 3.2 「last_name」カラムと「first_name」カラム
この2つのカラムは名前と名字で、同じようなカラムなので同時に見ることにします。

まずはサマリビューです。
![2023-01-10-16-42-46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/ba1a664a-48dc-b6cf-3244-1f8c0021042c.png)
どちらも「NULLの行のパーセンテージ」がゼロなので、NULLの行はありません。また、「個別の行のパーセンテージ」「重複のある行のパーセンテージ」を見ると値の重複があるようですが、同姓や同名が存在することは特におかしなことではないので、値の重複があることは問題ないでしょう。

データ型を確認すると、last_nameが
![2023-01-10-16-57-16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/93dccf86-7237-cee5-92fe-481448c4ec38.png)
となっていて、first_nameは
![2023-01-10-16-58-17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/1a59c222-eeb0-c150-ce9f-cbeec6c6846e.png)
です。
どちらもString型で100%となっているので、これも問題なさそうです。

パターンはどうでしょうか？ last_nameが
![2023-01-10-17-01-36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/5ea2bcee-6924-7f1b-7760-68e734d1bc08.png)
となっていて、first_nameは
![2023-01-10-17-02-51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/645e4fc3-6a75-7b6e-e6d3-c4c5e2a5208d.png)
です。
`X`、`XX`、`XXX`は、それぞれ1文字、2文字、3文字の意味です。それくらいの長さの名前は普通ですので、これらのパターンは問題なさそうです。しかし、それ以外の次の5つのパターンが気になります。

1. `bX`
1. `bXX`
1. `XXb`
1. `XXXb`
1. `X　X`

まず1～4の4つですが、これらに出てくる`b`は半角スペースを意味します。名前の前後に半角スペースのある名前の人はいないはずなので不正なデータです。
5番目の`X　X`は文字と文字の間が広くなっています。わかりにくいですが、これは全角スペースが入っていることを表しています。名前に全角スペースが含まれている人もいないはずなので、これも不正なデータと言えます。
念のため、`X　X`のパターンをドリルダウンして実際のデータを見てみましょう。
![2023-01-13-13-26-56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/2dc5a96f-4143-29a0-b246-b85469692eb4.png)
名前の途中に全角スペースが入っていますが、全角スペースを取り除けば正しい名前になりそうです。

さて、ここまで見て、`bX`や`XXb`のように名前の前後に半角スペースが入っているケースがあるのであれば、名前の前後に全角スペースが入っているケースもありそうな気がしてきました。そんなことを気にしながら、last_nameのパターンを改めてよく見てみると、`XX`が2つあることに気がつきます。
![2023-01-12-15-40-59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/acf7e453-beea-325b-1b64-58cf7b6c093d.png)
同じパターンが別々に表示されるのはおかしいです。そこで、2番目の`XX`をマウスで選択して反転表示させてみます。すると全角スペースが隠れていました。
![2023-01-12-15-42-43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/578fd5e6-523a-c91c-5700-8d64ebba0ce9.png)
注意していないと見逃してしまいそうですが、名前の後ろに全角スペースがついているデータがあることがわかりました。
**半角スペースは`b`と表示してくれるのですが、全角スペースはそのまま表示される**ため、全角スペースはちょっと注意が必要です。

:::note warn
多数のパターンが表示されているときに、全て反転表示させて確認するのはあまり現実的な方法とは言えません。本当はCloud Data Profilingの機能で全角スペースをわかりやすく表示してくれるといいのですが、少なくとも現在は全角スペースがこのように表示されてしまいます。そこで考えられる対策としては、**全角スペースを可視化できるフォントを使用する**ことだと思います。下の画像は、ブラウザのフォントを、全角スペースを可視化可能な[Ricty Diminished](https://rictyfonts.github.io/diminished)に変更して表示したときのものです。全角スペースもわかるように表示されるため、これであれば反転表示させなくても全角スペースを確認できます。
![2023-01-12-17-23-35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/ba31e906-d3cf-10da-d78a-eef9ec4fc6d4.png)
:::

以上から、この2つのカラムは

:o: NULLなし
:o: 重複はあるが問題ない
:o: 文字列型
:x: 半角スペースや全角スペースが含まれるデータが存在する（本来、半角スペースや全角スペースは含まれていはいけない）

ということがわかりました。
半角スペース、全角スペースが含まれているデータが存在することが問題です。

## 3.3 「phone」カラム
サマリビューを確認します。
![2023-01-13-13-38-35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/d33134bf-649f-cef1-ad29-8a4ecfd0a245.png)
「NULLの行のパーセンテージ」がゼロなので、NULLの行はありません。また、「個別の行のパーセンテージ」が100%で、「重複のある行のパーセンテージ」がゼロなので、値は重複していないことがわかります。

データ型を見てみましょう。
![2023-01-13-13-57-21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/4117398b-cfce-45e2-a2fc-f8c1ebd8f296.png)
このカラムはハイフンを含まない電話番号を想定しているため、全て数値であることを期待していましたが、Decimal型、Integer型とされたのは98.83%で100%となっていません。String型では100%なので、1.17%のデータは数値以外の文字を含んでいるようです。

次にパターンです。
![2023-01-13-14-29-14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/3e6bbf04-e01e-3924-c3d4-a193cb08b72e.png)
また`Others`が表示されてしまいました。
「No」カラムを確認しているときにパターンのしきい値を変更したのに、再び`Others`が表示されたのは、今度は出力されたパターンの数が多いからです。**デフォルト設定だとパターンの数が10を超えると`Others`と表示されてしまう**のです。
というわけで、再び設定を変更します。
具体的には、パターンのしきい値を変更したときと同様に、「スケジュール」タブを開き、「詳細オプション」の「最大パターン数」を変更します。値をいくつにするかですが、これも一概にいくつが良いとは言えないため、とりあえず全てのパターンが表示されそうな100と大き目な数を設定してみます。
![2023-01-16-14-16-11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/7731bda2-5391-2c63-7f08-3797b4a06864.png)
設定を保存して、再度プロファイリングを実行します。
すると、以下のように`Others`は表示されなくなりました。
![2023-01-13-15-26-48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/f5f1b922-6a0a-419a-61f0-c98eb290632c.png)
さて、数値以外が含まれているパターンを確認すると次のように9つありました。

1. `999-9(4)-9(4)`
1. `999-999-9(4)`
1. `p999q999-9(4)`
1. `9(4)-99-9(4)`
1. `p9(4)q99-9(4)`
1. `99-9(4)-9(4)`
1. `999-99-9(4)`
1. `p99q9(4)-9(4)`
1. `p9(4)q9-9(4)`
 
全てのパターンにハイフンが入っています。
`9`とハイフンだけで構成される1, 2, 4, 6, 7のパターンでドリルダウンしてみます（下の画像は5レコードだけ抜粋したものです）。ハイフンの入った電話番号になっています。
![2023-01-13-17-11-48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/d80c6624-25d6-c414-9fef-9e38967d482b.png)
3, 5, 8のパターンには`9`とハイフンの他に`p`と`q`という表示があります。`p`は"("で、`q`は")"を意味するので、これらのパターンは数字の他に丸括弧とハイフンが入っていることになります。
こちらもドリルダウンすると丸括弧とハイフンの入った電話番号になっていることが確認できます（下の画像は5レコードだけ抜粋したものです）。
![2023-01-13-17-29-13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/c13f64b9-8390-d6a8-8684-f20697166d33.png)

以上から、このカラムは

:o: NULLなし
:o: 重複なし
:x: 数値型がほとんどだが、文字列型のデータも存在する（本来は全て数値型）
:x: ハイフンと丸括弧が含まれるデータが存在する（本来、数字以外は含まれてはいけない）

ということがわかりました。
数字以外にハイフンと丸括弧が含まれているデータ存在することが問題です。

:::note warn
電話番号を扱う場合、本当は以下のようにまだまだ確認した方が良いと思われることがありますが、やり始めると記事が長くなりすぎてしまうので、この記事では割愛します。
- 電話番号の桁数は正しいか？
- 電話番号はゼロで始まっているか？（ただし、国番号から始まっているデータもあるかもしれないので、ゼロかどうかだけでは判断してはいけない可能性あり）
、、、など
:::

## 3.4「date_of_birth」カラム
サマリビューを確認します。
![2023-01-16-14-39-48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/230fa1b3-d4a9-8936-14cf-20ef1018fba5.png)
「NULLの行のパーセンテージ」が0.7%となっていてNULLの行があることがわかります。そして、「個別の行のパーセンテージ」が100%でないですが、同じ誕生日の人がいてもおかしくないので、これは問題ありません。
ここで気になるのは最大値です。"9999/12/31"となっています。これは明らかに不正な値です。

データ型を確認します。
![2023-01-16-14-47-56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/8816a8c6-e987-5971-0088-b9541b4bf601.png)
yyyy/mm/ddという形式で"/"が含まれているため、String型で100%となっているのは問題なさそうです。

パターンはどうでしょうか？
![2023-01-16-14-49-32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/4a6ed980-6da2-fc28-3e2f-0d1d87cf386e.png)
NULL以外のデータは全てyyyy/mm/dd形式となっているようです。こちらも問題ありません。

データ型やパターンは問題ないことがわかりましたが、最初のサマリビューで気になった"9999/12/31"のような不正なデータが他にも存在するのか、という疑問が残ります。
このようなデータを検出するために、Cloud Data Qualityの[ルール仕様](https://docs.informatica.com/ja_jp/data-quality-cloud/cloud-data-quality/current-version/_rule-specification-assets_cloud-data-quality_current-version_ditamap/GUID-7A11E423-6751-40DC-BB0A-97D1A4C45CA7.html)を利用することにします。ルール仕様は簡単に言うと、データがある条件を満たしたときに実行するアクションを定義したもの（プログラムで言うところの `if 〜 then 〜` を定義したもの）で、プロファイリングするときのルールとして利用することができます。

ルール仕様はマイサービスで「データ品質」を開き、続けて「新規...」、「ルール仕様」をクリックすることで作成できます。
![2023-01-19-16-51-00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/d20dc9f4-bafc-23fe-f438-ba7e53b18a33.png)

ここでは次のような出力を行うルール仕様を作成します。

- NULLの場合 :arrow_right: 'NULL'と出力
- NULLではなく現在日時よりも先の日付 :arrow_right: '未来日'と出力
- 上記以外 :arrow_right: '有効日付'と出力

実際のルール仕様の画面では以下のように設定します。
![2023-01-17-15-01-55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/4564aa77-219e-2710-0bba-43ad4b7e537f.png)
ルール仕様が作成できたら、再びプロファイリングの画面に戻り、作成したルール仕様を「ルール」タブで「date_of_birth」カラムに設定します。
![2023-01-17-16-34-44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/ccf08425-086a-7a9f-ef2b-0cd2acd34dc1.png)
設定後、保存を行い、プロファイリングを再実行します。
するとプロファイリング結果に先ほど設定したルールの行が追加されています。
![2023-01-25-14-24-29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/61ec5421-9404-ae91-f571-160faaebf764.png)
追加されたルール仕様の行をクリックして値を確認します。
![2023-01-17-16-47-39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/ec72fa08-52aa-3ab9-b343-aa396f406e3c.png)
「未来日」のデータが5件ありました。「未来日」でドリルダウンしてみましょう。
![2023-01-17-16-48-45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/8acc0e51-a64b-85f2-99fb-6db00bd46e1c.png)
たしかに未来の日付が入っていることが確認できます。

以上から、このカラムは

:x: NULLあり
:o: 重複はあるが問題ない
:o: 文字列型
:o: NULLでないデータは全てyyyy/mm/dd形式
:x: 未来の日付が入っているデータが存在する

ということがわかりました。
NULLがあること、未来日のデータが存在することが問題です。

## 3.5 「address」カラム

サマリビューから確認します。
![2023-01-25-14-26-32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/3ff3f07f-2610-3428-443a-378692407d0e.png)
「NULLの行のパーセンテージ」がゼロなので、NULLの行はありません。また、「重複のある行のパーセンテージ」が98.4%と高いですが、このカラムは都道府県名が格納されているため重複があることは特に問題ありません。
ここで気になるのは最小値で、"XXX"と明らかに不正な値になっています。

データ型を確認します。
![2023-01-17-17-19-54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/d0785f7b-a4e7-aa3d-25a6-adce436e5dd6.png)
`String(4)`で100%とあるので4文字以内の文字列型となっているようです。都道府県名は4文字以内（「神奈川県」のように「県」も含むと最大で4文字）のため、特におかしなところはありません。

続いてパターンです。
![2023-01-17-17-20-38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/e0863804-76f4-0617-8bad-f5ae753123ba.png)
3文字、もしくは4文字であることがわかります。これも特におかしなところはありません。

そうなると最初のサマリビューで確認できた"XXX"が気になります。このようなデータは他にはないか確認する必要があります。
そのために、今回もルール仕様を使用します。データが正しい都道府県名か確認すればいいのですが、以下のように都道府県名を一つずつ確認するようなルールを47行書くのは少々大変です。
![2023-01-30-15-05-49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/0c720e47-a3de-2923-4c9b-8723e4e98850.png)
したがって、ここでは[ディクショナリ](https://docs.informatica.com/ja_jp/data-quality-cloud/cloud-data-quality/current-version/_dictionaries_cloud-data-quality_current-version_ditamap/GUID-2CE80592-F1BE-444E-8E82-FDCB15243335.html)を利用します。

ディクショナリはマイサービスで「データ品質」を開き、続けて「新規...」、「ディクショナリ」をクリックすることで作成できます。
![2023-01-25-15-21-12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/42bc5c28-3093-b417-1799-3bd89becd52e.png)
ディクショナリの内容は都道府県名を入力するだけです。CSVファイルを用意してインポートさせて作成することも可能です。
![2023-01-25-15-28-33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/f1d763e9-a153-c5c2-de4f-70a3cdd14975.png)
ディクショナリが作成できたら、このディクショナリを使ったルール仕様を作成します。
ルール仕様では、 入力データがディクショナリに含まれていたらVALID、含まれていなければINVALIDと出力するロジックを設定します。
![2023-01-25-16-03-46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/6ad8351f-95c9-3365-7b44-6b69393e1c3b.png)
プロファイリングの定義で、「address」カラムに対してルール仕様を設定します。
![2023-01-25-16-07-39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/7bf0005c-c970-6c83-080c-001305b020a2.png)
設定を保存して、プロファイリングを再実行すると、ルール仕様の行が追加されています。
![2023-01-25-16-12-43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/4c4cc0ad-144c-c495-0bf0-42ea5001914d.png)
追加されたルール仕様の行をクリックして値を確認します。
![2023-01-25-16-14-17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/0f79b98c-609e-00ab-a397-ecee19b91296.png)
INVALIDのデータが8個ありますので、ドリルダウンして確認します。
![2023-01-25-16-16-54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3025212/2ac80e41-bf9c-59ee-5bab-c216688664dd.png)
サマリビューで確認できた"XXX"の他に"あああ"というデータもありました。

以上から、このカラムは

:o: NULLなし
:o: 重複はあるが問題ない
:o: 文字列型（桁数は3もしくは4）
:x: 都道府県名ではない値（具体的には"XXX"と"あああ"）が入っているデータが存在する

ということがわかりました。
都道府県名以外のデータが含まれているデータが存在することが問題です。

## 3.6 全カラムのまとめ

全カラムの確認結果です。

| カラム名 | プロファイリング結果 |
|:-|:-|
| No  | :o: NULLなし<br> :o: 重複なし<br> :o: 数値型（桁数は1～4）  |
| last_name<br>first_name  | :o: NULLなし<br> :o: 重複はあるが問題ない<br> :o: 文字列型<br>:x: 半角スペースや全角スペースが含まれるデータが存在する（本来、半角スペース・全角スペースは含まれていはいけない）  |
| phone  | :o: NULLなし<br> :o: 重複なし<br> :x: 数値型がほとんどだが、文字列型のデータも存在する（本来は全て数値型）<br> :x: ハイフンと丸括弧が含まれるデータが存在する（本来、数字以外は含まれてはいけない）  |
| date_of_birth  | :x: NULLあり<br>:o: 重複はあるが問題ない<br>:o: 文字列型<br>:o: NULLでないデータは全てyyyy/mm/dd形式<br>:x: 未来の日付が入っているデータが存在する |
| address  | :o: NULLなし<br>:o: 重複はあるが問題ない<br>:o: 文字列型（桁数は3もしくは4）<br>:x: 都道府県名ではない値（具体的には"XXX"と"あああ"）が入っているデータが存在する  |

デフォルト設定でプロファイリングしただけでは検出できない問題もありました。プロファイリングを何度も行うのは大変ですが、データの問題を検出するためには必要な作業だと言えます。

# 4. 最後に

プロファイリングを繰り返しながらデータの問題を検出してみました。実際の業務ではもっと複雑な問題が隠れていることが多いとは思いますが、どのようにプロファイリングを進めていくのか雰囲気だけでも感じていただければ幸いです。
また、この記事を読んで、自分の持っているデータが気になった場合は、是非プロファイリングしてみてください！

（2023/03/23 追記）
続編を書きました。

https://qiita.com/tsuru_/items/0bfa8779d854606ba3df


# 仲間募集中！

[NTTデータ Data&Intelligence事業部](https://enterprise-aiiot.nttdata.com/) では、以下の職種を募集しています。

<details>
<summary>1. 「クラウド技術を活用したデータ分析プラットフォームの開発・構築(ITアーキテクト/クラウドエンジニア)」の募集</summary>
クラウド/プラットフォーム技術の知見に基づき、ITアーキテクトまたはPMとして、DWH、BI、ETL領域における、ソリューション開発の推進や、コンサルティング工程のシステムグランドデザイン策定時におけるアーキテクト観点からの検討を行う人材を募集しています。

https://nttdata.jposting.net/u/job.phtml?job_code=808
</details>

<details>
<summary>2. AI／データ活用を実践する「クラウド・ソリューションアーキテクト」</summary>
AI／データ活用を実践する「クラウド・ソリューションアーキテクト」として、クラウド先進テクノロジーを積極活用し、お客様のビジネス価値創出活動を実践。AI／データ活用の基本構想立案コンサルティングからクラウドプラットフォーム提供・活用を支援しています。お客様のAI・データ活用を支援するクラウド・ソリューション提案、アーキテクチャ設計・構築・継続活用支援（フルマネージドサービス提供）、および最新クラウドサービスに関する調査・検証で、クラウド分析基盤ソリューションのメニュー拡充を実施する人材を募集します。

https://nttdata.jposting.net/u/job.phtml?job_code=807
</details>

また、取り扱う主なソリューションについては、以下のページも参照ください。

# ソリューション紹介

<details>
<summary>1. NTTデータとInformaticaについて</summary>
データ連携や処理方式を専門領域として10年以上取り組んできたプロ集団であるNTTデータは、データマネジメント領域でグローバルでの高い評価を得ているInformatica社とパートナーシップを結び、サービス強化を推進しています。

https://enterprise-aiiot.nttdata.com/service/informatica
</details>

<details>
<summary>2. Trusted Data Foundationについて</summary>
～データ資産を分析活用するための環境をオールインワンで提供するソリューション～

https://enterprise-aiiot.nttdata.com/tdf/
最新のクラウド技術を採用して弊社が独自に設計したリファレンスアーキテクチャ（Datalake+DWH+AI/BI）を顧客要件に合わせてカスタマイズして提供します。
可視化、機械学習、DeepLearningなどデータ資産を分析活用するための環境がオールインワンで用意されており、これまでとは別次元の量と質のデータを用いてアジリティ高くDX推進を実現できます。
</details>