ファイルサイズの圧縮に関する、良くまとめられたテキスト

PhUSE(http://www.phuse.eu/)にて、よいテキストがあります。「ファイルサイズの問題って何?」という根本的な疑問は、読み手の勉強に任せます。


※当ブログがCDISC標準に関わっている方の目に触れる機会が増えたようです。CDISC関連のエントリは、TKDとSMZの二名で作成しております。中の人は一人ではありません。その点、勘違いしないように。
ファイルサイズが大きくなる原因
 A) データの行数が多い
 B) 変数の占有領域が大きい(=変数長の定義が大きい)

SDTMの電子データ提出では、.xpt形式が用いられる。この形式はかなりの旧式であり、変数長を大きく設定するとファイルサイズが増大する。実データ量とファイルサイズは比例しない。より洗練されたファイル形式であれば、この手の問題は解決される。残念ながら、.xpt形式がデファクトスタンダードであるため、Bが問題となっている。


Aの問題を解決する方法
『ファイルの分割』である。FDAは1GBまでのファイルを受け付けている(※1)。これを超えるなら、ファイルを複数に分ければよい。ファイルの分割方法(カテゴリー毎に分割)、Define.XMLへの記述方法が各種のドキュメントに記載されている。これは『ファイル当りのデータ行数』を制限するアプローチである。

※1:FDAが受け付けるファイルサイズは徐々に大きくなっている。かつては25MBであったが、2011年ごろに500MBに拡張された。2013年には1GBとなっている。FDA発行のドキュメントを精読して、最新の情報を手に入れておきたい。


Bの問題を解決する方法
『変数長を最適化』である。データ長を調べ、必要な変数長に指定しなおす。優れたプログラマであれば、効率的に作業を実施する手段をいくらでも見つけられるだろう。あらゆる文字変数を対象にできる。しかし、SDTMのスペックで長さが指定されている変数が存在する。また、ヘッダ変数を対象に含めるべきか、議論の余地がある。それらの変数は除外した方がいいかもしれない(※2)。

※2:フラグには1文字指定、変数名として利用されるデータには8文字指定、変数ラベルとして利用されるデータには40文字指定がある。


「Aの解決」と「Bの解決」(※3)
ファイルサイズがある程度大きい場合、Bの解決を図るほうがよい。作業者にとって、ステップが増加することになるが、申請直前に行うプロセスにすると導入しやすい。

20131228a.jpg

すなわち、SDTMデータセットが2つ存在することになる。1つは調整前のSDTM、もう一つは申請用にファイルサイズ調整されたSDTMである。どちらのデータセットを用いてADaMを作成するかは任意である。しかし、調整前SDTMデータセットを用いるのが現実的かもしれない。

20131228b.jpg

この手法は『現実的で実用的なファイルサイズ圧縮のアプローチ』である。しかし、これが最善である保障はないし、ファイルサイズを最も圧縮するプロセスでもない。

例えば、『ファイルサイズが1GBを超えないこと確認したら、いかなるファイルサイズ調整もしない』という戦術もある。この方法では、ファイルにムダがあるものの、消費リソースが極小で済む。

『上記の手順に従いファイルを分割した後に、更に変数長を見直す』戦術もある。ファイルサイズが更に圧縮できるかもしれない(※4)。

※3:大前提として、申請データセットに対してファイルサイズのチェックを行う。内部的な利用にとどまるなら、ファイルサイズを調整する必要はない。もし、あなたのファイルサーバーが容量不足に悩まされているなら、迷わずに記録領域を拡張しよう。安い投資で問題が解決できる。

※4:この場合、ある変数の変数長が分割ファイル間で不一致となる。ファイルを再結合する際に、この不一致が問題になるかもしれない。



参考:
http://www.phusewiki.org/wiki/index.php?title=Data_Sizing_Best_Practices_Recommendation
2013-12-28(Sat)
 

コメントの投稿

非公開コメント


プロフィール

TKD + SMZ

Author:TKD + SMZ
ガレージキット組み立て中級者
子育て初心者

2007年に友人の薦めでガレージキット組み立てを開始。その面白さに目覚める(w

2011年にお付き合いのあった原型師さんに薦められて、原型製作を開始。ワンフェスに参加しています。2017年から、活動を一時休止しております

ブログの大まかな内容についてはカテゴリーの「総合案内」をご覧下さい

カウンタ
ブログ内検索
月別アーカイブ