PHPerKaigi2024 の登壇資料です。 履歴データテーブルとの向き合い方 https://fortee.jp/phperkaigi-2024/proposal/47cf9f17-825a-4021-bf33-86e4a62bc222
この記事は MERPAY TECH OPENNESS MONTH の 13日目の記事です。 こんにちは、メルペイ ソフトウェアエンジニアの laughngman7743 です。 メルペイではマイクロサービスにおけるデータストアのデータや、アプリケーションのログを有効活用できるような基盤づくりをデータプラットフォームチームとして行っています。 データプラットフォームではラムダアーキテクチャに基づき、スピードレイヤとして Cloud PubSub と Cloud Dataflow を利用した仕組みに加え、バッチレイヤとして Cloud Composer と Cloud Dataflow を利用した仕組みを構築しています。 この記事ではバッチレイヤのアーキテクチャについてご紹介します。 スピードレイヤのアーキテクチャについては 「GCPでStreamなデータパイプライン始めました」 を参照くださ
挨拶 どうも!BaseconnectのBIチームに所属してます。おこどんです。 弊社BIチームは ユーザー行動のログ化 <=> データ収集・蓄積 <=> データ可視化・分析までの領域を社内で担当しております! 担当領域の都合から、クライアントサイドログ収集関連リソース, ETL, データレイク, データウェアハウス, BIツールなどなどデータ分析基盤周りのインフラリソースの作成と管理も担当してまいりました。 立ち上げから2年ちょっとの歳月が経ち構成も一旦落ち着いたので、弊社の分析基盤周りの構成の歴史・変遷を今回記事にすることとしました! (※社員1人インターン1,2名のチームでずっと作ってきたため、人的リソース依存の課題感や技術選択があります。ベストプラクティスの参考としてではなく、失敗の歴史を温かく見守ってもらえたら幸いです) 黎明期(2020/02~) 〜データレイクという概念の不在〜
VOYAGE GROUP Zucks DSPレポーティング基盤をどのようにして作ったかの話。 https://pages.awscloud.com/JAPAN-event-OE-20210624-AnalyticsModernization-reg-event.html ディメンションモデリング https://zenn.dev/pei0804/articles/dimensional-modeling スタースキーマ(基礎) https://zenn.dev/pei0804/articles/star-schema-design 複数スタースキーマ https://zenn.dev/pei0804/articles/multiple-star-schema ファン・トラップ https://zenn.dev/pei0804/articles/datawarehouse-fan-trap
技術部データ基盤グループの青木です。 ここ1、2年はなぜか成り行きでBFFをでっちあげたり、 成り行きでiOSアプリリニューアルのPMをしたりしていたので あまりデータ基盤の仕事をしていなかったのですが、 今年は久しぶりに本業に戻れたのでその話をします。 突然の1人チーム、そして0人へ…… 今年のデータ基盤チームは消滅の危機から始まりました。 間違いなく去年末は5人のチームだったと思うのですが、 メンバーがイギリスへグローバルのデータ基盤チームを作りに行ったり、 山へ検索システムを直しに行ったり、川へレシピ事業の分析業務をやりに行ったり、 海へ広告のエンジニアリングをしに行ったりするのをホイホイと気前よく全部聞いていたら、 なんと4月から1人だけのチームになってしまいました。 事はそれで終わりません。 恐ろしいことに10月にはわたし自身も育休に入ることになったので、 10月はデータ基盤が0
こんにちは、今年の1月に会員事業部から技術部データ基盤グループへ異動した佐藤です。先日、京まふ2019前夜祭イベントに参加するために人生で初めてピカピカ光る棒を買いました。 新卒で入社してから2年ほど分析作業をしていた身から、データ活用基盤を作る側へ立場を変えました。今回は新たに身を移したデータ活用基盤の外観を説明したいと思います。 2017年にも同内容の記事が投稿されていますので、当時との違いを中心に説明していきます。 外観図 以下が2019年10月現在におけるクックパッドのデータ活用基盤の全体像です。 クックパッドのDWH外観図 masterデータのインポートがMySQL以外にも複数種対応し始めたことと、PrismとSpectrum(S3+Glue)周りと、Tableau Serverが大きな変更点となっています。2017年の図にDmemoはありませんでしたが、記事本文にある通り当時か
前回「第1回」の開催となった「Data Pipeline Casual Talk」、参加レポートについては下記エントリで言及させて頂きましたが、イベントとしては驚異の競争率且つ実際参加した内容も非常に参加者に好評なものとなっておりました。 Data Pipeline Casual Talk - connpass データパイプラインに関する知見をカジュアルに語る! Data Pipeline Casual Talkに参加してきた #DPCT | DevelopersIO その1回目の好評を受けて、早速の「第2回」が予定され、2019年04月17日(水)にイベントとして開催されました。第2回は「ブログ枠」が設けられていましたのでその枠を使って参加を確保。当エントリはその参加レポートとなります。 Data Pipeline Casual Talk Vol.2 - connpass 目次 参加レポ
日本語Wikipediaのダンプデータ中の本文を利用したい。 ただ、単純にパースするだけではWiki記法の記号等が邪魔である。 というわけでWikipedia Extractorを利用して本文だけテキストとして抽出します。 Wikipedia Extractorの他にもパースするためのライブラリはいくつかあるようなので、用途によっては別のライブラリを使用したほうが良さそう。 Alternative parsers - MediaWiki 環境 Mac OSX Yosemite Python v2.7.11 Wikipedia Extractor v2.4 20GB程度のディスク空き容量 出力結果例 抽出処理後に生成されるXMLファイルは下記のようなdoc要素の集まりになります。 <doc>...</doc> <doc>...</doc> ... <doc>...</doc> 具体的な例とし
概要 本記事はWikipediaのダウンロード可能なデータについてまとめたものです。 Wikipediaではクロール行為は禁止されています(ここを見る限りでは)が、代わりに全記事の情報を圧縮したファイルが公開されています。 日本のWikipedia情報ダウンロードページ http://download.wikimedia.org/jawiki/latest/ 本記事は2009年の10月下旬に取得した情報を元に書いています。時間が経つと結果が変わる可能性があるのでご注意ください。 事前情報 2009/10/25に確認した時点では、日本語Wikipediaのダウンロードページには55個のファイルが置いてありました(うち半分は更新を通知する為のRSS)。 ファイルの形式は「XML」、「MySQLのダンプ」、「テキスト」などがあります。 詳しいデータのインポート方法は、こちらのリンク集が参考になる
ElasticSearchにwikipediaのデータを投入する手順.md pluginコマンドのパス /usr/share/elasticsearch/bin/以下(※Ver1.3.2で確認) Elasticsearch-river-plugin HP https://github.com/elasticsearch/elasticsearch-river-wikipedia ※ElasticSearchのバージョンによってインストールするバージョンが異なるため注意 インストール bin/plugin -install elasticsearch/elasticsearch-river-wikipedia/2.0.0 Kuromoji HP https://github.com/elasticsearch/elasticsearch-analysis-kuromoji インストール bi
Apache SolrにWikipediaデータをインポートする手順.md Wikipediaデータダウンロード先 http://dumps.wikimedia.org/jawiki/latest/ ダウンロード&解凍 # wget http://dumps.wikimedia.org/jawiki/latest/jawiki-latest-pages-articles-multistream.xml.bz2 # bunzip2 jawiki-lasest-pages-articles.xml.bz2 コレクションディレクトリ作成 # cd /usr/local/solr/{プロジェクト名}/solr この中の「collection1」ディレクトリがコレクションの本体になる これを任意の名前に変更する 今回はWikipediaのarticleのため、「article」コレクションとする #
$ mysql -u root jawikipedia < jawiki-latest-page.sql $ mysql -u root jawikipedia < jawiki-latest-pagelinks.sql $ mysql -u root jawikipedia < jawiki-latest-categorylinks.sql データが大きくて実行時間は結構かかります。手元のMacでかかった大体の時間を参考までに載せておきます。 jawiki-latest-page.sql・・・数分で終わった。 jawiki-latest-pagelinks.sql・・・10分くらい。 jawiki-latest-pagelinks.sqlは・・・8時間くらい。途中PCがスリープになっていたので本当はもっと早かったかもしれません。 取り込んだデータ テーブル構造 page mysql> d
背景 WEBサービスで駅とか路線のマスター情報とか使いたいときが結構あると思います。自分でマスター管理するのは大変なので、どこかにお願いしたいですよね。そんな時はこちら。 無料 駅データ.jp 無料(有料プランもあり) 事業者マスタ、路線マスタ、駅マスタ、接続駅マスタがCSVで提供されます APIでの提供も用意されています 商用利用やデータの改変についても制約がなく使い勝手が良さそうです 有料契約すると取得できる情報がちょっと詳細になります リクルートWEBサービス 無料 APIでの情報提供になりますが、沿線マスタAPIで全件取得できますので、それをもとにAPIをぐるぐる回せば自分で駅マスターは作れそうです ただ利用者としてリクルート社のコンテンツをマッシュアップしてサービス提供したい人向けのようなので、全く無関係のシステム・サービスで利用しようとしている場合は利用許可がでないかもしれませ
当サイトは2017年12月末でサービス終了です。 ■先物 日経平均先物やTOPIX先物などのデータ 4本値+出来高+売買代金 がCSVダウンロードできます。 セッションごとデータ 日中 ・ 夜間 各銘柄ごとの時系列データ 日夜 ・ 4時間足 ・ 1時間足 ・ 30分足 ・ 15分足 ・ 5分足 ■指数 日経平均やマザーズ指数など株価指数のの4本値データ がCSVダウンロードできます。 セッションごと 日足 ・ 前場 ・ 後場 各指数ごとの時系列データ 日足 ・ 前後場 ・ 1時間足 ・ 30分足 ・ 15分足 ・ 5分足 ■個別株 個別株のデータ 4本値+出来高+売買代金 がCSVダウンロードできます。 セッションごとデータ 日足 ・ 前場 ・ 後場 各銘柄ごとの時系列データ 日足 ・ 前後場 ・ 1時間足 ・ 30分足 ・ 15分足 ・ 5分足 ■市場統計 市場ごと・業種ごと の売買代金
個人情報の利活用の場面において個人情報の匿名化を避けて通ることはできないわけですが、踏み込んだ知識はデータ処理の門外漢には敷居が高く、「完璧な匿名化手法は存在しない」というかの有名な結論については理解できても、そこから進んで「どうするのがベターな匿名化手法なのか」といったことについては今ひとつ理解できずにいました。 そんな中でデータ匿名化手法 ―ヘルスデータ事例に学ぶ個人情報保護の存在を知り、早速読んでみたところ、いくつか腑に落ちたことがあったのでまとめてみます。 匿名化は確率的なものなので、再特定化される可能性をゼロにはできない。(上記の「完璧な匿名化手法は存在しない」と同じこと) 生データを提供することで得られるメリットは、生データを提供することで発生するリスクとのトレードオフ。 問題はリスクがゼロかではなく、リスクを正当化できるか。 データの開示方法、データの開示を受ける人が既に保有
巨大なファイルを使ってディスクやネットワークの速度を測定する ディスクやネットワークなどの性能(速度)がどのくらい出ているかを手っ取り早く調べるには、ある程度大きなデータファイルを用意しておいて、その読み書き速度や送受信速度を調べると簡単だ。 厳密なベンチマークツールがなくても、ファイルをコピーさせながら、その速度をタスクマネージャーやパフォーマンスモニターで見たり、完了するまでの時間を測定したりするだけでも大まかな速度は計測できる。 これを行うには、数十~数百GB以上のサイズのテストファイルが必要になる。本Tech TIPSでは、「fsutil.exe」というコマンドを利用して、こうした巨大なファイルを簡単かつ素早く作成する方法を紹介する。 fsutilコマンドで巨大なファイルを作成する Windows OSで巨大なファイルを作成するには「fsutil.exe」というコマンドがとても便利
うん、気持はよく分かるよ。 例えばフィルターとか超使ってるし、タブをドンドン増やしてハイパーリンクでつないで元データから引っ張ってきて計算して表組みを作成するとかいつもやってるような作業が新システムだと厳しい(=できないor莫大な時間と金がかかる)らしい・・。帳票は固定になりますね、帳票増やすと増やした分だけ金かかります、みたいな感じ。 エクセルでできることができない何百万のシステム・・ うんうん。なんでそんな不自由になるんだろうね。 シンプルに考えましょう。きちんとシステム化されていないものをシステム化するというのは言いかえると「業務プロセスを必要最小限に絞る」ことだと思って下さい。 何のために作るのか 理由はいくつかあります。ざっと上げてみると 属人化した業務プロセスを標準化する(しかし、ある人にとってはいつもどおりだがある人にとっては今までやってたことが全然できないシステムになること
転職して丁度2年がたちました。 現在はWebベンチャーで統計屋しています。大変楽しい毎日です。 なぜ楽しいかというと勿論リスプを書いているからというのも大きなる理由の一つです*1。 このエントリでは何が楽しいのか近況交えてつらつらまとまりなく書いてます。 あと現職の解決しがたい不満についても書いています。 糞長くなってしまったので要約すると 「今糞面白いけど超えられない壁あるので誰か助けて」 です。 現職面白い理由5個。 1.データが面白い*2 私は経済学科・数理統計の研究室出身で、応用先としてコミュニケーション活性化を目的とした 行動経済学やテキストマイニングをやっていました。 そういう背景があるため、学生時代いつか壮大な社会実験をやりたいと思ってたけど、 それには大変なお金がかかったり大がかりなシステムを構築しないといけなかったりで断念した。 ですが今はSNSやソーシャルゲームや広告の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く