【Data Factory】データ分析プラットフォーム勉強会#3で登壇しました
お久しぶりです、ジーフーです。
8月末に勉強会のスピーカーとしてAzure Data Factory V2に関する技術情報を発信してきました。
内容としては、Azure Data Factory Version2で追加された新機能の紹介をメインに、Demoを交えて紹介致しました。 その際に、DataFactoryを理解する上で欠かせないキーワードに関しても説明しております。
実は私、こういった場での発表は初めてございました。 資料作りは好きなので空いている時間にゴリゴリ作成を進めていたのですが、発表はどうするか。。。時間通りに話すにはどうするか。。。ということで、今回は大変お世話になっている小澤さんのブログからすぐに活用できそうなテクニックを参考にさせて頂きました。
この記事を参考に、事前に原稿を準備した上で、頭の中で読んでみたり、実際に声に出して読んで各スライドにかかる所要時間を測りながら、メモをとって準備しました。 これが実際本番でも役に立ちまして、各スライドの時間を測っていたことで余裕も生まれ、予定通りの時間内で発表することができました。 (発表の内容自体には反省点が多々あります。。)
実際に話してみたことでわかったことは、インプットよりアウトプットすることが学べることが多いということ。 スピーカーになってみたことで、質問に来てくれる人が一人でもいると嬉しい、アンケート結果は悪い評価でも良い評価でもいいから気になるし正直に答えてくれる人がいると嬉しい、ということが実感できました。 これってアウトプットしないと得られない喜びだよなと思いますし、積極的にアウトプットする癖をつけたいと改めて思えるようになりました。
社会人の基本はアウトプット。 当たり前といえば当たり前。ですが、私の場合はアウトプットする機会がこれまでいくつかありながら、自分にはまだ早い、人前で話すのは怖い、と言い訳ばかりで動き出してきませんでした。 貴重な機会をみすみす逃していた自分を殴りたい気分です。 これからは積極的に勉強会にも顔を出し、インプットした知識をアウトプットすることで強化して自分を高めていきたいと強く思いました。
Azure Data Factory バージョン2 (v2)のGUI、統合ランタイム
こんにちは。
Azure Data Factory(以下、ADF)のバージョン2が2018年6月末にGA(一般公開)となりました。 ※GA(一般公開)とは、プレビュー版として提供していたサービスを一般的に公開することです
そこでADF v2で強化されたUI周り、また、統合ランタイムについてを簡単に記していこうと思います。
パイプライン作成画面
筆者自身、実際に使ってみてオオオ便利!!と思ったパイプライン作成画面について説明します。 まずは画面キャプチャをドーン!
ADF V2にバージョンアップしたことで、GUIによるパイプラインの作成が格段に向上し、ADFがより使いやすくなったと筆者自身実感しています。
※V1のパイプライン作成に用いられるGUIについてはおいおい述べようと思いますので今回は割愛
この画面より、処理グループとなるパイプラインを新たに追加し、そのパイプラインで実行する処理(Activityと呼びます)、および、その処理に紐づくDataset、LinkedService等を設定していきます。
アクティビティはデータコピーアクティビティ、データ変換アクティビティ、データ制御アクティビティと多種用意されており、Activityメニューより選択し、ドラッグアンドドロップして追加することが可能となっております。
複数のアクティビティを設定し、それぞれを線でつないでいくことで一連の処理を設定していき、パイプラインが作成できます。
実際のパイプラインの作成手順に関しては今度詳しく記事にまとめようと思います。
統合ランタイムの登場
ADF v2で、統合ランタイムというADFの実行環境が構成されるようになっております。 統合ランタイムは以下の3種類が用意されております。
- Azure統合ランタイム
- セルフホステッド統合ランタイム
- SSIS統合ランタイム
データ移動、HDInsight等の実行環境上で実施するデータ変換アクティビティのディスパッチ、SSIS(SQL Server Integration Service)のパッケージ実行を上記の統合ランタイムで実施する仕組みになっています。
以下、それぞれについて説明します。
Azure統合ランタイム
BlobストレージからAzure SQL DatabaseやAzure SQL DataWarehouse等、Azure環境上のPaaS間でのデータコピー等アクティビティを実行するための環境。
Azure統合ランタイムは各地のリージョン上に構成されており、データコピーを実施する際に、それぞれのデータソースのリージョンから、最適なリージョンで構成された統合ランタイムを判別し、データコピー処理を実施する仕組みになっております。
スケールも自動で実施されるため、常にベストなパフォーマンスでデータコピーを実施できる仕組みが備わった実行環境となっています。
※なお、スケールはデフォルトでは自動(Auto)設定になっていますが、手動で設定することも可能です。
セルフホステッド統合ランタイム
ADF v1でいうところの「Data Management Gateway」にあたるADF機能の実行環境です。
オンプレミス環境やAzureのVNet環境下に構成したデータソースとのデータのやり取りを行うために構成されます。例えば、オンプレミス環境上のWindowsマシンにセルフホステッド統合ランタイムをインストールし、プライベートネットワーク上のDBやファイルシステムからAzure上の各サービスに接続するための玄関口として機能させます。セルフホステッド統合ランタイムからの通信は暗号化されておりセキュアなデータのやり取りが可能となります。
Azure統合ランタイムでは、自動でスケールされると説明しました。セルフホステッド統合ランタイムもスケール構成を用意することが可能ですが、そのためには複数のwindows環境を用意し、それぞれにセルフホステッド統合ランタイムをインストールし、グループ化してあげることが必要となります。
SSIS統合ランタイム
※現在検証中のため、内容薄目ですが後日また記事にしますのでご了承ください。。
SSISパッケージを実行するための完全マネージドVM環境です。SSH接続等直接実行環境に接続することはできません。
SSISを実行するにあたりログ等の情報格納先となるカタログデータベースが必要となります。カタログデータベースはSQL Database上などに作成可能です。
まとめ
本日はADF v2のGUI画面の簡単な紹介と統合ランタイムについて説明しました。
次は実際にパイプラインをGUIを操作して作成する流れを記そうと思います。
Azure Data Factory v2 スケジュールトリガー設定時の注意点
こんにちは。
Azure Data Factory バージョン2はGUI周りが強化されて、非常に操作性が向上したと実感しています。
バージョン2にアップデートされて、パイプラインの実行タイミングはトリガーで指定するようになりました。
筆者がトリガーの検証を行った際にひっかかった点がありましたのでメモとして記します。
スケジュールトリガーの設定について
赤枠で囲った部分がトリガーの実行開始時間を設定するフォームです。日付の他に開始時間を分単位で設定することができます。同様に、トリガーの期限を設定することも可能です。
GUIを利用してトリガーを作る際に時間を設定する上で二つ注意点があります。
一つは、ここで指定する時間は"UTC"時間であることです。
そのため、日本時間と9時間の差があることを考慮した上で設定する必要があります。
二つ目は、AM12時はお昼の12時を指すということです。
そんなの当たり前ですって……?筆者は混乱しました笑
まずは画面を見て頂きたいです。
時間はドロップダウン形式で選択できるようになっております。
AM/PMを指定した上で時間を選択してトリガーの開始時間、期限を設定します。
さて、筆者は日本時間9:50から10:05までの間で1分間隔でパイプラインを実行するよううトリガーを設定したいと考えました。
トリガーの検証を始めた時刻は9時45分。トリガー作成画面に遷移すると、トリガーの開始日時はあらかじめ現在日時が設定された状態になっています。
トリガーの開始時刻は【AM12:45】が指定されていました。
5分後に動き出すトリガーを作りたいから、実行開始時間は【AM12:50】を指定すればいいんだな。
その15分後には終わるトリガーにしたいから、期限は開始時間の15分後だよなと考え、【PM01:05】を指定したわけですよ。
さて、トリガーの作成が完了しました。
時間になったら自動で動き出したことが確認でき、はい成功!と安心してとりあえず放置していました。
~他の作業中~
あ、そろそろ終わっている時間だよな。確認しよ。
ん?
(。´・ω・)ん?
まだ動いてる!!!!!!!!!
そこでようやく、トリガーの期限の指定が誤っていることに気づきました笑
トリガーのソースコードを確認し、【AM12:50】と指定したトリガー開始日時は【"startTime": "2018-07-25T00:00:00.000Z",】と設定され、【PM01時】と指定したトリガー期限は【"endTime": "2018-07-25T13:05:00.000Z"】と設定されていることが確認できました。
つまり、【AM12:00】の1時間後は【AM01:00】と設定するのが正しかったのです。
単純にAM12:00の次はPM01:00だよなと勝手に思い込んで設定してしまっていたのが間違いでした。。
まとめ
ここで得た教訓は以下のものがあげられます。
①AM/PMの正しい考え方を理解しよう
②トリガーのソースコードもしっかり確認しよう
筆者と同じような勘違いする人はいないよ!!って意見もあるかもしれませんが、少しでもこの記事が皆様のお役に立てば幸いです。。笑
Azure Data Factoryとは
こんにちは。 Blog復帰(?)一回目の記事は、最近お気に入りの製品「Azure Data Factory」について記そうと思います。 今回はAzure Data Factoryとは何か、また、その製品を理解する上で基礎となる部分に関してを説明します。 なお、本記事は2018年6月にGA(一般公開)となったData Factoryのバージョン2をベースにしています。
Azure Data Factory
Microsoftが提供するパブリッククラウドAzure環境上で利用できるフルマネージドのデータ統合(ETL)サービスです。(以下、ADFとします)
オンプレミス、クラウドと環境を問わない各種データソースからのデータロード、加工、出力を管理でき、データ統合を支援するツールです。
主な利用用途
分単位、時間単位、日次、月次処理等の定期的な周期で実施されるデータ移動、データ加工処理の自動化を行うために使われ、以下の利用用途が想定されます。
- オンプレミス環境上のデータソース(ファイルサーバ、DB等)からクラウド環境上の各種ストレージへのデータ移行
- AWSのS3からAzureのBlobストレージへのデータ移行
- 各種センサデバイスから収集されるデータのクレンジング、データウェアハウスへの流し込み
データソース
データソースとして接続できる環境は2018年7月時点で約70種以上あります。
Azure環境の各製品はもちろん、オンプレミス上に構築されたDB、ファイルシステム、AWS等その他パブリッククラウド上の製品とも連携することが可能となっています。
筆者自身が未検証のためまだ内容をよく理解できていませんが、PayPalサービスとの連携も現在プレビュー機能として可能となっており、今後も連携できる製品、サービスは増加していくことが見込まれています。
連携できる製品については下記の公式ドキュメントをご参照ください。
Azure Data Factory のデータセットとリンクされたサービス
ADFの構成要素
ADFを理解する上で押さえておくべき用語がいくつかあります。 下記をまずは理解しておくことが重要と考えます。
- LinkedService
- DataSet
- Activity
- Trigger
- Pipeline
LinkedService
各種データソースへの接続情報の定義を示します。
ex)
- SQL Databaseへの接続情報(url,user,pw)
- Blobストレージへの接続情報(接続文字列)
- オンデマンドHDInsightへの接続情報(ノード構成等)
DataSet
データストア(入力、出力データ)に関するデータ構造に関する情報の定義を示します。
ex)
Activity
データセットに対して実行するアクション設定を示します。
ex)
- データ移動(データソースからターゲットへのデータコピー)
- データ変換(HDInsight等でのHive, sparkを利用したデータ加工処理)
- フローの制御(※V2から追加されたアクティビティ
以下は制御アクティビティからいくつか抜粋- IF(アクティビティ実施結果の分岐)
- ForEach(配列に対して繰り返し処理の実施)
- WEB(REST呼び出しによるデータ取得等)
制御アクティビティを利用することで、メール送信サービス(SendGrid)と連携しメール送信APIを叩いてメールを送信することも可能です。そのうち構築手順を記そうと思います。
Trigger
2018年6月にGA(一般公開)となったADFの新バージョンV2より新たに登場した機能であり、処理の起動タイミングに関する設定を示します。
ex)
- スケジュール トリガー
実時間のスケジュールによってパイプラインを起動するトリガー - タンブリング ウィンドウ トリガー
状態を保持しながら定期的に実行されるトリガー - イベントベースのトリガー
Blobストレージ上でBlobが格納or削除されたイベントに応答するトリガー
Pipeline
各データセットとアクティビティを組み合わせ論理的にグループ化した一連の処理セットです。
まとめ
ADFを理解する上で基礎となる各用語についてを記しました。
次は2018年6月末にGA(一般公開)されたADFの新バージョンV2の特徴に関して説明しようと思います。
久々の投稿になってしまいました。。
このブログをご覧いただいている皆様、こんにちは。 じーふーと申します。
このブログを開設した当初は頑張って記事を投稿しておりましたが、元来飽き性な性分であることがブログでも発揮され、記事投稿が滞ってしまいました。。。 現在33歳。ブログ開設時に入社した職場を離れ、現在新たな環境に移り変わり引き続きインフラエンジニアを務めております。 ブログ開設時はOracleをメインに扱うDBエンジニアとしてスタートしましたが、現在はAWS,Azureといったクラウド環境全般の製品を扱うインフラエンジニアに。
新たな環境で学ぶことも多い今。新たにブログ記事を投稿していき仕事の中で得てきたナレッジを自分のものにしていくため、記事投稿に勤しみます。
引き続き、宜しくお願い致します。
【linux】 各ユーザーのログイン履歴確認コマンド(last, lastlog)
各ユーザーのログイン履歴や、最終ログイン日時を確認することができるコマンドがあることを知りましたのでメモメモ。
管理サーバの不正ログインを検知するのに使えそうですね。
最近ログインしたユーザー履歴確認
# last
実行結果
[root@db-1 scripts]# last root pts/0 192.168.2.12 Wed Jun 10 07:59 still logged in oracle pts/3 :0.0 Tue Jun 9 22:11 - 22:29 (00:17) oracle pts/0 :0.0 Tue Jun 9 21:57 - 22:29 (00:31) oracle tty1 :0 Tue Jun 9 21:57 still logged in root pts/2 192.168.2.12 Tue Jun 9 21:51 - 22:29 (00:38) root pts/1 192.168.2.12 Tue Jun 9 21:49 - 22:29 (00:39) root pts/1 192.168.2.12 Tue Jun 9 17:15 - 20:32 (03:16) root pts/0 :0.0 Tue Jun 9 12:43 - 21:56 (09:12) root tty1 :0 Tue Jun 9 12:42 - 21:56 (09:13) reboot system boot 2.6.32-504.el6.x Tue Jun 9 12:41 - 08:36 (19:54) root pts/0 :0.0 Tue Jun 9 12:23 - down (00:18) root tty1 :0 Tue Jun 9 12:22 - down (00:18) reboot system boot 2.6.32-504.el6.x Tue Jun 9 12:22 - 12:41 (00:19) root pts/0 :0.0 Tue Jun 9 12:20 - down (00:01) root tty1 :0 Tue Jun 9 12:20 - down (00:01) reboot system boot 2.6.32-504.el6.x Tue Jun 9 12:18 - 12:21 (00:03) root pts/0 :0.0 Tue Jun 9 11:41 - down (00:36) root tty1 :0 Tue Jun 9 11:41 - down (00:37) reboot system boot 2.6.32-504.el6.x Tue Jun 9 11:40 - 12:18 (00:38) reboot system boot 2.6.32-504.el6.x Tue Jun 9 11:38 - 11:39 (00:01) wtmp begins Tue Jun 9 11:38:42 2015
各ユーザーの最終ログイン日時確認
# lastlog
実行結果
[root@db-1 scripts]# lastlog ユーザ名 ポート 場所 最近のログイン root pts/0 192.168.xx.xx 水 6月 10 07:59:27 +0900 2015 bin **一度もログインしていません** daemon **一度もログインしていません** adm **一度もログインしていません** lp **一度もログインしていません** sync **一度もログインしていません** shutdown **一度もログインしていません** halt **一度もログインしていません** mail **一度もログインしていません** uucp **一度もログインしていません** operator **一度もログインしていません** games **一度もログインしていません** gopher **一度もログインしていません** ftp **一度もログインしていません** nobody **一度もログインしていません** dbus **一度もログインしていません** vcsa **一度もログインしていません** rpc **一度もログインしていません** rtkit **一度もログインしていません** avahi-autoipd **一度もログインしていません** abrt **一度もログインしていません** rpcuser **一度もログインしていません** nfsnobody **一度もログインしていません** haldaemon **一度もログインしていません** gdm **一度もログインしていません** ntp **一度もログインしていません** saslauth **一度もログインしていません** postfix **一度もログインしていません** pulse **一度もログインしていません** sshd **一度もログインしていません** oprofile **一度もログインしていません** tcpdump **一度もログインしていません** oracle **一度もログインしていません**
補足
マニュアルによると、last
コマンドは/var/log/wtmp
、lastlog
コマンドは/var/log/lastlog
というバイナリファイルの内容を整形して表示させているようです。
また、wtmpはどのくらいの期間のログイン履歴を保持しているかというと、デフォルトでログローテーションするよう設定されているため、通常1ヶ月の履歴を保持しているようです。
[root@db-1 scripts]# cat /etc/logrotate.conf # see "man logrotate" for details ~~ 中略 ~~~ # no packages own wtmp and btmp -- we'll rotate them here /var/log/wtmp { monthly create 0664 root utmp minsize 1M rotate 1 } ~~ 中略 ~~~ # system-specific logs may be also be configured here.
【linux】 rpmでインストールする際に実行されるスクリプトを確認する
PostgreSQLのRPMをインストールすると、合わせて「postgres」ユーザーが作られたり、サービス自動起動が設定されたりと色々勝手にやってくれるのですが、ユーザー作成やサービス自動起動設定を定義している記述は何を参照すれば確認できるのかまったくわかっていませんでした。
ようやくその謎も解けました。。
RMPファイルインストール、アンインストール時に実行するスクリプトがRPMファイルには設定されていたのですね。
RPMのインストール、アンインストール時に実行されるスクリプトは、--scripts
オプションを付けてrpmコマンドを実行することで確認することができます。
# rpm -qp --scripts <rpmファイル>
試にPostgreSQLのPRMスクリプト確認コマンド実行結果
[vagrant@redmine ~]$ rpm -qp --scripts postgresql94-server-9.4.2-1PGDG.rhel6.x86_64.rpm preinstall scriptlet (using /bin/sh): groupadd -g 26 -o -r postgres >/dev/null 2>&1 || : useradd -M -n -g postgres -o -r -d /var/lib/pgsql -s /bin/bash \ -c "PostgreSQL Server" -u 26 postgres >/dev/null 2>&1 || : postinstall scriptlet (using /bin/sh): chkconfig --add postgresql-9.4 /sbin/ldconfig # postgres' .bash_profile. # We now don't install .bash_profile as we used to in pre 9.0. Instead, use cat, # so that package manager will be happy during upgrade to new major version. echo "[ -f /etc/profile ] && source /etc/profile PGDATA=/var/lib/pgsql/9.4/data export PGDATA # If you want to customize your settings, # Use the file below. This is not overridden # by the RPMS. [ -f /var/lib/pgsql/.pgsql_profile ] && source /var/lib/pgsql/.pgsql_profile" > /var/lib/pgsql/.bash_profile chown postgres: /var/lib/pgsql/.bash_profile chmod 700 /var/lib/pgsql/.bash_profile preuninstall scriptlet (using /bin/sh): if [ $1 = 0 ] ; then /sbin/service postgresql-9.4 condstop >/dev/null 2>&1 chkconfig --del postgresql-9.4 fi postuninstall scriptlet (using /bin/sh): /sbin/ldconfig if [ $1 -ge 1 ]; then /sbin/service postgresql-9.4 condrestart >/dev/null 2>&1 fi [vagrant@redmine ~]$
これを見ると、PostgreSQLのPRMには下記4種類のスクリプトが設定されていることがわかります。
- preinstall (インストール前に実行)
- postinstall (インストール完了後に実行)
- preuninstall (アンインストール前に実行)
- postuninstall (兄インストール完了後に実行)
個別に見ていきます。
preinstall script
preinstall scriptlet (using /bin/sh): groupadd -g 26 -o -r postgres >/dev/null 2>&1 || : useradd -M -n -g postgres -o -r -d /var/lib/pgsql -s /bin/bash \ -c "PostgreSQL Server" -u 26 postgres >/dev/null 2>&1 || :
下記流れの処理を実行していますね。
- postgresグループ作成
- postgresユーザー作成
これで、RPMインストール時にどのタイミングでユーザーが作られているかの謎が解けました。
postinstall script
postinstall scriptlet (using /bin/sh): chkconfig --add postgresql-9.4 /sbin/ldconfig # postgres' .bash_profile. # We now don't install .bash_profile as we used to in pre 9.0. Instead, use cat, # so that package manager will be happy during upgrade to new major version. echo "[ -f /etc/profile ] && source /etc/profile PGDATA=/var/lib/pgsql/9.4/data export PGDATA # If you want to customize your settings, # Use the file below. This is not overridden # by the RPMS. [ -f /var/lib/pgsql/.pgsql_profile ] && source /var/lib/pgsql/.pgsql_profile" > /var/lib/pgsql/.bash_profile chown postgres: /var/lib/pgsql/.bash_profile chmod 700 /var/lib/pgsql/.bash_profile
完了後は下記流れの処理を実行しているのがわかります。
- postgresql-9.4サービス自動起動
- ldconfigコマンド実行
- /var/lib/pgsql/.bash_profile作成
- 上記ファイルのパーミッション変更
preuninstall script
preuninstall scriptlet (using /bin/sh): if [ $1 = 0 ] ; then /sbin/service postgresql-9.4 condstop >/dev/null 2>&1 chkconfig --del postgresql-9.4 fi
アンインストール前は下記の処理実施
- PostgreSQLサーバのサービス停止
- 自動起動設定削除
postuninstall script
postuninstall scriptlet (using /bin/sh): /sbin/ldconfig if [ $1 -ge 1 ]; then /sbin/service postgresql-9.4 condrestart >/dev/null 2>&1 fi
アンインストール完了時は下記処理実施
- ldconfigコマンド実行
- 上記コマンド実行成功時以外はサービス再起動
rpm queryオプション
rpmのmanからQUERYオプションについて確認してみました。 色々と見れる情報も多いんですね。
PACKAGE QUERY OPTIONS: --changelog Display change information for the package. -c, --configfiles List only configuration files (implies -l). -d, --docfiles List only documentation files (implies -l). --dump Dump file information as follows (implies -l): path size mtime digest mode owner group isconfig isdoc rdev symlink --filesbypkg List all the files in each selected package. -i, --info Display package information, including name, version, and description. This uses the --queryformat if one was specified. --last Orders the package listing by install time such that the latest packages are at the top. -l, --list List files in package. --provides List capabilities this package provides. -R, --requires List capabilities on which this package depends. --scripts List the package specific scriptlet(s) that are used as part of the installation and uninstallation processes. -s, --state Display the states of files in the package (implies -l). The state of each file is one of normal, not installed, or replaced. --triggers, --triggerscripts Display the trigger scripts, if any, which are contained in the package.