[C01] DECIMAL(38,10) を超える精度の数値が silent に桁落ちする(エラー無しでデータが丸まる)
再現条件
- 数値カラム(物理計測値など)に 11 桁以上の小数を含む値が入った CSV
- Admin UI から
analyze → apply
観測された挙動
- analyze 時に Bedrock は該当カラムを
DECIMAL(38,10) と推定する(DDL に固定された 6 種の型のうちの 1 つ)
- apply / COPY は成功し、Admin UI も
SUCCEEDED 表示
- しかし 11 桁目以降の小数は silent に切り捨てられる
- ロード後の件数チェックだけでは気づけない(行数は一致)
実測 (C01 の sensor テーブル)
生成側:
if bad_precision:
torque = f"{rng.uniform(10, 20):.15f}" # 例: "15.123456789012345"
ロード後:
select max(length(torque_nm::varchar)), max(torque_nm), min(torque_nm) from sensor;
-- max_len = 13 (例: "19.9998340473")
-- max_t = 19.9998340473
-- min_t = 10.0000342029
元は小数 15 桁で保存したのに、DB 上は 10 桁までしか残っていない。
原因(設計)
- DDL が
DECIMAL(38,10) 固定(lambda/redshiftinitworkflow/handlers.py の CREATE TABLE ロジック)
- Redshift の COPY は
DECIMAL(p,s) に対して s を超える桁のデータを silent に丸める(TRUNCATECOLUMNS などの明示指定がなくてもデフォルトで丸まる)
- analyze でデータ分析していても「元データの小数桁数」は拾われず、固定精度に押し込む設計
期待される挙動
いずれかの対応:
- 検知: analyze 時にサンプル行から元データの小数最大桁数を観測し、10 桁を超えたら warning を UI に出す(B04 の
load_error_details と同じレベルで可視化)
- DDL 柔軟化:
DECIMAL(p,s) の s を可変にする(例: 観測桁数 + マージン)
- COPY 側:
ROUNDEC のような明示オプションで動作を宣言的に切り替える、または MAXERROR で違反件数を把握する
少なくとも UI 側で「この CSV を正しく精度維持して格納できていない可能性があります」ぐらいの注意表示が欲しい。B04 (price に "12,345 円") のようなパース失敗は既に「91 行目, カラム price」と丁寧に UI 報告されているのに、同じ精度欠損系なのに DECIMAL だけサイレントなのは非対称。
再現手順
- 同一スキーマの CSV で、ある列に小数 15 桁前後の値が入ったデータを用意(例: センサー計測値
f"{value:.15f}")
- Admin UI で該当プレフィックスを指定し analyze → apply
- apply は SUCCEEDED になるが、Redshift 側で
select length(col::varchar) や該当列の値を確認すると 10 桁までに丸まっている
参考情報
- 対象スタック:
arn:aws:cloudformation:ap-northeast-1:411521242467:stack/stagingDwhAgentStack/6d94b460-4105-11f1-a522-0e470ca459d5
- SFn execution ARN:
arn:aws:states:ap-northeast-1:411521242467:execution:AdminBackendInitWorkflowStateMachine4193125B-SxMdod2fTY64:99851d65-3c61-4d8a-a048-cbe531cf339c
- 関連ファイル:
lambda/redshiftinitworkflow/handlers.py (CREATE TABLE / COPY 生成), lambda/adminwebbackend/app.py (_analyze_csv_file / _analyze_single_csv_with_bedrock)
[C01] DECIMAL(38,10) を超える精度の数値が silent に桁落ちする(エラー無しでデータが丸まる)
再現条件
analyze→apply観測された挙動
DECIMAL(38,10)と推定する(DDL に固定された 6 種の型のうちの 1 つ)SUCCEEDED表示実測 (C01 の sensor テーブル)
生成側:
ロード後:
元は小数 15 桁で保存したのに、DB 上は 10 桁までしか残っていない。
原因(設計)
DECIMAL(38,10)固定(lambda/redshiftinitworkflow/handlers.pyの CREATE TABLE ロジック)DECIMAL(p,s)に対してsを超える桁のデータを silent に丸める(TRUNCATECOLUMNSなどの明示指定がなくてもデフォルトで丸まる)期待される挙動
いずれかの対応:
load_error_detailsと同じレベルで可視化)DECIMAL(p,s)のsを可変にする(例: 観測桁数 + マージン)ROUNDECのような明示オプションで動作を宣言的に切り替える、またはMAXERRORで違反件数を把握する少なくとも UI 側で「この CSV を正しく精度維持して格納できていない可能性があります」ぐらいの注意表示が欲しい。B04 (
priceに"12,345 円") のようなパース失敗は既に「91 行目, カラムprice」と丁寧に UI 報告されているのに、同じ精度欠損系なのに DECIMAL だけサイレントなのは非対称。再現手順
f"{value:.15f}")select length(col::varchar)や該当列の値を確認すると 10 桁までに丸まっている参考情報
arn:aws:cloudformation:ap-northeast-1:411521242467:stack/stagingDwhAgentStack/6d94b460-4105-11f1-a522-0e470ca459d5arn:aws:states:ap-northeast-1:411521242467:execution:AdminBackendInitWorkflowStateMachine4193125B-SxMdod2fTY64:99851d65-3c61-4d8a-a048-cbe531cf339clambda/redshiftinitworkflow/handlers.py(CREATE TABLE / COPY 生成),lambda/adminwebbackend/app.py(_analyze_csv_file/_analyze_single_csv_with_bedrock)