こんにちは。開発部データエンジニアの遠藤です。現在、私はデータ×テクノロジーでZOZOグループのマーケティングを支援するデータチームに所属して、データ処理基盤の運用などに従事しています。 本記事では、Lookerを用いて運用中のデータ集計基盤をきれいなデータをスマートに取り出せる基盤に改良した件について報告します。 データ集計基盤で燻っていた問題 1. クエリ管理の限界 2. 集計定義に対するデータの信憑性が謎 Lookerは何が良い? ~データガバナンス機能~ LookML データディクショナリ Gitによるバージョン管理 データ集計基盤(改)の設定フロー データ集計基盤(改)でのデータマート更新 まとめ データ集計基盤で燻っていた問題 ZOZOでは、サービスに関するあらゆるデータをBigQueryに集約しています。BigQueryに集約した大量のデータからデータマートとして必要なデータ
アプリをリリースできる状態に保ったまま 段階的にリファクタリングするための 戦略と戦術 / Strategies and tactics for incremental refactoring
TL; DR 以前、社内向けにDocker/Kubernetes入門の勉強会を開催したのですが、今回はそれに引き続き、AWS Fargateに関する勉強会を開きました。 speakerdeck.com 資料の目的 前回の勉強会の資料についてはこちらをご覧ください。 inductor.hatenablog.com 今回の勉強会については、前回Kubernetesに入門してからそこそこ概要を理解した前提で、AWSのマネージドサービスであるECSやFargateの実態や、その特徴について理解してもらうために開きました。 ECS初心者がつまづきがちな、FargateとECSを比較してしまう問題や、そもそもECSというサービスの立ち位置などについて改めて解説した資料となっています。 インフラ向けではありますが、開発者が見てもわかりやすくなるよういくつか前提知識のスライドも含めていますので、もしよけれ
この資料は 11/16(土)開催の勉強会 いまからはじめるReact の資料になります。 React未経験者/初学者向けに チュートリアルを通してReact(およびHooks)について学ぶためのものです。 そのため、サンプルコードには例外処理などが不十分な箇所があります。ご注意ください。 Reactとは? Reactとは Facebookが中心となってオープンソースで開発されている ユーザーインターフェースを構築するためのJavaScriptライブラリです。 (2019/10/30現在、v16.10.2 が公開されています) React – ユーザインターフェース構築のための JavaScript ライブラリ https://ja.reactjs.org/ コンポーネント(部品)を作成し、これらを組み合わせることでSingle Page Applicationのような複雑なユーザーインター
「jQueryはオワコン」「いや、jQueryは便利!」議論が行われるようになってから2年は経つでしょうか。Twitterを観測してると定期的に盛り上がるので、私なりにちゃんとまとめようと思います。 ちなみに結論を先に書いておくと ・ レンダリングブロックしない構成、かつ最新版を使おう ・ jQueryはいいものだけど、脱jQueryした方が手っ取り早い です。 1. 保守しないといけないサポートの切れたjQuery1, 2を使ってるけど、依存プラグインが動くかどうかわからないから最新版にアップデートしていないプロジェクトが散見されます。 jQuery1, 2 は、Officially End of Life(公式に廃止)が名言されてます。ですので、「jQuery におけるクロスサイトスクリプティングの脆弱性」みたいな報告も修正されていません。EOLのバージョンはやめましょう。 ちなみにj
10月29日にリリースされたFedora 31で行われた大きなアップデートのひとつに、Python 2を完全に削除し、PythonコマンドをPython 3にスイッチしたことが挙げられる。そして2020年春のリリースとなる「Fedora 32」では、Pythonのパフォーマンスをさらに向上させるための変更が実施されることになる。 Changes/PythonStaticSpeedup - Fedora Project Wiki これまでFedoraではPython 3パッケージをコンパイルする際には共有ライブラリである「libpython3.x.so」を使用しており、最終的なバイナリは/usr/bin/python3.xに動的にリンクさせていた。だが、libpython3.x.soのかわりに静的ライブラリ「libpython3.x.a」を使ってみたところ、ワークロードによって多少差が出るも
We are going to rewrite React from scratch. Step by step. Following the architecture from the real React code but without all the optimizations and non-essential features. If you’ve read any of my previous “build your own React” posts, the difference is that this post is based on React 16.8, so we can now use hooks and drop all the code related to classes. You can find the history with the old blo
【特集】「『予測』という名の欲望」全記事はこちらから読めます ■人間にはAIの考えが分からない? ――ディープラーニングは、大量の「教師データ」を読み込み、入力する変数と、出力する変数との間の関係を見つけ出します。その関係が分かれば、新たなデータを入力したとき、出力が予測できるというわけですが、なぜ人間はそのプロセスを理解できないのでしょうか? おもにふたつの要因があります。質的なものと、量的なものです。量的な問題は、すごくシンプルです。ディープラーニングの内部で動くパラメータ(母数:システムの内部で動く情報)が多すぎるので、その大量・複雑なデータを人間の直感につなげることが難しい、という話です。最近は、多いものでは1億個を超えるパラメータから出力を予測します。じゃあ、その1億個をざっと人間が見てなにか分かるのかといえば、分からない。これが基本的に起こることです。 ――大量の変数という意味
以下では、DaskやPandasなどと比較して、swifterがどの程度高速なのかを検証したいと思います。 swifterはベクトル化可能な場合とそうでない場合で挙動が異なるので、各々の場合を検証します。 使用したPCのスペックはIntel Core i5-8350U @1.70GHz、メモリが16GBです。 ベクトル化可能な場合 swifterはベクトル化可能なときはベクトル化するので、swifterの計算時間は単純にベクトル化した場合と ほぼ等しくなるはずです。これを確認してみましょう。 import pandas as pd import numpy as np import dask.dataframe as dd import swifter import multiprocessing import gc pandas_time_list = [] dask_time_list
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く