ちょっと実務的な部分に絞って２枚目
データ的な特徴
ログデータ
アクセス数やPV数、UserAgentの解析をしたい。とすれば、ApacheとかのWebサーバーのアクセスログから拾って集めて、分析用のDBに片っ端から突っ込むことになる。
Google Analytics などの外部ツールでもこの系のアクセスログは蓄積できるが、内部で集計するためのデータソースにするには情報量の不足や取得までの仕組みの関係で厳しい。
想像のとおり、非常にデータ量が膨大であるため、どういう単位でデータを残すかが非常に悩ましい部分。しかもApacheのログなんかは、何か問題がった時の調査用にログ出力フォーマットを変えたりする。（ヘッダーサイズ出力とか） 柔軟な設計が試される部分。
保守業務で辛いところ
完全に愚痴
業務領域のデータにまつわる変更が全部分析DBに落ちてくる
インプットデータとして、全領域全システムの全テーブルの面倒を見ることになる。
例えば、業務領域の改修でとあるコード値が入力できなくなったとする。（もう使わないしいらないよね？）とすると、そのコード値がリリース時から分析に落ちてこないようになり、後日集計してから「〇〇コードの最新タイムスタンプがこの日で止まってるけどなんなの？この日以降の実績消えたの？」とユーザー問い合わせがくる。
集計処理の変更が滅茶苦茶怖い
5年も続けて保守してきた分析システムの集計はどうなっているだろうか？ 一つの答えが、「300行SQLの集計が3個ぐらい連なったバッチ」のような、集計結果のチェーン味噌ダレ。
「とある属性値の選択ルールを、コード最小値から画面上で先頭のものに変えました」なんてのがめっちゃ怖い。レコード数増えたり減ったりしない？？集計前後でjoin結果がめっちゃ変わらない？？ ここらへんはなるべくポリシー化してできるならポリシーに従った集計を個別に実施して、レイヤ的な集計を実施していきたいが。。
現在、確認範囲を全て確認していっているが、ここらへんうまく自動化できないものかなと考えている。 自動テストしたい。
