.NET Coreで実行可能ファイルを作る

最近はちょっとしたプログラムを作るときに.NET Coreコンソールアプリケーションを選択するようにしている。今のところ実際にLinuxで動かすような機会はないが、クロスプラットフォームに出来るからだ。ただ通常はDLLとしてビルドされるため、PCに詳しくない人には起動手順を説明しにくい。

第三者向けにインストーラを作成して使用手順を書こうとした時に、ふと.NET Core 2.2からはDLLではなくて、実行ファイル(EXEファイル)としてビルド出来ることを思い出した。第三者向けに配布するなら実行ファイルとしてビルドしておいた方が便利そうだ。

コマンドラインから実行ファイルを生成するのは以下のように”-r win-x64 –self-contained true”指定するだけである。

dotnet publish -c release -r win-x64 --self-contained true

win-x64はRID(Runtime Identifier)でビルドするターゲットとなるプラットフォームを示します。linux-x64とかwin-arm64などと指定すれば異なるOSやCPUアーキテクチャをターゲットとしたバイナリを簡単に作れて便利です。

URL:
https://docs.microsoft.com/ja-jp/dotnet/core/deploying/deploy-with-cli
https://docs.microsoft.com/ja-jp/dotnet/core/rid-catalog

僕の経験した最悪の糞コードの話

ツイッターで久しぶりに糞コードの話を見かけたので、僕の知る最悪の糞コードの話を書いておこうと思う。

そのコードはGeneric Programmingによって実装されていました。クラスはきちんと整理されており、テンプレートを最大限に活用したコードは必要最小限の記述となっています。整然とひとつの思想によって実装された素晴らしいコードでした。いくつかの致命的な問題を除いては・・・

一つ目の致命的な問題は、このプロダクトがWindows向けであり、開発環境にVisual C++を使用していたことです。当時のVC++コンパイラにはバグがありました。複雑なテンプレートを定義すると、コンパイラがジェネラルプロテクションエラーを起こして終了してしまうのです。

知っていれば回避可能な、実用上は問題ないバグをBy Design(仕様)と称していた時代の話です。コンパイラのバグが近日中に修正される可能性はありません。この問題を根本的に解決するには、プログラムの根幹を構成しているGeneric Programmingを、互換性を維持し挙動を変えることなく取り除く・・・・って、ほぼリメイクですヤン!

実際には既にリリースしてしまっているので互換性維持は絶対、修正や機能追加は待ったなし、そんな大規模修正できません。影響の少なさそなところからGeneric Programmingを取り除き、VC++が落ちない程度までテンプレートの使用量を減らしては、修正をするって作業に明け暮れたのでした。

一つ目の・・・と書いたからには二つ目以降もあるわけで、DLLの引数としてクラスを何の考えもなく受け渡してる。それもDLL側で確保して呼び出し元で解放させたり。C++はコードや変数がどのようにメモリ上に展開されるかは仕様として定められていません。したがってクラスを引数として受け渡そうとするなら、全てのモジュールを同じコンパイラ、同じヘッダファイル、同じコンパイルオプションでビルドするのが必須です。ちょっと直すだけでも全モジュールをビルドし直して置き換えないと動作を保証できないという困難さ。

このコードを書いたエンジニア、どうやらJavaのスペシャリストであったようです。JavaのプログラマとしてOOな設計やコーディング技法には精通しており、その技をしっかりと使いこなしていました。でもC++固有の言語仕様には非常に疎く、おそらくはほぼ初心者。newしてもdeleteを呼んでいる場所が全くない。C++の言語仕様上の地雷をことごとく踏み抜いてく、そんなクソースでした。

Windows7でWindowsUpdateの再起動中に15%程度でとまってしまう

Windows 7 Professional (x64)の環境において、Windows Updateで繰り返しエラーが発生。OSの再起動中に毎回15%程度のところでエラーが発生して、巻き戻されてしまいます。久しぶりにC:\Windows\Logs\CBS\CBS.LOGの出番です。

2019-01-22 10:17:51, Info                  CBS    Waiting for poqexec.exe to complete...
2019-01-22 10:17:56, Info                  CBS    Waiting for poqexec.exe to complete...
2019-01-22 10:18:01, Info                  CBS    Waiting for poqexec.exe to complete...
2019-01-22 10:18:10, Info                  CBS    SQM: Reporting poqexec status with status: 0xc0000043, failed file: conhost.exe, interfering process: tmbmsrv.exe,conhost.exe,conhost.exe, context: Startup, first merged sequence: 1613
2019-01-22 10:18:10, Info                  CBS    SQM: Upload requested for report: PoqexecStatus, session id: 142861, sample type: Standard
2019-01-22 10:18:10, Info                  CBS    SQM: Ignoring upload request because the sample type is not enabled: Standard
2019-01-22 10:18:10, Info                  CBS    Failure in poqexec.exe while processing updates. [HRESULT = 0x80070020 - ERROR_SHARING_VIOLATION]
2019-01-22 10:18:12, Info                  CBS    Set the CCP impactful-commit disabling value
2019-01-22 10:18:12, Error                 CBS    Startup: Failed while processing critical primitive operations queue. [HRESULT = 0x80070020 - ERROR_SHARING_VIOLATION]
2019-01-22 10:18:12, Info                  CBS    Setting ExecuteState key to: CbsExecuteStateResolvePending | CbsExecuteStateFlagRollback
2019-01-22 10:18:12, Info                  CBS    Progress: UI message updated. Operation type: Update. Stage: 1 out of 1. Rollback.
2019-01-22 10:18:12, Info                  CBS    Startup: Processing advanced operation queue, startupPhase: 0
2019-01-22 10:18:12, Info                  CSI    00000006 IAdvancedInstallerAwareStore_ResolvePendingTransactions (call 1) (flags = 0000000a, progress = NULL, phase = 0, pdwDisposition = @0x1e0f9e0
2019-01-22 10:18:12, Info                  CBS    Startup: Changing logon timeout to a static timeout: 10800000
2019-01-22 10:18:13, Error                 CSI    00000007 (F) Error: ResolvePendingTransactions called after poqexec failure (call 1)
  Status = STATUS_SHARING_VIOLATION, Operation = DeleteFile, DiagString = [l:70{35}]"\??\C:\windows\System32\conhost.exe"
[gle=0x80004005]
2019-01-22 10:18:59, Error                 CBS    Startup: Primitive operations failed, startupPhase: 0.  The transaction will be cancelled. [HRESULT = 0x80004005 - E_FAIL]
2019-01-22 10:18:59, Info                  CBS    Setting ExecuteState key to: CbsExecuteStateInitiateRollback | CbsExecuteStateFlagPrimitivesFailed
2019-01-22 10:18:59, Info                  CSI    00000008 Creating NT transaction (seq 1), objectname [6]"(null)"
2019-01-22 10:18:59, Info                  CSI    00000009 Created NT transaction (seq 1) result 0x00000000, handle @0x12c
2019-01-22 10:19:05, Info                  CSI    0000000a@2019/1/22:01:19:05.296 CSI perf trace:
CSIPERF:TXCOMMIT;2808573

Errorが発生している箇所を見ると、conhost.exeのところでERROR_SHARING_VIOLATION(0x80070020)が発生しているようです。
ERROR_SHARING_VIOLATION はほかのプロセスとの排他処理によってエラーが発生していることを示しています。

注目するのはErrorの少し手前の行。”SQM: Reporting poqexec status with status: 0xc0000043, failed file: conhost.exe, interfering process: tmbmsrv.exe,conhost.exe,conhost.exe, context: Startup, first merged sequence: 1613″のところです。 “failed file: conhost.exe”に続く”interfering process: “のところで、原因となった可能性のあるプロセスが列挙されています。そこには”tmbmsrv.exe”の表記が・・・・

“tmbmsrv.exe”ってトレンドマイクロのアンチウィルス・・・セーフモードで起動して、コントロールパネルのサービスから アンチウィルス のサービスを無効にして再起動。アンチウィルスが動作しない状態にして、Windows Updateを実行すると・・・成功しました。

事務に使う業務用パソコンに限ってはVDIも良い

最低限必要なパソコンのスペックって」の話の続き。

事務用パソコンに限った話だが、もし一拠点の事務用パソコンの台数が15台以上あるならVDI(Virtual Desktop Infrastructure、仮想デスクトップ基盤)を検討してみるのもよい。

VDIには様々なソリューションがあるが、おすすめしたいのは、最もコストパフォーマンスに優れる、Windows Server 2016にRDPで接続する、正確にはSBC(Server Based Computing)と呼ばれるタイプ。

パソコンを購入する場合、処理のピークを短い時間で終わらせるために十分な性能のCPUやストレージを用意する必要があります。ですが処理のピークが続くのは数秒(ピークが数秒で終わる程度の性能を持つCPUとストレージを準備したのだから当然だ)でしかありません。それ以外の時にはパソコンの持つ性能の数%しか使っていないので、潜在性能の10%も活用できていない事になります。

もしCPUやSSDを複数のユーザーで共有できるなら、メモリを16GBも積めば1台のパソコンで8人程度が同時に作業しても、体感速度はほとんど変わらないはずです。

そこで十分に高い性能を持つサーバーを用意します。そのサーバにシンクライアント端末という低性能な端末(モニター、マウス、キーボードが繋がっているだけで、実質的にCPUにメモリやストレージはありません。単体ではパソコンとして機能しません。)で接続して使います。それでもユーザーにとっては、普通にパソコンを使っているのと操作は変わりません。

仮に15人の場合には概ね下記のような金額になります。
サーバー(8コアCPU、メモリ32GB、SSD1.4TB RAID5)が90万円。シンクライアント(モニター込み)が5万円×15台で75万円。Windows Server 2016のCALが5000円×15台で7.5万円。割安なOfficeのプレインストールモデルを使うことは出来ないので、Office 2016 Std(約5万円)を購入するか、Office 365 ProPlus(月額1,310円)を契約する必要があります。トータルで250万円ぐらいで導入できるはずです。

15万のパソコンを15台買うなら225万円ですから25万円ほど割高になっています。でもそれ以上にメリットもあるのです。

・メンテナンスの手間が激減
サーバーにだけ設定すればよいので、手間が激減します。新しいプリンタのドライバや業務アプリケーションをインストールするにも、15台のパソコンにインストールしてあるく必要はありません。VDI用サーバ1台にインストールすればOKです。

・バックアップの手間が激減
クライアントパソコン内に保存されている設定やデータのバックアップはかなり大変です。実際にはパソコン内のデータバックアップは諦めている事が多いでしょう。VDI用サーバーのバックアップさえ取っていれば、各自のデスクトップやマイドキュメントのファイルもしっかりバックアップをとれます。

・故障時の復旧作業が激減
パソコンが壊れた場合、新しいパソコンに必要なアプリケーションのインストールや設定を施し、故障したパソコンのHDDが必要なデータを取り出してコピーする。場合によっては1日~2日は潰れてしまいます。VDI環境なら設定やデータはVDI用サーバーに保持されているので、新しいシンクライアント端末をつなぐだけで復旧します。予備にシンクライアント端末を1台余計に買っておくなら、30秒で復旧できるのです。
サーバが壊れた場合ですが「5年間24時間365日4時間以内に訪問修理」とかを購入時に申し込んでも+30万円程度です。年間6万円程度の支出に過ぎません。同じ事をパソコンで申し込んだら+100万円、年間20万円程度かかるであろう事を考えたら、安いものです。

・体感速度はむしろ向上
サーバー全体ではCPUのコア数もSSDの速度も、個人にパソコンを与えていた場合の2倍ほどになってます。したがってピーク時の処理性能も個人にパソコンを持たせていたときの2倍、ユーザーを待たせるような重たい処理も短時間で終わるようになり、体感速度も増します。

・在宅勤務やサテライトオフィスにも対応
VPNによる社内ネットワークへの接続方法さえ準備すれば、流行の在宅勤務やサテライトオフィスにも対応できます。全従業員を対象とするのは内部統制的な難しさもあるでしょうけど、部長の自宅にVPNルーターとシンクライアントを設置(10万円程度)するだけで「自宅でも会社と同じ作業ができる」ぐらいの事は簡単に実現できます。

ちなみに15台だと25万円ほど高くついてますが、30台だとサーバ(16コアCPU、メモリ64GB、SSD1.4TB RAID5)の価格が約160万円、他は同じだから総額で約320万円。15万のパソコンを30台買うと450万円なので、130万円くらい安くなる計算です。こうなると事務用パソコンに限っては、VDIを使わない理由は無いですね。

ちなみに技術者用パソコンをWindows Server 2016のRDPで共有するのは無理です。一般ユーザーよりも強い、管理者権限やデバッグ権限を与えてもらわないと仕事になりません。頻繁に管理者権限で設定を変更することになるので、ちょっとしたミスで全員巻き添えで仕事がとまる可能性が高いです。Hyper-VやVMWareを使ったVDIなら行けますが、さらにコストが高くなります。

またデザイナ用パソコンをVDIにするのは完全に無理です。GPUが使えなくなる上に、画面上の表示品質下がるので、おそらく仕事になりません。

最低限必要な業務用パソコンのスペックって

低スペックPCを使わせる事の損失・・・
人権を満たす最低スペックのパソコンとか、Twitterで話題になっているようなので、補足説明ておく。

・事務職・・・15万円前後

CPU:Intel i5 or i3(4コア)
メモリ:8GB(4GB×2枚)
ストレージ:SSD 128GB
モニタ:24インチ(設置スペースがあるならデュアルモニター)

事務職でこれが最低スペックな理由は、これ以上スペックを落とすと価格差以上に性能が低下してしまうため。例えばCPUをCeleronに落とすと数千円安くなるが、性能は半分以下になる。モニターも20インチにすれば数千円安くなるが、A4資料を画面上で閲覧することすら困難になる。
メモリが8GBなのには二つの理由がある。
一つ目はデュアルチャンネルを有効にするため。同サイズのメモリを2枚さすとデュアルチャンネルが有効になってメモリアクセス速度が2倍になる。同一メモリサイズでもデュアルチャンネルが有効か否かで実行速度が30%前後異なってくる。2GB×2枚でもデュアルチャンネルは有効になるが、2GBのメモリカードはほとんど製造されておらず流通していない。メーカーによっては16GB(8GB×2枚)以上にしないとデュアルチャンネルが有効にならない場合もある。この場合には16GBにしたほうが良い。
二つ目はメモリスワップが発生した場合にSSDの寿命が短くなってしまうこと。最近のアプリケーションはメモリをたくさん使って早く動かす設計になっていることが多い。そのためWEBブラウザだけでも1GB程度のメモリを使ってしまうことは珍しくない。SSDの欠点は書込み可能回数に制限があり、頻繁に書込みを行うと寿命が短くなることにある。メモリが不足してメモリスワップが発生し、SSDへの書き込み回数が増えると、SSDがより早く寿命を迎えることになる。SSDの容量を増やせば書込み可能回数も増やせるが、SSDよりメモリのほうが安い。
SSDが128GBとかなり小さいのは、日常的に使用するデータはファイルサーバに保存していると考えているため。128GBでも事務作業で使用するようなアプリケーションのインストールや、一時的な作業ファイルを置くのに、困ることは少ないと思う。128GBより小さくすること、Windows Updateのための作業領域が不足するなどの問題に直面する。

・技術職・・・30万円前後

CPU:Intel i5 又は i7
メモリ:16~32GB
ストレージ:SSD 256GB+HDD 数TB
モニタ:27インチ(設置スペースがあるならデュアルモニター、2台目は24インチでも可)

最低メモリが16GBに増えている。エンジニアは複数のツールを同時に起動して作業する機会がどうしても増える。統合開発環境などは、メモリを多く使う事が多い。WEBブラウザに、Officeに、メールに、統合開発環境に、ビジネス用チャットに・・・と立ち上げていくと到底8GBのメモリ消費では収まらない。最低でも16GB必要となる。

できれば32GBほしい。32GBあると仮想OSをストレスなく利用できる。仮想OSを使うと、テスト用のOSを作業前に保存していた状態に数十秒で戻すことが出来る。そのためインストールのテストや、環境を壊す恐れのあるようなテストが非常に捗る。仮想OSを使えないと、たびたび半日かけてOSを戻す羽目になるので、かなり大変なのだ。
またメインで使用している環境に共存できないソフトウェアを使ってテストしなければならない場合も便利である。特定バージョンのOSでしな再現しない問題や、古いバージョンのOfficeでしか再現しない問題などをテストするために、別途パソコンを用意してゼロからインストールしていては時間がかかりすぎるのだ。

CPUは早いに越したことはないですが、i7以上のCPUや、高速なグラフィックスカードは機械学習でもするのでない限りは必要ないです。

・デザイン職・・・50万円前後

CPU:Intel i5 又は i7
メモリ:16~32GB
ストレージ:SSD 256GB(容量不足時にはHDDを追加)
GPU:5万円前後
モニタ:27インチ(カラーマネジメント対応)

CADやCG、動画を扱うなら上記の技術職向けPCに加えて、5万円程度のGPUが必要になります。
そして何より重要なのがモニターです。安物のモニターだと微妙な色の差を視認できなかったり、モニター毎の発色の差を微調整する機能が不足していて、色校正に手間どってトラブルの原因になります。カラーマネジメント機能のついたモニターは、一般的な事務用モニターの価格より2~3倍ほど高いです。27インチモニターだと20万円ちかい金額となります。
意識せずにマックを使っているデザイナーも少なくないですが、デザイン職にマックが支持されてきた理由もここにあります。マックのモニターは最初から同じ発色になりように微調整されて販売されており、カラーマネジメントの云々を意識する必要がないのです。カラーマネジメント機能のついたモニターを買うと、結果的にマックと変わらない値段になってしまいます。もしデザイナーがWindowsではなくてマックで仕事をしたいというなら、素直にマックを買ってあげたほうが安いです。

でも、事務用に限るならパソコンを使う事自体を止めてしまう手もあります。「事務用に限ってはVDIの方が良いかもよ?」に続きます。

Windows 7以降にオフライン環境で.NET Framework 3.5をインストールする

Windows 7移行のOSに.NET Framework 3.5をインストールする場合など、コントロールパネルの「Windowsの機能の有効化または無効化」にて機能の追加をする場合、最新のモジュールを試みるために、インターネット接続に制限のある環境ではエラーとなる。

この場合にはコマンドラインからDISMコマンドを実行して、インストールメディアからインストールする事で回避できる。例えばWindwos 7上で.NET Framework 3.5をインストールする場合には、下記のコマンドを実行する。(D:はインストールメディアのあるドライブ)

DISM /Online /Enable-Feature /FeatureName:NetFx3 /Source:D:\sources\sxs\

参考:Deploy .NET Framework 3.5 by using Deployment Image Servicing and Management (DISM)

低スペックPCを使わせる事の損失・・・

「4年前のPC利用は約35万円の損失」――マイクロソフト「最新PC買った方が得」

古いPC もそうだが、10万円程度の安いPCを買い与えるのも問題で、低スペックなパソコンを従業員に使わせることによる損失というのはすごく大きい。

実際「自宅ならすぐに終わる仕事なのに、会社だとスペックの不足で仕事にならない・・・」等という話をしばしば耳にする。

15万円のPC(Intel Core i5、SSD 125GB、メモリ8GB、モニタ24インチ)を与えれば良いところ、5万円節約して10万円のPC(Intel Celeron、HDD 500GB、メモリ4GB、モニタ17インチ)を使わせる。その結果、例えばファイルを開くのに30秒余計な時間がかかる。

正社員の場合には年収400万円程度でも、間接人件費も含むと時給2,500円程度は支払っている。10秒の人件費に7円。ファイルを開くのに30秒余計に待たせれば20円、一日に20回ファイルを開くな400円、営業日数240日で96,000円になる。5万円の経費節約のために、年間96,000円の無駄なコストを負担し続けている。

もちろん、無闇に高性能なパソコンを買い与える必要は無いが、職務に合わせて最低必要なスペックは考えて与えなくてはならない。

PS1・・・同じ事はインターネット接続でも言える。

PS2・・・参考までに私が見積もるなら、こんな感じ。
CPUを1ランク落としてでも、メモリとSSDを購入した方が、体感速度は早い。
メモリはデュアルチャンネルが有効になるように、必ず2枚となる構成にする。よくよくカタログを見ると8GB x 1枚となっている事があるので注意。デュアルチャンネル有無で20%程度は体感速度が異なる。

事務職・・・15万円前後
CPU:Intel i5
メモリ:8GB
ストレージ:SSD 128GB
モニタ:24インチ(設置スペースがあるならデュアルモニター)

技術職・・・30万円前後
CPU:Intel i5 又は i7
メモリ:16~32GB
ストレージ:SSD 256GB(容量不足時にはHDDを追加)
モニタ:27インチ(設置スペースがあるならデュアルモニター、2台目は24インチでも可)
GPU:そこそこのものを、機械学習とかするなら高スペックのものを。

Office 2019からOffice 365への移行

2018年10月、Office 2019が発売されました。11月にはプレインストールモデルも順次Office 2019に移行していくでしょう。様々な魅力的な新機能の陰に、ひとつ大きな問題が・・・。Office 2019の延長サポートは、Office 2016の延長サポート終了と同じ2025年10月まで。オンプレミスライセンスは後7年でサポート終了し、サブスクリプションライセンスに移行すると言う、Microsoftからの強いメッセージが込められてます。

Office 2019の発売を喜んで、漫然とオンプレミス版の永続ライセンスを使い続けているわけには行きません。Office 2019からOffice 365への移行を真剣に考えなくてはない状況になっています。

Office 365への移行の壁となるのがライセンス料です。オフィスワーク以外の現場では常時パソコンを使っているわけではありませんから、サービス業や小売業、製造業では1台のパソコンを10人程度で共有している事も珍しくありません。Office 365にはデバイスクライアントライセンスが設定されていないので、使用するユーザー数分のライセンス購入を求められます。10人で共有しているなら1台あたり年間108,000円(Office 365 Business)、Office 2016 Standardの2ライセンス分に相当するコストです。実質20倍程度のコストを負担することになります。従業員が1000人いれば年間1,000万円以上のコスト増加です。単純なOfficeの代替としては受け入れられません。

Office 365ライセンス料を抑えるためには

Officeを使った業務の削減

業務報告など定型入力資料のために使っているなら、これをグループウェアやAdobe Readerを使ったフォーム入力に置き換える。

Officeをレポート出力のためのミドルウェアとして使っている場合がある。この場合にはシステム改修して、別のレポーティングツールに移行するのが良い。

Officeの利用を削減すれば、常時パソコンを使うのでは無い従業員について、Office 365ライセンスを購入しないで済ませる可能性がある。

飾らない資料を標準化

資料を綺麗に飾り付けない文化を推奨する。オンラインで使用するWEB版のOfficeならライセンス料を安く済ませることが出来るが、表現力は大幅に制限される。対外的な資料作成の多い営業職以外はOffice 365 Business Essentialsライセンスで済ませる事を検討する。

フルセット(メール、グループウェア、ファイルサーバ、リモート勤務)でOffice 365に移行

単純にOfficeライセンスの移行として済ますのではなく、複数の社内インフラも含めて移行する。グループウェアやファイルサーバ、メールサーバ、内線電話の運用は年間数百万のコスト負担となっているはずである。これをOffice 365 Business PremiumまたはOffice 365 Business Essentialsに付随するExchange、One Drive、SharePoint、Microsoft Teams、Skype for Businessに移行する。

Office 365 Business Essentialsのライセンス料程度は、オンプレミスで動かしていた各サービスを停止する事でまかなえる。

ただしインターネット上のサービスに移行すれば、インターネットへの通信量が大幅に増える事は避けられない。ネットワーク構成への見直しも合わせて実施しなくてはならない。

Microsoft Officeと決別する選択肢

G Suiteに移行する

コストを問題視しているなら、これは無い。G Suiteはエンドユーザーコンピューティングと、セキュリティ監査関連の機能で勝るが、コスト面ではOffice 365 Business Essentialsの方が優れている。

Libre Officeに移行する

デスクトップアプリケーションについてOpen Sourceを導入した例があったが、長期的に上手くいったという話は聞かない。過去に実施した自治体はMicrosoft Officeに戻している。出力イメージが若干異なる、マクロなどに互換性がない、Libre Officeに不慣れな従業員が多数であり教育コストが増える・・・と言った事を考えると現実的な選択肢とはならない。

 

Ubuntu 18.04 LTSにDockerをインストール

Ubuntu 16.04 LTSから18.04LTSに移行すべく準備中。
移行作業に伴うメモなどを残しておく。新サーバは最近のはやりを反映してDockerをベースに構築するぞ。

Ubuntu 18.04 LTSへのDockerのインストールは下記ドキュメントの通りで問題なく動作する。
Get Docker CE for Ubuntu
ただし、2018.06.01時点ではstableリリースはUbuntu 17.06にしか対応しない。step 4.で次のコマンドを実行するときにstableをedgeに変更する。

$ sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   edge"

ビッグデータを扱うための話

Pythonによるデータ加工での大容量csvの扱い」のような質問を見かけたので、回答を載せておく。普通には扱いないサイズの、ビッグデータを処理するための汎用的な話を残しておきます。

ビッグデータを扱うには、元となるデータを一度に処理可能な量(数十MB程度)に分割して処理を行うバッチ処理か、最小単位のデータ(1行)毎に処理を行うストリーム処理の何れかになります。

ビッグデータを処理するための環境として知られているApatch Hadoopは前者を、RDBに対するSQL文の処理などは後者の方法を使っています。

一行ずつのデータに対して処理を行う場合には、バッチ処理でもストリーム処理でも良いのですが、複数の行にまたがった計算処理を行う場合にはバッチ処理でないと難しくなります。例えば時系列にそった移動平均を計算しようとするなら、元となるデータを時系列順に並び替えなくてはなりません。ですが並び替える処理は多くのメモリを使用するため、データ量が多いと一度にはできません。こういう部分はストリーム処理では実装が難しくなります。

またビッグデータの処理では、どのような中間データを出力するかが肝になります。移動平均を算出する場合には「順不同の元データ→各月毎のデータに分割→各月毎のデータを並び替え→月毎のデータを結合→移動平均算出」のように、何段階かのバッチ処理に分ける必要があるでしょう。この時に汎用性を考えた中間データを作成しておかないと、異なる集計を行う場合に最初からやり直すために、多くの時間がかかる事になります。

Hadoopのプログラムを作るときのMap/Reduceの考え方は、Hadoop以外にも適用できるので、ビッグデータを処理する機会があるならば、Hadoopを使ってみることをお勧めします。既存の仮想マシンのイメージをダウンロードして使うなら、インストールに手間もかかりません。開発言語もJavaに限りません。コンソールからの入出力を処理できる開発言語なら何でも使えます。