探索的財務ビッグデータ解析 : PG-Stromによるデータラングリングの並列化
35
0
0
全文
(2) 1. 探索的財務ビッグデータ解析 PG-Strom によるデータラングリングの並列化. 地. 道. 正. 行. 要 旨 本稿では, データベース Orbis から抽出された世界の2,400万社を超え る企業 (一般事業会社) に関する財務データを前処理したものを, PGStrom を利用することによって並列処理し, データラングリングを行う 時間を短縮することを試みる. また, 探索的データ解析の端緒として, デー タの要約と可視化も行い, さらに, この工程を自動実行することによって, 再現可能性を確保する方法についても述べる. キーワード：探索的財務ビッグデータ解析 (Exploratory Financial Big Data Analysis), 前処理 (Preprocessing), データラングリング (Data Wrangling) , 並 列 化 (Parallelization) , 再 現 可 能 性 (Reproducibility). . はじめに. 地道 (2020) では, 粗データ (raw data) を ｢読み込めるファイル形式｣ に変換する工程を ｢前処理｣ (preprocessing) と呼び, それを (Tange, 2018) を用いて並列化することによって, 処理速度 (velosity) を 改善した1). 本稿では, このように処理されたデータファイルをデータ解析 環境に読み込み, 分析・解析できるオブジェクトに変換する工程を ｢データ ラングリング｣ (data wrangling) と呼び (Wickham and Grolemund, 2016 参 1). を利用した並列処理については, Janssens (2014) の第８章が参考にな る.. − 1 −.
(3) 2. 地. 道. 正. 行. 照), この工程を並列化することによって高速化することを試みる (図１も 参照のこと).. 図１. 探索的財務ビッグデータ解析の全工程 (地道, 2020, 図１を再掲). ｢データサイエンス｣ や ｢ビッグデータ｣ に関する文献等における経験則 として, 前処理とデータラングリングの工程は, データを処理・分析・解析 する全工程の50％から90％を占めるともいわれることからも (cf. Patil (2012), p. 18), この試みは重要な意味を持つ. 具体的には, 財務関連の情報を含むデータベースから抽出された規模の大 きい粗データファイルを, 前処理を行うことによって ファイル2) に変 換したもの (地道, 2020参照) を, PostgreSQL3) でデータベース化する. さら に PG-Strom4) を利用することによって, GPGPU5) で並列処理し, データラ ングリングを高速化することによって, 処理速度を向上させることを試みる. (Comma Sepelated Values) ファイルとは, 項目 (カラム) 間がコンマ区切りの テキスト形式のファイルである. 3) PostgreSQL (
(4)
(5) ) は, リレーショナル・データベー ス管理システム (Relational Database Management System : RDBMS) の一つである. 本研究では, バージョン10.10を利用している. 4) PG-Strom (
(6)
(7) ) は, 海外浩平氏 によってオープンソースとして開発されている PostgreSQL の拡張モジュールであり, GPGPU を使うことによって, 高速に PostgreSQL サーバからデータを抽出する仕組 みを提供する. 海外 (2019-a, b) を参照されたい. 5) GPGPU とは, General-Purpose computing on Graphics Processing Units の略語であり, 画像処理を高速に実行する GPU (Graphics Processing Unit) の機能を, 画像処理以 外の用途に転用することである (IT 用語辞典
(8) 参照). 2).
(9) 探索的財務ビッグデータ解析. 3. 本稿の構成は次のようなものである. まず, Ⅱ節では, 本稿で利用するデー タベースとデータセット, そして前処理されたデータセットファイルについ. て述べ, Ⅲ節では, 従来から行ってきた, . 6) (以下, と略) を用いたデータラングリングについて述べる. 次に, Ⅳ節では PGStrom 環境を利用してデータラングリングを行い, . 環境を用いた場合 と比較する. さらに, この応用として, Ⅴ節では, データラングリングの結 果として抽出されたデータオブジェクトに対する探索的データ解析の端緒と して, データの要約と可視化を行う. 最後に, Ⅵ節では総括を行う. なお, 本稿で利用した計算機環境についての情報を付録に与えている.. . データベースとデータセット. 本研究では, Bureau van Dijk7) (ビューロー・ヴァン・ダイク) 社 (以下 BvD と略) のデータベース Orbis (オービス) を利用する. このデータベー スには, 世界の全企業 (データ抽出時点で約2.4億社以上を収録) の情報が 国際比較可能な統一のフォームで収録されている. このデータベースから, データセットとして, 主要財務情報 (売上高, 資産合計など) を最長10年分 抽出した以下のようなものを利用する： (1) 連結 (consolidated) 財務諸表を優先的に抽出した24,014,352社 (2) 非連結 (un-consolidated) 財務諸表を優先的に抽出した24,012,807社 データセットのファイルは, １個のサイズが 5 GB 程度の25個の
(10) ファ イル8) (２セット) からなり, 表１, 表２には, それぞれ, データセットの 仕様とサイズを与えている. 地道 (2020) では, 主に連結優先で抽出したデータセット DS-Orbis-C2018 の前処理の工程を並列化によって効率化することが議論されている. 6) 7) 8).
(11) BvD Web Page :
(12)
(13) (Tab Sepelated Values) ファイルとは, 項目 (カラム) 間がタブ区切りのテキ スト形式のファイルである..
(14) 4. 地. 表１. 道. 正. 行. データセット：仕様. データセット名. 抽出年度. データベース. 上場情報. 抽出主体. 抽出期間. 抽出指標数. DS-Orbis-C-2018. 2018. 0rbis. 上場・非上場. 連結優先. 10年. 82. DS-Orbis-U-2018. 2018. 0rbis. 上場・非上場. 非連結優先. 10年. 82. 表２ 粗データセット：サイズ データセット名. 社数. 総行数. 粗データファイル. トータルサイズ. DS-Orbis-C-2018. 24,014,352社. 264,157,872行.
(15)
(16) . 約 127 GB. DS-Orbis-U-2018. 24,012,807社. 264,140,888行.
(17)
(18) . 約 125 GB. なお, 処理後のファイル (形式) のサイズは, DS-Orbis-C-2018 (連結 優先), DS-Orbis-C-2018 (連結優先) のそれぞれの場合に対して表３のよう なものである. 表３. . 前処理後のデータセット：サイズ. データセット名. 社数. 総行数. CSV ファイル. サイズ. DS-Orbis-C-2018. 24,014,352社. 240,143,521行.
(19) . 約 124.5 GB. DS-Orbis-U-2018. 24,012,807社. 240,128,071行.
(20) . 約 124.8 GB. によるデータラングリング. は, 高速かつ汎用的なクラスタ・コンピューティング・システムの 一つであり, 本稿で利用するデータ解析環境 と連携して利用するための パッケージも提供されている. 地道 (2018-a) では, BvD のデータベース Osiris から世界157カ国の全上場企業を対象に抽出されたデータセットを前 と , そして , 処理したもの (約 1.3 GB の ファイル) を . .
(21) パッケージを利用してラングリングを行ったが, パッケー ジによって利用可能となる オブジェクト形式は, ここで 扱うような 100 GB を超える規模のデータセットにも対応している. ここでは, 東京大学情報基盤センターの専有利用型リアルタイムデータ解 環境を利用して, DS-Orbis-C-2018 (連 析ノード (FENNEL) 上で, 結優先) のデータセットファイル
(22) を へ読み込み,.
(23) 探索的財務ビッグデータ解析. 5. オブジェクトへ変換 (データラングリング) することを試みる. なお, 計算 機環境については付録を参照されたい. の環境設定として, 上で以下のように入力することによって パッケージを利用した： スクリプト１ パッケージを利用するための スクリプト !"#$%&'(
(24) (
(25) ( ( )**+),)*-'. * / 0 !"#$% & '(1(,(2
(26) (2)3) '. 4 , 5, & 6 ' !"#$%'.5' ' 5 ', '5''... 7
(27) &'89:'5 6 & .
(28)
(29) &'*6'.5 ,16
(30) ;<6 & '*++'.. パッケージに付属する関数 . を以下のように利用すること によって,
(31) ファイルを のオブジェクト ( オブジェ クト) として読み込むことができる. スクリプト２. =>?@A@Bによるデータの読み込み.
(32) C) '(0(
(33) *+3'5 1 & ''5 &< D%5
(34) & '1 '56& 'E '.. この入力の工程において, CPU の稼働率を 9) コマンドによってモニタ リングした結果を図２に与える. この図から, 全ての CPU コアがほぼ100％ で稼働していることがわかり, はデフォルトで並列処理を行っている ことがわかる. 読み込まれた
(35) オブジェクト (
(36) ) は, そのままでは可視化や統計モデリングを行うことに適していないため, パッケージに付属する 関数と 関数を用いて適当な 条件のものとで行と列の選択を行った後, 関数で で標準的に扱 われるオブジェクト形式 (の
(37) オブジェクト) に変換する. その際, データ処理の流れ10) の視認性を向上させるために, パイプ演算子 9) F((
(38)
(39) (( 10) パイプ演算子 GGを使って, データの処理をつなげることは, ｢データパイプライン｣ (data pipeline) と呼ばれることがある..
(40) 6. 地. 図２. 道. 正. 行. 1234コマンドによる CPU の稼働率のモニタリング：図の上部のプ ログレスバーが CPU コアの稼働状態をあらわしており, ８個の CPU コアが全てほぼ100％で稼働していることが読み取れる. を利用している. なお, これまでに行ってきたデータ解析のためのス クリプトとの整合性を保つために, 関数 を用いて列名を変更し ている. スクリプト３. オブジェクト変換と列名の変更.
(41)
(42)
(43)
(44)
(45) !
(46)
(47)
(48)
(49) ""# #$
(50)
(51)
(52) $
(53)
(54)
(55) %. $
(56)
(57)
(58) & $
(59)
(60)
(61) '"" (.
(62)
(63)
(64)
(65) )*+
(66)
(67)
(68) ,+
(69)
(70)
(71) +
(72)
(73)
(74) +
(75)
(76)
(77) -' +
(78)
(79)
(80) )
(81) ./+
(82)
(83)
(84) +
(85)
(86)
(87) %. +
(88)
(89) .
(90) & 0
(91)
(92) #
(93) )*#+#,#+ # #+ # #+ #. -' #+#
(94) %/#+# #+# %. #+# #. . ここでは, 行選択の基準として, 決算年を2015年 (
(95)
(96)
(97) .
(98) 探索的財務ビッグデータ解析. 7. ), 売上高, 従業員数, 資産合計を正値 (
(99)
(100)
(101) . ), さらに決算月数を12カ月のものに限定 (
(102)
(103) ) している. また, 以下の列を抽出対象とした： . 表４ Orbis データセットファイルからの抽出対象列 (1) 列名. 説明. . 企業名と BvD 企業 ID の結合. !"
(104) . 所在国. !
(105) . 連結情報. . 上場情報. #!
(106) $. 主取引所.
(107) % &. 情報提供元. . 売上高. . 従業員数. . 資産合計. 以上のデータラングリングの工程をイメージ化したものが図３である.. 図３. FENNEL 上での , , パッケージ によるデータラングリング. 以上のデータラングリングの工程を計測した結果として, 約30分 (1765 秒) かかることがわかった11). なお, 複数回の実行において数秒単位のばら つきはあるものの, 一回のラングリングに, このような時間がかかるという.
(108) 8. 地. 道. 正. 行. 結果は, 探索的データ解析を行う上で, インタラクティブ性が損なわれるこ とを表している. 以上の考察から, この工程の処理速度を向上させることが 本研究の目的である.. . PG-Strom によるデータラングリング. 本節では, PG-Strom 環境を利用することによって, ラングリングの高速 化を検討する.. 1. 環境設定 PG-Strom 環境の利用にあたっては, 以下の設定が必要となる： (PG-1) PostgreSQL データベースの構築 (PG-2) PG-Strom の設定. ここでは, 設定 (PG-1) に関する簡単な説明を行い, 設定 (PG-2) に関す る詳細は割愛する12). PostgreSQL データベースの構築にあたっては, 一旦, サーバー上に PostgreSQL データベース () を作成後, ２種類のテー ブル (
(109)
(110) ) を作成し, 表３におけるデータセッ トファイル
(111)
(112) から, それぞれ, テーブル
(113)
(114) にコピーする. これらの工程の流れ を図４に与える. 図４について簡単に補足すると, まず, データセットの ファイル
(115)
(116) を, それぞれ, ファイル へ 一 旦 変 換 し て お り , こ の 段 階 で の 処 理 は , 11) パッケージに付属する , 関数を用いて計測を行った 12) 本研究で利用する PG-Strom 環境は, JHPCN プロジェクト ( !
(117) "#$) の一環として, 実験 的に期間限定 (2019年11月15日−12月６日) で用意された環境を利用した. なお, PG-Strom の イ ン ス ト ー ル に つ い て は , % & & ''を参照されたい..
(118) 探索的財務ビッグデータ解析. 9. 図４ PostgreSQL データベース 34567のテーブル 89:;<=>?@6A89:;<=>?@Bへのデータのコピー. PostgreSQL データベースへデータファイルをロード (コピー) を行うため に文字列の置換をおこなっている13). 次に, これらの変換された ファ イル を PostgreSQL の
(119) コマンドを利用してテー ブル へコピーしている.. 2. PostgreSQL 環境のもとでのデータラングリング 通常, から RDBMS へ接続するためには, 専用の パッケージを利用. する. たとえば, から PostgreSQL のデータベースへ接続するためには, パッケージと
(120) パッケージを利用することによって可能と なる (図５参照). .
(121) パッケージを利用し, PostgreSQL データベースに接続する ための設定は, 以下のようなものである： スクリプト４. .
(122) パッケージを利用するための設定. !" # $%&#' ( !(" ) *%&# ** #+# $ ,+(----( + ./) + (( 0#+(11111111( #* + (2,*(". 13) 実際には, データファイルに存在する欠測値を表す文字列 (CD) を置換するための 処理を と を用いて行っている..
(123) 10. 地. 道. 正. 行. 図５ ,
(124) パッケージによる Postgre SQL と の接続. ここで,
(125) によって, RPostgreSQL パッケージ を読み込んでいる. なお, このパッケージの読み込みと同時に読み込まれる パッケージには, 関数が収められており, この関数を使っ て, データベースドライバを指定 (
(126) ) し, そ の結果をオブジェクト に付置している. さらに, パッケージ に付属する 関数に引数として, ドライバ名 ( ), ホスト名 (RDBMS サーバ名) (
(127) ), 接続ポート番号 ( !"#$) ,. ユーザ名. (%
(128) ) ,. パスワード. (
(129)
(130) & . ''''''''), データベース名 (( ) ) を与え, その結果を オブジェクトに付値している. この後は, データベースとの通信は オブジェクトを介して行う14). 以上の設定のもとで, PostgreSQL データベース ) から を利用し てデータラングリングを行う (図６参照). その際, . を利用して行った一連のデータラングリング (スクリプト ２, ３) と同等の条件で行うために, スクリプト５を利用する.. 14) セキュリティの関係上, ここでは, ホストアドレス, ユーザ名, パスワードは省略し ている..
(131) 探索的財務ビッグデータ解析. 11. 図６ .
(132) による PostgreSQL データベース からのデータラングリング. スクリプト５ .
(133) パッケージによるデータラングリング ｣｣ ｣｣ ｣｣ ｣｣ ｣｣ ｣｣!" ｣｣ ｣｣ # ｣｣ $ ｣｣｣｣ %&'｣｣ ｣｣( ｣｣ ｣｣｣｣%&)｣｣ ｣｣ ｣｣｣｣& ｣｣ # ｣｣｣｣&｣｣ ｣｣ $ ｣｣｣｣&｣｣ ｣｣｣｣｣｣% ｣ ｣ %
(134) * + , -.%&) * +. スクリプト５の１行目でデータ抽出を行うための SQL スクリプトを定義し たものを に付値しており, この情報とスクリプト４の３行目で定義さ れているデータベースとの接続情報 を関数
(135) に引数とし て与えることによって, SQL クエリーをデータベースエンジンにサブミッ トするための情報を定義し, に付置している. なお, この段階では, デー タ抽出はまだ行われておらず, 最終的には３行目で関数 の引数に与 えることによって, データの抽出を行っている. ただし, 引数 は先 頭行を読み飛ばすための指定である. このラングリング時間の計測結果は, 約640秒 (10分40秒) であり, この 結果は を用いた場合 (約30分) からは改善 (約３分の１に短縮) さ れている. しかしながら, １回のラングリングに, これだけの時間がかかる ということは, 対話型の処理を基本とする探索的データ解析にとって快適な 環境とはいえない. この問題に対して, PG-Strom 環境によって改善するこ.
(136) 12. 地. 道. 正. 行. とを試みる.. 3. PG-Strom 環境のもとでのデータラングリング を か ら 利 用 す る と き は , ス ク リ プ ト １ で 与 え た よ う に ,. 関数を利用した環境変数の設定や, パッケージのロー ド, さらに
(137) 関数を使って セッションをスタート させる等の専用の環境設定を行うことが必要となる. 一方, PG-Strom が適 切に設定された環境のもとで, を用いてデータラングリングを行うための ( こ れ 以 上 の ) 特 別 な 設 定 は 必 要 な い . こ の 理 由 は , PG-Strom が PostgreSQL に対するプラグインとして実装され, ハードウェア (GPGPU) に強く依存したシステムであることにある15). つまり, PG-Strom 環境のも とでデータラングリングを行うためには, スクリプト４, ５をそのまま実行 すればよい (図７参照). スクリプト４, ５を実行する工程で, 見かけ上は PostgreSQL の環境下で 実行した場合と見分けがつかないが, GPGPU の稼働率を 16) コマンド. 図７ PG-Strom 環境のもとでの .
(138) による PostgreSQL デ ー タ ベ ー ス !"の テ ー ブ ル #$%&'()*+!からのデータラングリング 15)
(139)
(140)
(141)
(142)
(143)
(144) 参照..
(145) 探索的財務ビッグデータ解析. 13. によってモニタリングした結果 (図８) から, GPU 稼働率が36％であるこ とがわかり, PG-Strom が GPU コアを並列的に利用して処理を行っている ことがわかる17).. 図８. コマンドによる GPGPU の稼働率のモニタリング：図の上部のプロ グレスバーが GPU コアの稼働状態をあらわしており, GPU 稼働率が36％ であることが読み取れる. また, のプロセスが並列的に働いて いる (
(146)
(147)
(148) ) ことも同様にわかる.. このラングリング時間の計測結果は, 約86秒 (１分26秒) であり, この結 果は を用いた場合 (約30分) から飛躍的な改善 (約20分の１に短縮) がなされており, PostgreSQL 環境のみを用いた場合 (10分40秒) からも十 分に改善 (９分の１に短縮) されていることがわかる. このように１回のラングリングに対する計測だけでは不十分と思われるた め, 100回ラングリングを繰り返し, 計測した結果を可視化することを考え る18). 16) ! 17) 今回利用した NVIDIA Tesla Volta (V100) (PCIe), 32 GB のコア (CUDA コア) 数は5120である. 18) データラングリングの時間を計測することに関するシステム間の差異を比較するため に公平性を期するためには, 本来であれば, 環境と PostgreSQL のネイティブ 環境での計測も複数回行って比較する必要があろうが, PG-Strom 環境以外のシステ ムでは, １回の計測にかかる時間が30分または10分程度かかることから割愛している..
(149) 14. 地. 道. 正. 行. 図９ PG-Strom 環 境 の も と で の .
(150) に よ る PostgreSQL データベースからのデータラングリン グを100回繰り返した場合. このラングリングを実行するための関数 を定義し, この関数を100回 実行した結果を計測し, ファイルに書き出す (ベンチマークする) た めのスクリプトファイル (スクリプト６参照) を作成した. スクリプト６. ベンチマーク用 スクリプトファイル .
(151) !"# $%& ' () (*+(*!,- "+.////.-0 + 1' - " + .2222.0""3(+.44444444.-( + .50. 1 " 6." 6 ｣｣7
(152) -｣｣2-｣｣"-｣｣6" (-｣｣ /# -｣｣7!*-｣｣ "6 "-｣｣ 062 "-｣｣"" "86｣｣｣｣"9 :｣｣3 ｣｣2 ｣｣+｣｣9 1｣｣ (｣｣"6 "｣｣;｣｣9｣｣(｣｣ 062 "｣｣;｣｣9｣｣(｣｣"" "86｣｣;｣｣9｣｣(｣｣｣｣+｣｣. . < "($ (% 2 -" 6 = >)9 1 "- + : (
(153) " ? @. 9 A/ . / 3 + 99- 6+ B. C 99 . 0 B B0 . ' D- ED EB D-EDEB D- E D E. 1 @. < $* 5 )$F6. = 3 "* -. #0 99"*. . スクリプト６における２行目から９行目で定義されている関数 は, スク リプト４による .
(154) を利用するための設定と, スクリプト５によ.
(155) 探索的財務ビッグデータ解析. 15. るラングリングを関数化したものであり, この関数を実行することによって, 図９におけるラングリングを１回実行するものである. また, 11行目から14 行目で, 実際に100回のラングリングを実行し, 各実行時間の計測結果をオ ブジェクト に格納している. さらに, 16行目で, オブジェクト を ファイル
(156) に出力している. 以上の処理を, 手動ではなく
(157) コマンドで自動実行するために,
(158) (スクリプト７) を作成し, ターゲット を用意した. スクリプト７ ファイル ! "ターゲット # $ ) +. % &'& & &(& * & * % &'% &(&. スクリプト７の１行目から４行目で定義されているターゲット を以下の ようにターミナルで実行することによって, ベンチマークの結果が ファ イル
(159) に出力される (図10も参照). ターゲット の実行 - . ,
(160) . 図10. ターゲット #に対する の実行によって実行される処理. 以上の処理は, FENNEL 環境のもとで実行しており, この工程にかかっ た時間の計測結果は, 以下のようなものである：.
(161) 16. 地. 道. 正. 行. ベンチマーク実行の計測時間.
(162) 年 月 日 金曜日 . 年 月 日 金曜日 . ここでは, ターゲット の実行開始時と終了時に出力される時間情報が記 録されたファイル (スクリプト７参照) を表示しており, この時間の差分を とることによってベンチマークの実行時間がわかる. この結果から, ２時間 ４分20秒かかったことがわかる. 次に, この結果を可視化するためには, ローカル環境で行った方が便利な ため コマンドを使って ファイルを転送後, 実行時間のデータの 可視化を行った (図11参照).. 図11. ベンチマークの実行時間の ファイルのローカル環境への転送と, に よる可視化. ここで, ベンチマーク (100回のデータラングリング) の実行時間の計測 結果をボックスプロットによって可視化しており, 実際にはローカルの 環境のもとで以下のように入力して実行している： ベンチマーク結果の読み込みと可視化
(163) !" #
(164) $ %& "' ()(! *+ ,)- . !+ ''. 実際のボックスプロットは, 図12で与えられる. この結果から, 全ての処理は90秒以内であり, 中央値が76秒程度であるこ.
(165) 探索的財務ビッグデータ解析. 図12. 17. ベンチマーク実行時間の計測結果のボッ クスプロット. とから, PG-Strom 環境は対話型の処理を基本とする探索的データ解析を実 行可能なものといえる. 次節では, これまでに 環境では難しかった ラングリングによる規模の大きなデータの探索的データ解析 (要約, 可視化) を実行する. なお, ここで考察したベンチマークの全工程については, 図13 を参照されたい.. 図13. 1. ベンチマークの全工程のイメージ. PG-Strom 環境のもとでの探索的データ解析 総資産利益率と実効税率の散布図の描画：2015年の場合. ここでは, データベース Orbis から非連結財務諸表を優先に抽出したデー タセット DS-Orbis-U-2018 にもとづいて作成された PostgreSQL のテーブル (図４参照) から, 以下のような スクリプトを実行するこ.
(166) 18. 地. 道. 正. 行. とによってラングリングを行った (図14も参照). なお, 一見すると特別な 設定は行っていないよう見えるが, PG-Strom 環境で実行している. スクリプト８. PG-Strom 環境でのテーブル !"からのデータラングリ ング. #$%&'(%｣｣ )*+｣｣+｣｣
(167) , +｣｣
(168) +｣｣
(169) +｣｣%-+｣｣. /+｣｣ )
(170) 0
(171) 1+｣｣ 23-+｣｣
(172) 2 3%
(173) +｣｣.+｣｣0422.+｣｣0425
(174) 2 .+｣｣2
(175) %｣｣
(176) ｣｣
(177) 5 6,｣｣7｣｣｣｣｣｣ ｣｣ -｣｣
(178) ｣｣｣｣ ｣｣ -｣｣
(179) ｣｣｣｣ ｣｣
(180) ｣｣
(181) ｣｣｣｣( #&'-58 -9,
(182) +$% : # &'+ ' . ここでは, 行選択の基準として, 決算年を2015年 ( ) とし, 決算月数を12カ月 (
(183) ), さらに非連結のものに限定 (
(184)
(185)
(186) ) している. また, 列として表５のようなものを 抽出対象とした： 表５ Orbis データセットファイルからの抽出対象列 (2) 列名. 説明. )*. 企業名と BvD 企業 ID の結合.
(187) , . 所在国.
(188) . 連結情報. %-. 上場情報. . /. 主取引所. )
(189) 0
(190) 1. 情報提供元. 23-. 支払利息.
(191) 2 3%
(192) 人件費 .. 税金. 0422.. 税引後利益. 0425
(193) 2. 2
(194) %. 税引前利益 資産合計. なお, このラングリングに要した時間は約３分19) であり, この程度の時間 であれば複数年にわたってラングリングを行うことも可能である. 次に, このラングリングによって抽出されたオブジェクト 19) 正確には176.755秒であり,
(195) パッケージの ,
(196) 関数を用いて測定した..
(197) 探索的財務ビッグデータ解析. 図14. 19. PG-Strom 環境のもとでの
(198) による PostgreSQL デ ー タ ベ ー ス OPQR"の テ ー ブ ル S!'%()*+T-からのデータラングリング. を使って要約と可視化を行う. まず, ラングリングを実行し, その 結果のオブジェクト
(199) を ファイル20) に保存するた めのスクリプトファイル を作成した (ス クリプト９参照). スクリプト９. データラングリングのための スクリプトファイル ! "# $%"#&!'%()*+,-./. 0 1 2 2 34 567 8｣｣ 9 :｣｣; :｣｣82 ;:｣｣ 2 <:｣｣82 :｣｣ =:｣｣ >8< :｣｣ 9 2? 2@:｣｣ AB=:｣｣82A B2; :｣｣>:｣｣?CA A>:｣｣?CA 2 A >:｣｣ A2｣｣ 2 ｣｣2 3｣｣1< ｣｣; ｣｣D｣｣｣｣ =｣｣ 2 <｣｣D｣｣｣｣ =｣｣E 82 ｣｣D｣｣FF｣｣2 ｣｣82 ｣｣D｣｣FFG7 H 6=I =J ;E82 :5G K
(200) 6 8<E : D G 0I@ 2L 8 M @ E7?NI2 7G. 次に, このスクリプトを自動実行するためのターゲット を に以下のように記述した： 20) ファイルは, の作業空間 (workspace) を保存するためのバイナリー形式 のファイルであり, 拡張子は, で表される.
(201) , , など の各種 OS 間でバイナリー互換である..
(202) 20. 地. スクリプト10. 道. 正. 行. ファイル !" #ターゲット $%&'()*&+. , -
(203) ./
(204)
(205)
(206) 0
(207) 1. 2
(208)
(209) 34356 . 7 -
(210) ./.-
(211) 0
(212). スクリプト10の１行目から４行目で定義されているターゲット を以下のようにターミナルで実行することによって, ラングリングの結果が.
(213) ファイル
(214)
(215) に出力される (図15も参照). ターゲット の実行 9 8 :. . 図15. ターゲット $%&'()*&+に対する の実行. 以上の処理は, FENNEL 環境のもとで実行しており, この結果を可視化 するためには, ローカル環境で行った方が便利なため
(216) コマンドを使っ て ファイルを転送後, 要約と可視化を行った (図16参照). ここで, ファイル
(217)
(218) は以下のように読み込んで いる. ファイル
(219)
(220) の読み込み / 4 - ;<
(221)
(222) <=. また, オブジェクト の要約は以下のような入力によって 行った..
(223) 探索的財務ビッグデータ解析. 図16. 21. ファイルのローカル環境への転送と, による要約と可視化. オブジェクト の要約
(224)
(225) . !"#$#! %& ' (& % % % ! (& %)& . !"#$#! ' % . !"#$#! ' % . . !"#$#! ' % . + . %& ,-. (& % % !. ! (& # %)& -.! 012 !".!-. + %& ,--"" (& ! % . % .$ ! (& !! %)& $$#$ 012 ..$. ) !"#$#! ' % . %& (& % % ! (& %)& * !"#$#! ' % . ) + + ) %& ,##--$ %& ,$&"-/ (& (& &/ % % &/ % # % ,$&.#/! ! (& ! (& &!/ %)& $$$ %)& !&!"/$ 012 -#- 012 --#"". + + ) + %& ,$&"-/ %& ,"#.. (& &/ (& " % !&/ % % ,$&$"/! % #- ! (& &./ ! (& "# %)& !&!"/$ %)& -"#.!# 012 -! 012 -..
(226) 22. 地. 道. 正. 行. ここで, パッケージを読み込むことによって利用可能となるパイプ演 算子 を使って, データフレーム
(227) を要約するための 関数 に引き渡している. この結果から, 欠測値 (Not Available : NA) が含まれていることがわかる. 次に, 可視化を行うためにまずは以下のように要約を行っている. スクリプト11. 企業の ROA と ETR を計算するための スクリプト. !"# &'!
(228) ()
(229) . * +
(230) , - . !"# $ %/ 0 &'!$% . ここで, １行目から４行目の入力で, オブジェクト
(231) にお ける税金 (), 税引前利益 (), 資産合計 ( ) における欠測値を パッケージに付属する関数 と を使って取り除いている. また, ５行目では税引前利益 ( ) が正の値のみに限定 (
(232) ) し ている. さらに, ６行目で 関数を用いて会社毎にグループ分け した後, ７, ８行目で各会社の総資産利益率 (Return On Asset : ROA) と 実効税率 (EffectiveTax Rate : ETR) を関数 を使って求めてい る. なお, 総資産利益率は税引前利益を資産合計で割ったもの (!"# $ %) で定義され, 実効税率は税金を税引前 利益で割ったもの (&'! $ %) で定義されている. 要 約の結果として得られるオブジェクト !"# &'!
(233) は, 各会社の社名と ROA, ETR の値を列として持つデータ・フ レーム・オブジェクトであり, 具体的には以下のようなものである： スクリプト12. オブジェクト 123412567896:;76<=>?612346@A44B3C. !"# &'!
(234) D#E/ ,*/
(235) *.*.
(236) 探索的財務ビッグデータ解析 . ! "! #$
(237) %&'()** + + ,
(238) -$-$-./ 01* 0 * -./*11 00 0 1 -./1 0 + -./+0+ 1 1+ +,
(239) - -./ 0 1 * 2&'
(240) , 3 4$5,)
(241)
(242) $'67 '4 7
(243) '2&'
(244) , 3 .)-'3 ,7'&… 1,
(245) - -./ 1 * 0,
(246) - -./ 0 1 8 1* 1 1 9 … : ;+; *< :. 23
(247) "! 00 . オブジェクト
(248) に対して, 以 下のようなスクリプトを実行することによって ETR を横軸, ROA を縦軸と する散布図を描く (Saka, et al., 2019 参照). スクリプト13 . + * 1. 企業の ROA と ETR の散布図を描画するための スクリプト. !"= > !
(249) ?!? =<=
(250) ; >> @ <#=A< B ; B>@ C=;>@=;>@"=<B > !=D
(251) D> != > ! <E=>. このスクリプトにおいて, １行目で パッケージを読み込んでおり, ２ 行 目 か ら ５ 行 目 で オ ブ ジ ェ ク ト
(252) をパイプラインでつなぎ, 関数を使って散布図を描くた めのレイヤーを重ねた結果をプロットオブジェクト に付値している. さらに, ６行目から８行目で, プロットオブジェクト を関数 を 使って 21) ファイル
(253) に書き出している. 図17はこ のファイルを描画したものである. なお, 本小節でのデータラングリングから可視化までの全工程を図18に与 える. ここで与えた単年のデータに対する可視化は, 時間をかければ３節で述べ 21) PNG は, Portable Network Graphics の略であり, 画像データを圧縮して記録するファ イル形式の一つである (IT 用語時点 FGG<: HG参照)..
(254) 24. 地. 図17. 道. 正. 行. ROA (縦軸) と ETR (横軸) の散布 図：2015年. 図18. 2015年のデータラングリング, 要約, 可視化の全工程のイメージ. た 環境と 環境を利用することによっても実現可能であったが, 複 数年にわたるデータ (例えば, Orbis データには10年分のデータが収録され ている) に対して同様の可視化を実行することは, 実行時間の観点から現実 的ではなかった. この問題に対して, 本小節で行った PG-Strom 環境を利 用することによって, 利用可能な全期間にわたるデータを使って可視化を行 うことを次に考える..
(255) 探索的財務ビッグデータ解析. 2. 25. 総資産利益率と実効税率の散布図の描画：2008年から2017年の場合 前小節では, 2015年におけるデータにもとづいて, 総資産利益率と実効税. 率の散布図を描く手順について詳しく見たが, ここでは, 期間を2008年から 2017年の10年間に拡大し, データラングリングと可視化について コマ ンドによって自動実行する方法を考える. まず, 10年分のデータラングリングを行うために, にスクリ プト14に与えられているようなターゲット
(256) を用意した. スクリプト14. ファイル !" #ターゲット $%&'.
(257) ( )*
(258)
(259) + , -. / )*)
(260)
(261) +. ここで, スクリプト は以下のような ものである： スクリプト15. スクリプトファイル $ 0 %1 23"!23415!6789:';<. =>?@ABCD )EF
(262) ) E>G?@ABCGD , -@F
(263) )H@->)EI)E?JKL@IG++++GK.@IM/,K IG====GK.N@) IGOOOOOOOOGK)IGPL.-GD / Q @@ M Q R S F
(264) G -｣｣T K｣｣=K｣｣-@ =K｣｣@LK｣｣-@K｣｣ )K｣｣+-LK｣｣ T@?@EK｣｣U.)｣｣-@U. @=K｣｣+K｣｣?CUU+K｣｣?CU@U+K U@ ｣｣@｣｣@ ｣｣NL｣｣=｣｣I｣｣｣｣)｣｣@L｣｣I｣｣｣｣)｣｣>-@｣｣I｣｣ ｣ ｣ VWV｣｣@｣｣-@｣｣I｣｣VWVDG X F
(265) )A)B =>-@K S D YWWF
(266) -L>K I
(267) D Z ( (>中略D ( QX , S XF
(268) G -｣｣T K｣｣=K｣｣-@ =K｣｣@LK｣｣-@K｣｣ )K｣｣+-LK｣｣ T@?@EK｣｣U.)K｣｣-@U. @=K｣｣+K｣｣?CUU+K｣｣?CU@U+K U@ ｣｣@｣｣@ ｣｣NL｣｣=｣｣I｣｣X｣｣)｣｣@L｣｣I｣｣｣｣)｣｣>-@｣｣I｣｣ ｣ ｣ VWV｣｣@｣｣-@｣｣I｣｣VWVDG / XF
(269) )A)B =>-@KS XD M YWXWF
(270) -L>XK I
(271) D R QAE@P- X E> I G GD.
(272) 26. 地. 道. 正. 行. スクリプト14の１行目から４行目で定義されているターゲット を以下 のようにターミナルで実行することによって, ラングリングされたオブジェ クトが ファイル
(273)
(274) に出力され る (図19も参照). ターゲット の実行 . 図19. ターゲット !に対する "#$%の実行によって実行される処理. 以上の処理は, FENNEL 環境のもとで実行しており, この工程にかかっ た時間の計測結果は, 以下のようなものである： ターゲット に対する の実行時間 &' (年 月 )日 火曜日 *+)+, -./ & 0' (年 月 )日 火曜日 *+,1+1* -./. この結果から, 40分55秒かかったことがわかる. こ の 処 理 に よ っ て 得 ら れ た フ ァ イ ル
(275)
(276) の容量は, 2.75 GB であり, 一旦ファイルを コマンド を利用してローカル転送した後, 可視化を行う (図20参照). 次に, 可視化を行うために
(277) にスクリプト16に与えられている ようなターゲット を用意した..
(278) 探索的財務ビッグデータ解析. 図20. 27. ファイル N
(279)
(280) OP
(281) QPRSTUVWX'(N
(282)
(283) のローカルへの転送. スクリプト16 # &.
(284) ファイル
(285) ターゲット と
(286)
(287) . ! " . $ % . ! " . ここで, スクリプト は可視化した結果を ファイルと して書き出すためのものでありスクリプト17で定義される. スクリプト17 # & < = ? 3 B 2 # & < = ? 3 B 2 . スクリプトファイル
(288) '(. )* +, -. / )%0 1% 234 . ,5 6!74$ %*+ 789 5 : ;4% +)* 5 ;4% + )9 5 6! 7> > 7%) +@% + "55 > > 7%) +@% +)A17* A "55 > > 7%) +@% + A * )55> > 7%) +)A17* A " 25 > > *4A19+7% % 5> > 4 %C+ 0DE)A17* A "- A * )8 FG E "-)A17* A "5> > )* + +FG 8 0D55 H *A*% + %C E 2 28)IE2 25 H ")%+!85H9)%+285 H )1 + % )E9 5 + +, 0D!FG !,8 9 8, ,8 E ,,55 % +5 J *77+5 K +7% 7%LM223M89 E2235 +7% 7%LM22BM8 9 E22B5.
(289) 28. 地. ' ( ) * . 道. 正. 行. !!" #$ % & !!"#$%& !!" #$ % & !!" #$ % & !'!" #$ % '& !(!" #$ % (& !)!"#$%)& !!" #$ % &. スクリプト17の１行目で, ファイル
(290) を読み込んでおり, ２行目から20行目で散布図を ファイル へ書き出すための関数を定義している. なお, 21行目から30行目で実際に 2008年から2017年のデータを利用した散布図を ファイルへ書き出す関 数を実行している. ターゲット を以下のようにターミナルで実行することによって, ス クリプト16の２行目から４行目で定義されているシェルスクリプトが実行さ れ, 10年分の ファイル ∼ が出力される (図21参照). ターゲット の実行 , + $ . 図21. ETR (横軸) と ROA (縦軸) の散布図：2008年∼2017年. 以上の処理は, ローカル環境のもとで実行しており, この工程 (10個の PNG ファイルの出力) にかかった時間の計測結果は, 以下のようなもので.
(291) 探索的財務ビッグデータ解析. 29. ある： ターゲット
(292) に対する の実行時間
(293) 年 !月 日 金曜日 "時 分##秒 $% &
(294) 年 !月 日 金曜日 "時'(分秒 $%. この結果から, 28分27秒かかっていることがわかる. さ ら に , 10 年 分 の フ ァ イ ル
(295) ∼
(296) をまとめてアニメーション 22) ファイルに変換するために にスクリプト18に与えられているようなターゲット を用意した. スクリプト18. )*+,ファイル -*+,./0,1ターゲット *2/)*3/42. 5 &6 ' 7
(297) 8
(298) &7# 9999
(299) # &6 & . ターゲット を以下のようにターミナルで実行することによって, スクリプト18の２行目から４行目で定義されているシェルスクリプトが実行 され, 10年分の ファイル
(300) ∼ フ ァ イ ル
(301) が 23) コ マ ン ド に よ っ て ア ニ メ ー シ ョ ン へ変換される (紙面では動きを表現できないので図は割 愛する). ターゲット の実行 ; : . 22) GIF は, Graphics Interchange Format の略であり, 画像データを圧縮して記録するファ イル形式の一つである. アニメーション はアニメーション機能を持つように拡 張された仕様の一つで, 動画を保存することができる形式である. (IT 用語時点 <
(302) 5==> & ?
(303) =参照.) 23) は, ImageMagick (<
(304) 5== = &
(305) <
(306) ) に付属す る画像ファイルを変換するためのコマンドである..
(307) 30. 地. 道. 正. 行. 以上のターゲット , を実行することによって得られる可 視化の工程のイメージを図22に与える.. 図22. 可視化の工程のイメージ. さらに本小節で行ったデータラングリングから可視化までの全工程を図23 に与える. なお, これらの実行時間は, FENNEL 環境で行った処理に約41 分, ローカル環境では約28分であり, (転送時間を除いて) 全体で１時間強 である.. 図23. 2008年∼2017年のデータラングリング, 可視化の全工程のイメージ.
(308) 探索的財務ビッグデータ解析. . 31. おわりに. 本稿では, PG-Strom 環境を利用したデータラングリングにもとづく処理 速度の向上と, 得られたデータの要約と可視化を行うことによって探索的デー タ解析の実行可能性について検討した. なお, にターゲットを 作成することができる工程は, を用いて自動実行することによって, 再現可能性をもたせた. また, 本稿で行ったデータの可視化は, の作業空間のイメージを ファイルに出力することによって保存し, ローカル環境に一旦転送 したものを再度読み込み, を用いて行った. この理由としては, ネットワー クを超える環境でリアルタイムで可視化することが速度などの観点から難し いためであるが, ファイルの ｢書き出し｣, ｢転送｣, ｢読み込み｣ に かかる時間は無視できないものがある (図24の破線内の工程を参照).. 図24. ファイルの ｢書き出し｣, ｢転送｣, ｢読み込み｣. この問題点をふまえ, 今後統計モデリングを含む探索的データ解析をさら に本格的に実行するために検討しなければならないこととしては以下のこと があげられる： (M1) シリアライズの再検討 (M2) データラングリングのさらなる高速化 ここで, ｢書き出し｣, ｢転送｣, ｢読み込み｣ の時間を改善するための簡単 な方法としては, (M1) で指摘しているように の作業空間をシリアライ.
(309) 32. 地. 道. 正. 行. ズ (serialize) するファイル形式を見直すことであろう. つまり, の標準 的なシリアライズのファイル形式である ファイルではなく, Apache Arrow24) や Apache Parquet25) などの形式でシリアライズすることによってファ イルサイズを縮小したり, 書き出し・読み込みにかかる時間を大幅に短縮で きる可能性がある. このことは, ファイル転送の時間短縮にもつながること から, 次の課題として検討する予定である. ま た , (M2) に つ い て は , PG-Strom と 列 指 向 デ ー タ ス ト ア (Arrow Fdw)26) を併用をすることによって, さらなる時間短縮を実現できることが 報告されている27). このことも, 今後の課題としたい. (筆者は関西学院大学商学部教授). 参考文献 [１] Janssens, J. (2014) Data Science at the Command Line, O’Reilly Media. (太田満久, 下田倫大, 増田泰彦監訳, 長尾高弘訳 (2015). コマンドラインではじめるデータサ. イエンス―分析プロセスを自在に進めるテクニック― , オライリー・ジャパン.) [２]. 地道正行 (2018-a). 探索的財務ビッグデータ解析―前処理, データラングリング,. 再現可能性― , 商学論究, 第66巻, 第１号, pp. 131, 関西学院大学商学研究会. [３]. 地道正行 (2018-b). 探索的財務ビッグデータ解析―データ可視化, 統計モデリン. グ, モデル選択, モデル評価, 動的文書生成, 再現可能研究― , 商学論究, 第66巻, 第２号, pp. 141, 関西学院大学商学研究会. [４]. 地道正行 (2020). 探索的財務ビッグデータ解析―前処理の並列化― , 商学論究,. 第67巻, 第３号, pp. 119, 関西学院大学商学研究会. 海外浩平 (2019-a) PostgreSQL は最新ハードウェアでどこまでやれるのか？ GPU. [５]. と NVME で実現する超高速ログデータ処理基盤 ,
(310)
(311)
(312)
(313) .
(314) !" "# [６]. 海外浩平 (2019-b). Arrow Fdw ―PostgreSQL で大量のログデータを処理するため. の ハ ー ド ウ ェ ア 最 適 化 ア プ ロ ー チ ― , 20191115-PGconf.Japan, $" % & '(&
(315) (.
(316) #" 24) 25) 26) 27). .
(317)
(318) & )*
(319) &
(320) "+ &*+
(321) &(
(322) .
(323) #" % & +$
(324) &
(325) の2019年10月31日の記事 秒速で10億レコー ドを処理する話 を参照されたい..
(326) 探索的財務ビッグデータ解析. 33. [７] Patil, DJ (2012) Data Jujitsu : The Art of Turning Data into Product, An O’Reilly Radar Report, O’Reilly. [８] Saka, C., T. Oshika, and M. Jimichi (2019) Visualization of tax avoidance and tax rate convergence : Exploratory analysis of world-scale accounting data, Meditari Accountancy Research, Vol. 27 No. 5, pp. 695724, Emerald Publishing Limited. [９] Tange, Ole, (2018) GNU Parallel 2018, ISBN : 9781387509881, DOI : 10.5281 / zenodo. 1146014, URL :
(327) , Mar, 2018. [10] Wickham, H. and G. Grolemund (2016) R for Data Science, O’Reilly. 謝辞 本研究の一部は以下の助成を得ている. さらに, 東京大学の宮本大輔氏には PG-Strom 環境を提供して頂き, BvD の増田歩氏にはデータの抽出に関して多大なるご協力いただ いた. ここに感謝の意を表する. 科学研究費基盤研究 C：｢グラフィカル・データ・アナリシスによる格差 研究と社会環境会計による解決方法の提案｣ (2016年∼2018年), 課題番号： 16K04022 科学研究費基盤研究 C：｢共有価値創造 (CSV) のための社会環境会計の 構築｣ (2019年∼2021年), 課題番号：19K02006 2019年度学際大規模情報基盤共同利用・共同研究拠点 ( JHPCN) 課題： ｢財務ビッグデータの可視化と統計モデリング｣, 課題番号：jh191002-NWJ 2020年度学際大規模情報基盤共同利用・共同研究拠点 ( JHPCN) 課題： ｢財務ビッグデータの可視化と統計モデリング｣, 課題番号：jh201003-NWJ 関西学院大学図書館図書費 B, 研究設備費 (III), 個人研究費. 付録 計算機環境 本研究のために利用した環境としては, 東京大学情報基盤センター28) に設 置された専有利用型リアルタイムデータ解析ノード (FENNEL) を利用した. １ノードの簡単な仕様を以下に与える29)： 28) 29) 今回利用しているノードは, GPU がある環境が２ノードであり, GPU がない環境が ２ノードの合計４である..
(328) 34. 地. 道. 正. 行. OS : 16.04 CPU : Intell Xeonプロセッサー E5-2620 v4, 8 Cores Main Memory : 16 GB Storage : 1 TB GPU Memory : 8 GB また, 本研究で利用した PG-Strom 環境は, 実験的に FENNEL 環境にネッ トワーク接続した以下の環境を利用させていただいた： OS : . 7.7 CPU : Intel Xeon Bronze 3104, 6 Cores Main Memory : 128 GB Storage : 600 GB GPU Unit and Memory : NVIDIA Tesla V100, 32 GB なお, ローカル環境は以下のようなものである： OS :
(329) . Catalina (10.15.4) CPU : Intel Core i9-8950HK, 6 Cores Main Memory : 32 GB Storage : 4 TB.
(330)
関連したドキュメント
Applications of msets in Logic Programming languages is found to over- come “computational inefficiency” inherent in otherwise situation, especially in solving a sweep of
Shi, “The essential norm of a composition operator on the Bloch space in polydiscs,” Chinese Journal of Contemporary Mathematics, vol. Chen, “Weighted composition operators from Fp,
We have introduced this section in order to suggest how the rather sophis- ticated stability conditions from the linear cases with delay could be used in interaction with
[2])) and will not be repeated here. As had been mentioned there, the only feasible way in which the problem of a system of charged particles and, in particular, of ionic solutions
This paper presents an investigation into the mechanics of this specific problem and develops an analytical approach that accounts for the effects of geometrical and material data on
[r]
I hearby report on release the attorney for the Customs procedures （as the attorney for payment of Consumption Tax (This case is only limited to perform regarding to Consumption
Amount of Remuneration, etc. The Company does not pay to Directors who concurrently serve as Executive Officer the remuneration paid to Directors. Therefore, “Number of Persons”
