はじめに こんにちは。株式会社High Linkのデータユニットマネージャーの芦川 (@assy) です。 私たちのチームでは、データを強みとした事業価値創出を促進するために、データ基盤の整備やデータマネジメント、全社的なデータ利活用レベルの引き上げに取り組んでいます。 データマネジメントをしていると、「誰が作ったかわからない野良のテーブルが乱立している」ことや「BigQueryコンソール上でviewを定義してしまってコードレビューができない」さらには、「テーブル間の依存関係がわからず削除できない」といった課題にぶつかる方は多いんじゃないでしょうか。 私たちもまさにこのような問題に直面し、導入したのがdbtです。 今回は、dbtの導入に至る経緯や選定の理由、dbtをどう活用しているのかといった話を共有させて頂こうと思います。 私たちのようにデータマネジメントにがっつり人的リソースを割けない
大阪オフィス所属だが現在は奈良県でリモートワーク中の玉井です。 dbtは、ELTのTをソフトウェア(またはアプリケーション)と同じように開発することができるサービスです。しかも、SQLのSELECT文さえ分かっていれば、もう早速使うことができてしまいます。 ただし、SQLはいわゆる宣言型言語で、柔軟なデータモデルを作るためには限界があります。そういう時のために、dbtはjinjaという言語が使えるようになっています。 今回はjinjaのチュートリアルを「実際にやってみつつ」、どういう事ができるかをご紹介したいと思います。 そもそもdbtとは?という方へ 下記をご覧ください。 Jinjaに関する公式情報 本家 dbt 本記事では下記に記載されているものを実際にやってみます。 やってみた Projectを新規作成する 今回の作業用に新規Projectを用意します。具体的な方法は上記の別記事をど
ここ数年,クラウドサービスの進歩や扱えるデータの多様性からデータ基盤の構築を推進している企業が多くなりました。また,データ活用/データ基盤の拡張の観点からデータ基盤においてもCI/CD(継続的インテグレーション/継続的デリバリー)を取り入れる必要性が増してきています。 データ基盤におけるCI/CDを取り入れているプロジェクトも多くありますがその多くは基盤環境の構築にのみ対応しておりデータモデリングの部分ではあまり取り入れられていないのではないでしょうか。今回のセッションではデータモデリング部分のCI/CDにもフォーカスしレビューしてからデプロイまでを自動化することを目的としたデータ基盤の構築についてご説明いたします。 以下今回の登場する主な製品です。 ・Snowflake(DataLake, DWH, DM) ・Github(リポジトリ) ・Airflow(ワークフロー管理) ・dbt(デ
はじめに dbtをデータエンジニアリング業界ではよく耳にするようになり、利用方法を調べていた時にdbt Cloudがでてきたものの、よく利用シーンがイメージできなかったのでまとめてみました。 dbtとは dbt(正式名称はdata build tool)とはELTパイプラインにおける「T」に相当する変換処理やデータモデリングを担当するツールです。ELTでのアプローチの場合、データレイクとしてBigQueryやSnowflakeのようなDWHに生データが集約されるため、変換処理をSQLで行う必要があります。 そのツールとして使われる代表格がdbtです。他の候補ではdataformが挙げられますが、2021年5月12日以降、新規登録を停止しています。GCPに買収されてからしばらく経つものの、GCP環境への移行作業がまだ完了しておらず、リソースを集中するための措置のようです。 現在(2022/0
スタースキーマ wikipedia スタースキーマ または 星型スキーマ はデータウェアハウスに利用される最も単純なスキーマである。スタースキーマには唯1つもしくは少数のファクト表と複数のディメンション表が含まれる。スタースキーマはスノーフレークスキーマの一種であるが、多くの用途で利用されている。 スタースキーマは、ディメショナル・モデリングをリレーショナル・データベースで実装したものになる。 詳しくは、ディメンショナル・モデリング にまとめている。 この記事は、あなたが「様々な指標を様々な軸で、レポートを見たい」類の要望に応えるためのスキーマ設計に困っている場合に役立つだろう。 ディメンションテーブル設計 サロゲートキー スタースキーマでは、各ディメンションテーブルに、サロゲートキーを割り当てる。このキーは、業務システムで使われているキー(ナチュラルキー)とは別のものを使用し、データウェ
データ モデルを活用した データ ウェアハウスの設計 Joshua Jones, Eric Johnson 目次 はじめに.................................................................................................................................. 2 データ ウェアハウスの設計.................................................................................................... 2 データ ウェアハウスのモデリング..........................................................................
はじめに 今朝、PL/pgSQLのストアドプロシージャのリリースについては以下のブログにてご紹介しました。さらにPL/pgSQLのストアドプロシージャの開発を具体例を用いて解説します。 Amazon Redshift 待望の PL/pgSQL のストアドプロシージャをサポートしました PL/pgSQLとは 特長 ストアドプロシージャとは 特長 アクセス制御 ストアドプロシージャの作成(CREATE PROCEDURE) 構文 ストアドプロシージャ名 引数の指定 プロシージャ本体の指定 プロシージャ本体 例.2つの入力パラメータを持つプロシージャ 例.1つのINパラメータ、1つのOUTパラメータ、および1つのINOUTパラメータを持つプロシージャ SECURITY属性指定 ストアドプロシージャの削除(DROP PROCEDURE) 構文 例.ストアドプロシージャtest_sp1の削除 ストア
Amazon Redshiftに於いて『パフォーマンスチューニング』は重要なトピックの1つです。Redshiftクラスタを立ち上げて、データを投入して、実際使ってみたものの思ったような速度・レスポンスが返って来ない...という状況も時折遭遇する事と思います。 AWS公式ドキュメント(英語版)を漁ってみると、まさにその『パフォーマンスチューニング』に焦点を当てたチュートリアルが公開されているではありませんか!当エントリではそのドキュメントを参考にひと通り実践してみた内容をまとめてみました。各種手順を1エントリに集約したので超長いエントリとなってしまいましたが、その辺りは目を瞑りつつ実践内容を順を追ってご覧頂ければと思います。 Tutorial: Tuning Table Design - Amazon Redshift: 目次 1.テスト用データセットの作成 2.ベースラインを作るためのシス
……とは言うものの、今回はまだRedshiftに本格的には踏み込みません。Redshift分析環境にインポートし、実際に分析対象としてアクセスする『データ』(ファイル)に関する部分について、やらなければいけないこと、気を付けるべき点を中心に話を進めていきます。分析環境の構築と同様に大事な点であり、労力を掛けるべき点であると個人的に考えている部分です。 分析テーマをピックアップ 今回のようなビッグデータ分析環境を構築するとなった場合、まず間違いなく分析環境を構築するための『元ネタ』ありきで話が進んでいるものと思われます。『現在稼働中の△△△システムで日々生成されている◯◯データや※※※のログをこういう風に見てみたい/分析して業務に役立てたい』『今度リリースする◯◯のシステムで、こういう情報が取得、生成されるのでそのデータを分析してみたい』などです。 そのような環境の場合、先行してまずは1つ『
Amazon Web Services ブログ 【開催報告】AWSで実践!Analytics Modernization ~事例祭り編 第三回~ 2022年9月22日に「AWSで実践!Analytics Modernization ~事例祭り編 第三回~」を開催しました。今回の事例祭りではAWSのAnalyticsサービスをご利用いただいている The ROOM Door 株式会社様、IQVIA ソリューションズ ジャパン株式会社様、株式会社カヤック様、株式会社デンソー様、ディップ株式会社様にご登壇いただきました。本ブログでは当日の各発表内容を紹介いたします。 Serverlessで始めるAWSのAnalyticsサービス — Serverlessサービスのご紹介&デモ アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト, アナリティクス 平間 大輔 まず、AWS の
環境 MAC OSX 10.10.5 Yosemite 使い方(例) テーブルの準備 CREATE TABLE items ( id SMALLINT , name VARCHAR(16) , item_id SMALLINT , item_name VARCHAR(16) , PRIMARY KEY(id, item_id) ); INSERT INTO items VALUES (1, '文房具', 1, 'シャーペン') , (1, '文房具', 2, '消しゴム') , (1, '文房具', 3, '定規') , (2, 'かばん', 1, 'リュックサック') , (2, 'かばん', 2, 'ショルダーバッグ'); CREATE TABLE genre ( id SMALLINT , name VARCHAR(16) ,PRIMARY KEY(id) ); # SELECT *
はじめに こんにちは、この記事はUnipos Advent Calender 2021の16記事目です UniposではデータをDataStoreとSpannerにもち、それらのデータを集計するためにBigQueryにデータを転送しています この記事ではSpannerからBigQueryへのデータ転送について紹介します 公式ドキュメント に詳しいことは書いてありますが、このブログでは具体的な操作、具体的な値について書いていきます 事前準備 BigQuery Connection APIを有効にする Spanner情報の追加 BigQueryのエクスプローラの「3点リード」→「データを追加ボタン」→「外部データソース」の順にクリック 情報を入力する 接続タイプ : Cloud Spanner 接続ID : 英数字、ダッシュ、アンダースコアで構成される文字列 データのロケーション : BQのロ
はじめに おはようございます、もきゅりんです。 皆さん、Glue 使ってますか? Glue は恐ろしいやつです。 影の支配者です。 なぜなら Athena や LakeFormation は Glue の恩恵によって存在しているといっても過言じゃないからです。 (LakeFormation は Glue の拡張機能だと公言されていますし) そんな Glue ですが、自分は何度読んでみても便利な機能っぽいんだけど、何だか分かったような分からないような気になってました。 今回はそのモヤモヤ感を払拭すべく、使い方からではなく、機能と構成要素からイメージを整理しようと考えました。 想定される読者としては、自分と同じように、 Glue が何かいい感じにETLしてくれるのは知ってる...けどよくイメージ湧いてない、という方、または Glue 全然知らないけど、 どんなものか興味がある、という方も OK
先日(日本時間の)2017年08月15日にAWS Summit 2017 NYCでアナウンスされたフルマネージドETLサービスの「AWS Glue」がついに一般利用開始となりました。早速色々触ってみたいと思っておりますが、サービスの特性上色々なサービスと連動させる必要があり、またAWS Glueを構成する各種要素も幾つか存在しているようで、サクッと作成・設定・実行!...という訳には行かなさそうな雰囲気です。そこで当エントリでは、実際にAWS Glueを使ってみる前に、AWS Glueの概要や構成要素について内容を把握してみたいと思います。 目次 AWS Glueの(ざっくり)概要 AWS Glueのユースケース AWS Glueの仕組み・構成要素 まとめ AWS Glueの(ざっくり)概要 AWS Glueはフルマネージド且つサーバレスのETL(抽出、変換、ロード)サービスです。以下の構
本記事では、データマネジメント・ガバナンスの推進に使えそうなAWS Glueの機能を考察していきます。 「激熱!1日1製品!最強のデータ系SaaSはどれだ決定戦」アドベントカレンダーにて、これまで20の商用製品を取り扱ってきましたが、ついにネタ切れとなってしまいました…(涙)。候補として挙げていた製品は多いものの、トライアル環境を簡単に提供してくれるところがそこまで多くなかったのが現実でした。 というわけで、21本目と22本目ではクラウドベンダー製のデータカタログについて改めて見ていくことにします。本日はAWS Glue編です。 AWS Glueの機能をおさらい AWS Glueはデータ分析基盤のETLワークロードを構築するためのサーバレスサービスです。主な用途として以下の4つが挙げられます。 データウェアハウスまたはデータレイク用に、データの整理やクレンジング、検証、フォーマットを行う
本記事では、分析基盤の総合支援ツール trocco の紹介とデモを実施していきます。 本アドベントカレンダー唯一の日本発の製品です。この度特別にトライアルの機会をいただけましたので、DevelopersIOにてtroccoの機能をご紹介していきます! troccoについて troccoを開発・提供するprimeNumber社は、2015年に東京で創業されたスタートアップです。つい先日約13億円の資金調達のアナウンスもありましたし、日本のデータエンジニアリング界隈では知っている方も多いテックカンパニーでしょう。 データ統合自動化サービスtroccoなどを手がけるprimeNumberが約13億円のシリーズB調達、採用・マーケ強化 | TechCrunch Japan troccoの日本発であるという強みを活かした日本語ネイティブのUIやサポート体制が、日系企業にとっては一番嬉しい特徴になるで
フィードバックを送信 Data Catalog の概要 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 Dataplex の Data Catalog 機能は、組織のデータアセットの統合インベントリです。Data Catalog は、 Google Cloud ソース(BigQuery、Vertex AI、Pub/Sub、Spanner、Bigtable など)からのメタデータを自動的にカタログ化します。Data Catalog は、検出によって Cloud Storage のテーブルとファイルセットのメタデータのインデックス登録も行います。 Dataplex の管理された組織全体のメタデータ検索機能を使用すると、データを検出できます。重要なビジネス コンテキストでメタデータをさらに拡充し、リネージ追跡、データ プロファイリング、データ品質チェック、アクセ
本記事では、データマネジメント・ガバナンスの推進に使えそうなGoogle Data Catalogの機能を見ていきます。 「激熱!1日1製品!最強のデータ系SaaSはどれだ決定戦」アドベントカレンダーにて、これまで20の商用製品を取り扱ってきましたが、ついにネタ切れとなってしまいました…(涙)。候補として挙げていた製品は多いものの、トライアル環境を簡単に提供してくれるところがそこまで多くなかったのが現実でした。 というわけで、21本目と22本目ではクラウドベンダー製のデータカタログについて改めて見ていくことにします。本日はGoogle Data Catalog編です。 Google Data Catalogの機能をおさらい Google Data Catalogは、Google Cloudで提供されるデータ検出とメタデータ管理のためのサービスです。システム向けのメタストアというよりかは、デ
はじめに 本記事は、AWSの公式ドキュメントAthena と AWS Glue を併用する際のベストプラクティスを参考に、Athena、Glue間のデータ連携について検証する記事になります。 わかりにくいワードを記事最後尾にまとめております。記事の目次から各ワードの解説へ飛べます。 読んでいる途中でわからないワードがあったら、目次から探してみてください。 本記事は数部にわたり、投稿してまいります。 投稿した記事を順次、以下に追記してまいります。 今回はまず、ベストプラクティスを学ぶ前にGlueとAthenaを触ってみる回になります。ベストプラクティスについては#2で学んでまいります。 Amazon Athenaとは AWSの提供するインタラクティブなクエリサービスです。Amazon S3 内のデータを標準 SQL を使用して簡単に分析できます。 AWS Glueとは AWSの提供するフルマ
はじめに アプリ開発では、使用状況を可視化したいという要求がよくあり、 事前に運用を想定して分析しやすいようなデータベースへのデータ格納にすることができていればよいのですが、最初はスピード優先やミニマムに開発してといったプロジェクトの場合、 JSONデータをスキーマレスで格納してしまうといったことがあるかと思います。 その場合、通常はDBからデータを取得して、 ログイン回数やUU数、アプリの各種イベントの状況、ゲームの達成状況など、 分析用に加工処理して出力する部分のプログラミング開発が必要かと思います。 Glueを使えば、DBからのデータ抽出部分のプログラミングが不要になり、 Athenaを使えば、分析用の加工をSQLで行え、 QuickSightを使えば、表示用のWebフロント側をプログラミングする必要がない、 ということで、やってみました。 DynamoDBのデータを分析できるように
AWS Glueをざっくりと理解するために基本的な概念とコンポーネントを、図と用語で整理してみます。 AWS Glueとは? フルマネージド・ETL&データカタログツール ETL = どっかからデータ引っ張って、いい感じに変換してどっかに突っ込むこと データカタログ = データ活用をしやすくするためのメタデータの目録 ざっくりとした概念図 特徴 サーバレス 高セキュリティ etc.. 用語 データストア S3, DynamoDB, RDBなど データソース Glueへの入力に使われるデータストア データターゲット Glueからの出力に使われるデータストア データカタログ(Data Catalog) Glueを利用するための箱 ジョブ、メタデータ(データベース,テーブル)などGlueに関わるコンポーネントはすべてここに含まれる 1AWSアカウントの1リージョンにつき、1データカタログ データ
データの分類、クリーニング、加工を行う、 フルマネージドなETL(Extract(抽出)/Transform(変換)/Load(ロード))サービスです。 分析用のデータ準備やロードを簡単に行うことができ、日々のETL処理を自動化・サーバレス化が可能になります。 データカタログに保存されると、データがすぐ検索でき、クエリ可能にもなるのが特徴です。 メリット 迅速なデータ統合 Glueで抽出、クリーニング、正規化、結合、読み込み、ワークフローの実行など行うことができ、 分析までにかかる時間を数ヶ月から数分に短縮できます 大規模なデータ統合を自動化 いくつものETLジョブを実行・管理ができ、 SQLを使用して複数のデータを結合できます。 サーバー管理が不要 フルマネージドサービスなのでサーバレス環境で実行できます。 用語 データストア s3やDynamoDB,RDS等 データソース Glueに入
はじめに こんにちは、情報戦略テクノロジーの小林と申します。 今回は初めて記事を書くということで、私が最も実務で触れているバッチ処理におけるlambdaとglueについてまとめることにしました。 ちょっとだけAWSを触ったことがある方に向けて、このふたつの違いを説明し、「じゃあどっちを使えばいいの?」に答えたいと思います。 前提条件として、どちらも時間起動でpythonコードを動かしているものとしています。 根本的にlambdaとは、glueとはなにかを知りたい方は以下のリンクをご参照ください。 https://aws.amazon.com/jp/lambda/ https://aws.amazon.com/jp/glue/ というだけだと寂しいので、キャラクターに見立てて一言書いていきます。 せっかくなので、この子たちはこの後も説明に登場させようと思います。 ちなみにこれらはラノベツクー
山陰の日本酒がすきな内立(@b1a9idps)です。2023年1月から STORES 決済 の開発部門のシニアマネジャーを担うことになりました。 マネジメント業務をはじめて1年が経ったので、やってきたことや自分自身の心情について思い出せるように書き残しておこうと思います。はじめたての頃に思っていたことはこちらにあります。 note.com 経歴 かんたんに自分の経歴を説明します。現在、STORESではマネジメント業務が中心ですが、副業ではがっつりJavaを書いています。 入社して4年7ヶ月 入社~3年半:STORES 決済 のバックエンドエンジニアとして開発業務を行う 3年半~4年半:バックエンドチームのプレイングマネジャーを担う マネジメントをはじめて1年経っての所感 マネジメントをはじめて1年の間の、チームの課題の洗い出しから解決に向けて実行したことや自分がマネジャー・シニアマネジャー
実家を出て30年以上経つが、きょうまでエアコンのフィルターの掃除をしたことがなかった。エアコンのフィルターを掃除すると効果が段違いであるという話はインターネットの黎明期から何度も目にしてきたのだが、今でいう「秒で消える唐揚げ」などと同様だと考えていたのである。この「秒で」の長さは、定義では60秒を超えることはないはずだ。60「秒で消える」唐揚げがあったとしたら「分で消える唐揚げ」と呼ばれるだろう。では20秒はどうだろう。1分以下ではあるものの、「秒で」と言ったときに想起するイメージからは遠い。それなら、「数十秒で消える唐揚げ」と呼ぶ方がふさわしいと感じるからだろう。「秒で消える唐揚げ」における「秒」とは、最長でも9秒ではないかと思う。そして、「秒で消える唐揚げ」が実際に9秒以内に消えるかというと、そこも非常に怪しい。まず「秒で消える唐揚げ」は、揚がって盛りつけられた直後からカウントアップが
ふと気づいたら、私は日々コンピューターに囲まれている。物理的にパソコンやスマートフォンだけでもたくさんあるが、仕事ではクラウドを扱っていて、多数のサーバーを受け持っている。毎日会話する人間より、コマンドを叩いているサーバーの数のほうが断然多い。 小学二年生のときに、親が気まぐれで買ってきたパソコンを手に入れたときから、きっと方向性は決まっていて、コンピューターのことが心底好きなんだと思う。そのころはコンピューターに触るのも大変で、大人になったらたくさんパソコンを触りたいという夢は、完全にかなっている。 あるサーバーエンジニアに関する記事を見た。コマンドを覚えるのが大変で病んだのだとか。そりゃコマンドだけで言えば世の中には無数にあって、すべてをソラで入力できるようになるのはそりゃ大変だろう。私もほんの一部しか記憶にはない。 でも、そんなに頭の中に記憶してなくたって、一度使えばどんなコマンドか
マスタリングLinuxシェルスクリプト 第2版 ―Linuxコマンド、bashスクリプト、シェルプログラミング実践入門 作者:Mokhtar Ebrahim,Andrew MallettオライリージャパンAmazon 令和最新版のシェルスクリプトの入門書とリファレンスがセットになった1冊。手元に置いておくと安心感ありますよね。 令和最新版なので、冒頭からデバッグしたいならVisual Studio Code がオススメ、と出てきます。 コンテナ使おうと思ったらシェルスクリプトの読み書きの出番がどんどん増えていって、コンテナに一番必要なスキルはシェルスクリプトのスキルでは?と思っている今日この頃です(違います)が、そのくらいの用途に必要な要素は全部盛り込んであり、シェルスクリプトの文法と実践的な使い方に加えて、一緒に利用されることの多いgrep、awk、sedといったコマンドの解説も併せて載
スタートアップのエンジニアの交流や知見の共有を目的とする、AWS Startup Community 主催の技術系オンラインイベント「AWS Startup Tech Meetup Online #5」。ここで、株式会社カケハシの福田氏が、「スタートアップにおけるデータ基礎バッチワークフローの変遷」をテーマに登壇。バッチワークフローの課題と、変更後の運用を紹介します。 自己紹介 福田貴之氏(以下、福田):「スタートアップにおけるデータ基礎バッチワークフローの変遷」と題して、株式会社カケハシの福田が発表します。自己紹介です。株式会社カケハシで、データ基盤のプロダクトオーナー兼エンジニアやってます。 経歴としては、2007年新卒で、某Yでモバイル向けサービス開発・運用などをやり、あとソーシャルゲームが流行っていたので、そのあたりでログ基盤を6年ぐらい見ていました。あとベンチャーをいくつかまわっ
はじめに こんにちは!LOGLY 開発グループでサーバサイド開発を担当している細野です。 日々主にRuby on Railsや Perl を用いた開発を行っていますが、昨年末あたりから4月までインフラ周りをメインで担当していたため、最近はTerraformやYAMLの記述量が多めになっています。 また昨年子供ができ、子育てに忙しい毎日を送っています。その中でいかにテクノロジーのキャッチアップを行うか、時間の効率的な使い方を絶賛模索中です。 2020年1月〜3月にかけて、当社開発チームメンバー6人で新バッチシステムを構築しました。 そこでせっかくの機会なので、今回は現状の課題と、課題を踏まえた新システムの技術選定過程をまとめました。 長くなったら申し訳ありませんが、お付き合いいただければ幸いです。 LOGLYバッチのいま バッチ実行はcronで管理しています(約40件)。 $ crontab
Treasure Data社によってOSSワークフローエンジン『Digdag』はその発表以後多くの反響を呼び、社内外を含め良く利用されるようになってきていますが個人的には下記の『試してみた』エントリ以降、あまり触って来ていませんでした。ちょっと個人的にも腰を据えて取り掛かってみようかという感じになってきましたので、仕組みや使い方を把握するという意味で一番参考になるであろう公式ドキュメントの一部を読み進めてみた記録をブログエントリとして残しておきたいと思います。 Treasure Data社のOSSワークフローエンジン『Digdag』を試してみた #digdag | Developers.IO Digdagのアーキテクチャ Digdagによるワークフローの自動化 ワークフローを使って、手動で行なっているあらゆる操作を自動化出来ます。一連のタスクを『ワークフロー』として定義し、Digdagを使
Digdag が Apache License 2.0 の元でオープンソース化されましたよ! さぁ試すんだ…! 今すぐにでも! https://t.co/Uzc4a5GLCe ドキュメント:https://t.co/PF8wy5KHln — Sadayuki Furuhashi (@frsyuki) 2016年6月15日 という訳で試してみました。注目度の高かったワークフローエンジン『Digdag』がついにOSS化されました!Githubリポジトリ及びドキュメントは以下となります。 treasure-data/digdag: Workload Automation System Getting started — Digdag 0.8 documentation 目次 インストール 環境の準備 Digdagのインストール実施 その他ドキュメントの内容について Digdagサンプルワークフロ
皆様いかがお過ごしでしょうか。こんにちはエンジニアの堀江です。aumoでは主に推薦エンジンなどを担当しています。 気がつけば年度も半ばで時が経つのは早いものですね。パラリンピックが終わった後の下半期は何が流行るでしょう?私はスラッシュメタルが流行ると思います。 ETL導入の動機 aumoの推薦エンジンの根幹は機械学習が主となります。(一部ルールベースも掛け合わせています。早く断捨離したいですね。) 効率的な学習や推論を行うためには、予め目的に沿った整えられたデータカタログが不可欠になると思います。 これまでのaumoにはETL/DWH基盤がなく、推薦エンジン側の実装でデータカタログを準備していたので、下記の問題を抱えていました。 推薦ロジック到達前のデータ準備で時間を要してしまう。開発時が特に辛くて待ち疲れするし、開発速度も渋る。 データ抽出と推薦ロジックが混在した実装になってしまっている
はじめに データ戦略室データエンジニアリンググループの楊と申します。2021年2月に中途入社して2ヶ月が経ちました。前職はSIerでSEを務め、データベースの運用や新ソリューションを創出するためのデモアプリ開発をしていました。データベースの仕事に携わっているなかで、データを取り扱うのが面白いと思い、データエンジニアに転職しました。 データエンジニアリンググループでは、データ基盤構築やデータ活用方法の設計と整備など、データ収集とデータ蓄積に関わる業務を主に行っています。 今回は、入社2ヶ月の間に、データエンジニアとして試行錯誤したことをいくつかご紹介します。 ぶつかった壁と試行錯誤 2ヶ月間、データ基盤の機能追加やデータ抽出など様々な仕事を経験しましたが、そのなかで1番苦戦したのは、データソースのデータとBigQueryに移行したデータを比較して差分を表示するプログラムを作ったことです。 設
こんにちは、MA基盤チームの田島です。私達のチームでは複数のワークフローエンジンを利用し、メールやLINEなどへの配信を含むバッチ処理を行っていました。今回それらのワークフローエンジンをすべてDigdagに統一しました。そして実行環境としてGKEのAutopilot環境を選択したことにより、柔軟にスケールするバッチ処理基盤を実現しましたのでそれについて紹介します。 また、その中で得られた運用Tipsについても合わせて紹介します。 目次 目次 Digdag on GKE Autopilotの構成 Digdagの4つの役割 Worker Scheduler Web API Kubernetes Command Executor Workerでのタスク実行の問題 Command Executor Kubernetes Command Executorの利用 GKE Autopilot環境でのKu
最近では『マルチクラウド』環境で仕事を回すというのも珍しい話では無くなって来ました。クラウドプラットフォーム間を連携するというのも普通に挙がってくるテーマかと思います。 そんな『マルチクラウド』の環境間で『データの移動』という部分について考えてみた場合、ざっと見てみた感じだと『AWS』から『GCP』については比較的情報量が多いなという印象を受けました。GCPが公式で『AWS向け』のドキュメントを展開しているというのも大いに関係しているかと思います。 ですが一方で、『GCP』から『AWS』という逆のパターンだとどうでしょう。AWSが個別に『GCP向け』の情報を展開しているというのは現状無さそうです。また、その他情報源についてはどうでしょうか?感覚値的には『AWS→GCP』程は情報量的に多くないのでは、という感じがします。 そこで当エントリでは、『GCP(Google Cloud Platfo
はじめに こんにちは、@shase です。 スタディサプリでは、データパイプラインのツールとして、従来 AWS Kinesis Stream や、Embulk や、AWS Lambda などがよく使われてきました。 ただ、現在開発中のプロジェクトでは、システム間の連携の為、Cloud Pub/Sub が多用されているということもあり、データパイプライン Cloud Pub/Subとの親和性が高いCloud Dataflowを一部取り入れています。 本記事では Cloud Dataflow 自体は詳述しませんが、簡単に説明させていただくと、Cloud Dataflowとは、GCP が提供するマネージドな Apache Beam の実行環境になります。 Cloud Dataflow のメリット Cloud Dataflow(Apache Beam)には、以下のようなメリットを感じています。 ス
メルカリのバックエンドを支える SRE(Site Reliability Engineering) チームに最近加わりました @syu_cream です。 本記事では KPI に関わる数値を計算してレポートを生成する集計システムの刷新に取り組んでいる話を紹介します。 現在は刷新の途中であり、集計項目ベースでいうと 1/3 ほどの実装が済み、現行システムと刷新後のシステムの一部を並行稼動させている状態です。 背景 メルカリではアプリケーションのログファイルやデータベースから、 DAU(Daily Active Users) などの KPI に関する様々な数値を集計するためのシステムを稼働させています。 この集計システムは毎日 Slack やメールにて KPI のサマリーレポートを送信し、全社員が数値を閲覧し、日々プロダクトの傾向を意識することを可能にしています。 集計システムの動作イメージは
個人的に作っているETLツールの紹介をします。 分散処理可能なバルクデータローダ 最近、CSV等のテキストベースのファイルをBigQueryへデータロードする際にEmbulkを使っているのですが、短納期のデータ分析案件で、長時間掛かるデータロードが途中で失敗すると詰んでしまう場合があります。 Embulkのスループットを上げる方法がないか調べたところ、MapReduce Executorというプラグインがあるもののv0.9.18からサポートされなくなっています。 また、分散処理可能なバルクデータローダとしてApache Sqoopというのもありますが、Hadoop基盤を使ってRDBからHDFSやGoogle Cloud Storage等にデータロードができるものらしく今回の用途と合いません。 ちなみに、急ぎの時はApache Beamを使ってデータロード処理のコードを書いて、Google
次世代システム研究室の Y.I です。 Google Cloud Platform (GCP) の B「BigQueryにデータを登録する方法」についてまとめます。GCPで一番知名度のあるサービスはBigQueryなのではないでしょうか。まずはBigQueryにデータを登録しないと集計や分析やMachine Learningを行うことができません。今回は以下のデータ登録方法をご紹介します。 BigQueryデータ登録方法 Google Console bq コマンド Google Dataflow Google Functions Embulk まとめ 今回のまとめです。 GCPから多様な手順が提供されている GCP以外の環境からデータ登録するのは Embulk がおすすめ Google Console GCP の Cloud Console で BigQuery の操作をブラウザから行え
この記事では、Airbyte の Change Data Capture(CDC)の機能を用い、MySQL から PostgreSQL にデータをレプリケーションしてみます。また、裏で DB に流れているコマンドについても簡単に確認してみます。 1. はじめに ある DB(ソース DB)から別の DB(ターゲットDB)にデータを継続的に移動するというのは様々なユースケースで必要とされ、現時点では ETL 処理などのバッチ処理で実装されることが多いです。ただし、バッチ処理に関しては、以下のような問題もあります。 対象テーブル数が多い、処理内容が複雑などの理由で、開発に時間と手間が掛かる。 例えば ETL 処理を1日に1回実行する場合、ターゲット DB への最新データの反映は最大1日遅れる。 バッチ処理以外のデータ移動のアプローチとして Change Data Capture(CDC)がありま
はじめに 私の現在の所属部署では、オブザーバビリティの一環として組織やサービスの各種KPIを自動で可視化することで、組織やサービスの状態をいつでも確認できるように進めています。 このためには利用している各種サービスや提供しているサービスからデータを収集、蓄積、加工、分析、可視化する基盤が必要となります。この基盤はKPIだけではなく様々なデータを収集し可視化する際の基盤として汎用的に利用することができます。 本記事は各種データを可視化する基盤をどのように構成しているか、全体のデザインとその工夫点を説明します。 基盤のビジョン できるだけ簡単に構築、設定でき、継続的に改善できるようにする なるべく汎用的で安価にする エンジニアによるエンジニアのためのシステムにする 構成するためのサービス、ツール Airbyte: 各種サービスのデータを収集するOSS Grafana: データを可視化するOSS
目次はじめに従来のデータ基盤(構想段階)3つの問題と解決策の振り返り問題1:データ変換処理の分散化解決策問題2:データパイプラインのワークフロー管理解決策問題3:手作業によるインフラ構築の負債化解決策データ基盤の今後の展望はじめにはじめまして。2021年の6月からYOJOのBI (Business Intelligence) チームでデータエンジニアとして働いている 古家 (@enzerubank) です。 突然ですが、みなさんデータ基盤を開発したことはありますか? 私はYOJOに来るまでは無く、社内にも知見のあるメンバーがいなかったため、技術責任者の上野と一緒に学びながら、四苦八苦して作り上げていきました。 本記事ではデータ基盤の構築についてここ半年くらいで試行錯誤したことを振り返っていきたいと思います。 従来のデータ基盤(構想段階)私がジョインした時に構想されていたデータ基盤がこちらで
技術部データ基盤チームに所属しているまつもとです。ペパボではGoogle Cloud Platform(以下 GCP)をメインで利用した社内データ活用基盤「Bigfoot」を開発・運用しています。BigfootはBigQueryによるデータウェアハウス・データマートを各部署へ提供することが大きな役割となっています。BigQueryへのETLはGCPのワークフローオーケストレーションサービスであるCloud Composerによって構成しています。データのExtractとLoadは基本的にEmbulkとStitchを利用していますが、対応していないデータソースについてはPythonでExtractとLoadのコードを個別に実装しています。 新たなデータソースに対応するために都度ETLを実装するのは非効率であるため、最近急速に対応データソースの数を増やしているOSSのETLシステム Airby
導入 こんにちは、データ分析PJTの縄司です。 寒気の流入が顕著になり、西高東低な気圧配置が頻繁に見られる冬が訪れてきましたね。今年は寒くなるのでしょうか?気になった方はAOI(北極振動指数)やエルニーニョ現象、ラニーニャ現象の詳細をぜひご覧になってください。肌の潤いは失われビニールの袋を開けるのに苦戦する日々を送っています。 さて今回は弊社データ分析基盤刷新のお話しをさせていただきます。 内容 従来のデータ分析基盤アーキテクチャ 弊社のデータ分析アーキテクチャは上のようになっており、MySQLやBigQueryで集めたデータをRedashに集約してデータの分析・可視化を行なっておりました。異なるデータソースを結合するQuery Resultsや豊富なチャート機能は便利ですが、日頃データ抽出やデータの整合性を確認する時にどのクエリを見ればいいの?といった疑問が業務の中でたくさんありました。
概要 ここ最近では、コロナの影響もあり、急速にIT化やDXを推進する企業が増えています。 そのような中、CRMやSFA、広告データを統合し、BIツールにて分析・可視化するニーズも高まっています。 しかし、このようなデータ統合を行うにはデータエンジニアが基盤を構築する必要があり、非常に手間がかかります。 そのような手間を解決するために、自動化して可視化する方法をまとめました。 以下の方法は全て troccoを使って、対応しています。 今なら2週間の無料トライアルも実施しているので、このような手間でお悩みの方は一度試してみてください。 CRM・SFA BigQueryに統合 SalesforceのデータをBigQueryに自動同期して、データポータルで可視化する kintoneの営業データをBigQueryに自動同期し、Googleデータポータルで可視化する HubSpotのデータをBigQu
はじめに 当社ではデータ分析基盤改善の一環としてtroccoを導入しました。 この記事ではtrocco導入により何がどのように改善されたのかをまとめて記載します。 0. troccoとは troccoはEmbulkをSaaS版にしたようなサービスです。各種ストレージ、SaaS、DBなどのデータ転送をWEBのGUI上で設定、管理することができます。それ以外にもRedshift/BigQueryへのクエリ発行やtrocco上のジョブの管理等の便利機能もあり非常に使い勝手が良いのが特徴です。 1. trocco導入を検討した理由 当社ではプロダクション用DBのコピーをBigQueryに転送し分析に用いているのですが、この転送部分に対処しにくい2点の問題があった為troccoへの乗り換えを検討しました。詳細は以下の通りです。 1.1 Embulk+digdag on EC2の運用問題 当時の構成で
Embulkのマネージドサービスtrocco体験記(1): Embulk exampleファイルをBigQueryにロードする この文書について この文書は、株式会社primeNumberが提供するEmbulkのマネージドサービスtroccoをつかってみた体験記です。 そもそものきっかけ 私はEmbulkがリリースされた2015年1月の直後にEmbulkのまとめを作ってその動向をみてきました。そういう中でprimeNumberの方からtroccoを使ってみてと話をいただきました。Embulkのマネージドサービスということでtroccoには前々から興味があり是非使わせてくださいとお願いしました。今回の記事はその第一弾になります。 troccoとは Embulk + αのサービスが利用できる株式会社primeNumber社のマネージドサービスです。 Embulkとは 2015年にfluendや
Airbyteはやはり良さそうだなぁ・・・ EmbulkもローカルGUIがあったっけ・・あればいいんだけどね。dockerであれば、サーバにすぐ乗っけられる ・・ていうと、Airbyteはやはり最先端なETLツールでいいなぁ — がく@心も、ふくよかに (@gak_t12) February 3, 2022 と紹介されており気になってました。 「へーーーー」知らないツールだ…と思い、調べて見ると…数多くのコネクターが提供されている素敵なツール! 「Tableau Prepのコネクター提供されていないHubspot やStripeもBigQueryにデータを送り込みたい」 という直近ニーズと合致しました。 そして検証した結果、そこまで時間を掛けずに実装できました。 ただ、日本語ドキュメントが少ない範囲なので備忘録兼ねてnoteに書きます。 環境Windows11、16GB、Git&Docke
技術部データ基盤チームに所属しているまつもとです。ペパボではGoogle Cloud Platform(以下 GCP)をメインで利用した社内データ活用基盤「Bigfoot」を開発・運用しています。BigfootはBigQueryによるデータウェアハウス・データマートを各部署へ提供することが大きな役割となっています。BigQueryへのETLはGCPのワークフローオーケストレーションサービスであるCloud Composerによって構成しています。データのExtractとLoadは基本的にEmbulkとStitchを利用していますが、対応していないデータソースについてはPythonでExtractとLoadのコードを個別に実装しています。 新たなデータソースに対応するために都度ETLを実装するのは非効率であるため、最近急速に対応データソースの数を増やしているOSSのETLシステム Airby
データローダとしてはEmbulkが有名で普段からお世話になっている。個人的には、並行処理など備えていてとても便利なツールだと思う。一方で、エラーの解析が少し難しかったり、プラグインは基本Javaで書くことになるので気軽に作れなかったりする。一方で、SingerやAirbyteはPythonやTypeScriptで気軽にプラグインが作れたり、比較的デバッグがしやすいイメージがある。 ただし、Airbyteは複数のサーバによって構成されていてデプロイや運用に手間が掛かる。今までEmbulkやSingerで実装していたものをAirbyteへ移行するとなるとデータパイプラインの設計を大きく変える必要が出てくる。また、SingerはEmbulkの代わりになるが、プラグインの開発が停滞しているものが多い。 こういった状況から、SingerのようにシンプルなアーキテクチャのCLIベースのデータローダを作
FROM openjdk:8-jre-alpine # Embulk 本体をインストールする RUN wget -q https://dl.embulk.org/embulk-latest.jar -O /bin/embulk \ && chmod +x /bin/embulk # 使いたいプラグインを入れる RUN apk add --no-cache libc6-compat \ && embulk gem install embulk-output-td WORKDIR /work ENTRYPOINT ["java", "-jar", "/bin/embulk"] 躓いたポイントが2点。 FROM openjdk:8-jre-alpine だと embulk gem install で失敗する flock unsupported or native support failed t
みなさん、こんにちは! プログリットでエンジニアマネージャーをやっている島本です。 この度、プロダクト開発部でブログを始めることになり、その最初としてプログリットのプロダクト開発部のエンジニアがどんなことをやっているのか紹介させてください。 プログリットについてプログリットは 世界で自由に活躍できる人を増やす というミッションを掲げ、英語コーチングを提供しているスタートアップです。 短期集中で習慣化させ、長期的な成長へ 英語学習でやりがちなのが、自信が持てない勉強法で中途半端に取り組むこと。結果、成長を実感できず、いつの間にか挫折してしまう。そんな経験ありませんか?プログリットは、あなたに合った学習法に沿って短期集中で英語力を飛躍的に向上させ、その後の長期的な成長をも可能にする英語コーチングサービスです。 トータルサポートだから、短期で伸びる ... プロダクト開発部の紹介プロダクト開発部
モダンデータスタック(Modern Data Stack)とは? データ統合の新しいトレンド:編集部コラム データ統合の分野でMDS(Modern Data Stack)というキーワードが注目を集めています。今までの技術とどんな違いがあるのでしょうか。
順を追って作業したので、備忘程度に記載する。私自身のキャッチアップも兼ねて Dockerによる環境の準備 dbtの設定・構築 Airflow側の設定・構築 dagでの記載例 (trocco => dbt) 環境の準備 Dockerを使ってAirflowを用意します。早く環境を立ち上げたいので、dbt等も一緒にイメージに入れてしまいます。 docker-compose ちょっと古いですが、2.1.0のversionを使います(composeのコードも短かったので) curl -LfO 'https://airflow.apache.org/docs/apache-airflow/2.1.0/docker-compose.yaml' 一部書き換えます。書き換えている内容としては Dockerfileからイメージを作成するように変更 編集しやすいようにvolumeに構成したフォルダをマウントさせ
さがらです。 DevelopersIO 2022 〜技術で心を揺さぶる3日間〜の2日目、2022年7月27日に「データ活用」に注力できるデータ基盤を構築しませんか?~クラスメソッドのModern Data Stackのご紹介~というタイトルで登壇しました。 本ブログではこの登壇内容について、まとめたいと思います。 登壇概要 概要 昨今ビジネスの環境が目まぐるしく変わる中、「これまでの経験」や「前例踏襲」のビジネスのやり方では対応できなくなってきているケースが多くなり、データを活用して、データに基づいた意思決定を行おうとする組織が増えていると思います。 一方で、データを活用するためには「データ基盤」が必要となるのですが、このデータ基盤の構築に苦労し、本来すべきデータ活用に注力できていない組織も多いのではないでしょうか。クラスメソッドでは複数のSaaSを組み合わせて簡単にデータ基盤を構築する「
こんにちは、データプラットフォームチームでデータエンジニアをやっている滑川(@tomoyanamekawa)です。 以前紹介したデータ分析基盤であるソクラテスの改善のためにCloud Composer(Airflow)で行っている処理のdbtへの置き換えを検討しましたが、導入を見送りました。 調べてみてdbtに対するわかりみも深まったので、その供養のために検討内容を公開します。 同じように検討している方の参考になれば幸いです。 dbtとは DWH(Data Ware House)でのquery管理やデータの品質、データリネージの問題を解決してくれるツールです。 すでに先人たちがいろいろな記事を公開してくれているので、詳細は説明しませんがこちらの文がdbtをよく表しています。 ELTの「T」を担当するツール データの前処理における作業をELT(Extract、Load、Transform)と
このモダンデータスタックはアメリカでは2、3年前からトレンドとなっており、様々なデータに関連するカンファレンスで取り上げられています。そのうちの一つ、Future DataでdbtのCEOであるTristan Handy(@jthandy)がこのトレンドの背景について話しており、とても面白い内容でした。 The Modern Data Stack: Past, Present, and Future先日、SisuのFuture Dataカンファレンスでこのタイトルの講演を行ったのですが、私はパワーポイントではなく散文で考えるので、スライドをまとめる前にブログ記事を書く必要がありました。最終的な推敲を重ね、世に送り出すまでに少し時間がかかってしまいましたが、貴重な情報としてご覧いただければ幸いです。講演の全文をご覧になりたい方は、こちらをご覧ください。 過去10年間、データプロダクトは多くの
今回のnoteでは、Modern Data Stackとは何か、どのようにして生まれたのか、そして今後どのような方向に進んでいくのかについて、大枠を理解するために以下の記事👇を翻訳したので展開します。 モダンデータスタックとは?モダンデータスタックとは、一般的にクラウドネイティブなデータプラットフォームを構成するテクノロジーの集合体を指し、一般的には従来のデータプラットフォームの運用における複雑さを軽減するために活用されます。個々のコンポーネントは固定されていませんが、一般的には以下のようなものがあります。 Snowflake, Redshift, BigQuery, Databricks Delta Lakeなどのクラウドデータウェアハウス Fivetran, Segment, Airbyteなどのデータ統合サービス ELTデータ変換ツール(ほぼ間違いなくdbt) LookerやMod
みなさん、こんにちは、Salesforceでプロダクトマネージャーをしている深田です。データ/AIプラットフォームを勉強している中で、ちょうど一年前にモダンデータスタックの歴史についてdbtのCEOの記事をざっくり翻訳しました👇 今回は、この現在急成長しているデータ/AIプラットフォーム領域における大きな変化、トレンドにどう向き合えば良いのかをブループリントを軸にa16zが解説した記事がとても勉強になったので、抄訳しました🥳 イントロダクションテクノロジー業界において、私たちは大規模で複雑なソフトウェアシステムを構築することが得意でした。その証拠として今、私たちは、データを中心に構築された巨大で複雑なシステムの台頭を目の当たりにしています。すなわち、システムによってもたらされる主なビジネス価値は、ソフトウェアが直接もたらすのではなく、データの分析によってもたらされます。このトレンドは、
がく@ちゅらデータエンジニア です。 ※2022年9月よりちゅらデータ株式会社にJoinしました データエンジニアリングな話題などをMediumで毎朝、サジェストされるんですが、これちゃんと読んでいかんとなーということで、読んだメモなどを残しておこうと思って書いて行こうと思います。 概要 今日はこちら 「2022年モダンデータスタック」 Modern Data Stackについての記事はたくさんあるので、読んだ方もいるかも知れない。 最近では Data Processing Frameworks(データ処理フレームワーク) Visualization Tools(可視化ツール、BIツール?) ETL Tools Development notebooks(JupyterNotebookみたいなやつかな?) Data Catalog といったものが現れてきている。 時代とともに新しい技術がで
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? MySQLにbinlogとredo logの二つの重要なログシステムがあります。本文では、この二つのログの仕組みについて説明します。 #1.基本知識 MySQLは、SQLの解析と実行する機能を実現するServer層とデータアクセス機能を提供するストレージエンジン層で構成されています。ストレージエンジンには、MyISAM、InnoDB、Memoryなどが存在します。 binlogは、Server層が出力するログです。redo logは、InnoDBエンジンが出力するログです。二つのログは、ともにDBテーブル更新時に出力されます。 ディスク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く