この問題をPythonで解いた。
#3 Largest prime factor - Project Euler
日本語の問題文はこちら
13195 の素因数は 5, 7, 13, 29 である.
600851475143 の素因数のうち最大のものを求めよ.
N = 600851475143
i = 2
while i * i <= N:
while N % i == 0:
N //= i
i += 1
print(N)
Azureを使ってデータ分析基盤を構築すると、Azure Data Lake Storage Gen2にデータを溜めていく事が多いです。
この日々溜まっていくデータから最新日付のファイルのみを取り出したいときに使えるテクニックです。
前提条件として、XXX_yyyyMMdd.csvやZZZ_yyyyMMddHHmmss.csvといった、同じファイル名の末尾に日時の情報がくっついているデータを取得するケースとします。
まずはパイプラインに変数を用意します。今回は最新日付のファイルだったので、latest_filename としました。
次にアクティビティを用意します。
今回使うのはGetMetadataと変数の設定です。2つとも「全般」の中に存在しています。
変数とアクティビティの設定が終わると、画像のようになります。
ファイルが置いてあるディレクトリへのデータセットを作成します。
ファイルパスの部分には「ディレクトリ」を設定し、「ファイル」の設定はおこないません。
GetMetadataアクティビティに、データセットを設定し、フィールドリストに子項目を設定します。
変数の設定アクティビティの変数タブへ移動し、下記の設定をします。
latest_filename@last(activity('get_files').output['childItems'])['name']ここでは、latest_filenameという変数に @last(activity('get_files').output['childItems'])['name']の値を入れています。
分解していくと、activity('get_files')は一つ前のアクティビティです。activity('get_files').output['childItems']は一つ前のアクティビティの出力結果の子要素、今回はactivity('get_files')のデータセットに、フォルダを指定していたので複数のファイル群になります。
その複数のファイル群の中からlast関数の実行結果である最後のファイルの['name']をlatest_filenameという変数に格納していることになります。
今回はフォルダ配下に、2ファイル配置しました。test_20210609110816.csvが取得できれば良さそうです。デバッグ実行してみます。
get_filesアクティビティの出力結果は2ファイル取れています。
set_filenameアクティビティの出力結果は1ファイル、そして最新のファイルの結果が取れています。
Azure Data Factory でデータレイクから最新日付のファイルを取得してみました。 デフォルトの機能をうまく使いこなすことで、少し込み入ったことも出来るようになりそうです。
どこから削除ができるのか探してしまったのでメモ。
まずはReposの「Files」に、現在いるものとする。
左のReposメニューから「Branches」を選択する。
削除したいブランチの右に配置されている点から「Delete branch」を選択する。
確認画面が表示されるので削除したければ「Delete」をクリックする。
ブランチが削除される。
Azure Data Factoryでは、パイプライン開発をバージョン管理するためにGit連携ができます。 GUIでの開発なのにバージョン管理できるのは、Data Factoryの実態がJSONファイルになっているからです。
Azure Data FactoryとAzure DevOpsなどを連携すると、デフォルトではmasterブランチとadf_publishブランチの2つが用意されます。 masterブランチは通常の開発として利用されるブランチになっていて、adf_publishブランチはAzure Data Factoryにおける本番リリース用となっています。
図解すると下記のようになります。 1人の開発者が1つのシステム連携を作成しているときは、シンプルで使いやすいものになります。
次に2人の開発者が2つのシステム連携を作成しているときは、どうでしょうか。 別々のシステム連携を作成しているとき、開発中は特に問題にはなりません。
しかし、adf_publishブランチへ本番リリースをしたいタイミングでは事情が変わってきます。 本番リリースをする際にはmasterブランチの作成物すべてが正常に動くか検証し、adf_publishブランチへマージします。 つまり、下記画像のように1人の開発者が作成物を本番リリースしたくても、もうひとりが開発中で中途半端な状態だとadf_publishブランチへマージすることができません。 最後まで完成させてもらうか、エラーが出ない切りのいい部分まで進めて貰う必要があります。 エラーが出ない切りのいい部分まで進めてもらったとしても、中途半端な成果物が本番リリースへと運ばれてしまいます。
この状態を回避するために、masterブランチから各システムごとのブランチを作成します。 この状態で開発をすすめることで、Bシステムでの開発が終わっていなくても、Aブランチの作業だけmasterに反映し、開発済みのキレイな作成物だけをadf_publishブランチへ持っていくことができます。
Azure Data Factoryを使い始めた人は、Gitの部分よりもAzure Data Factoryになれるために、ひとまずGitを横へ置いてどんどん開発していくと思います。 自分も開発に慣れてきて、さらには新しい人も入ってきて開発のスピードを上げていこうとしたタイミングで起こりうる問題として、解決策を取り上げてみました。 まずは開発のスピードを落とさず、問題が起きないようにするための第一歩として、参考になれば幸いです。 ここからさらにGit-flowといったものへ目を移していけばいいと思っています。
カーディナリティは、データベースのカラムに入っているデータの種類がどれぐらい存在しているかを表す。 もともとの英単語の訳としては濃度という訳が当てはまる。
例えば、genderカラムが存在していたとする。単純な話としたいので、このカラムに入ってくる値は男か女とする。
| id | gender |
|---|---|
| 1 | 男 |
| 2 | 女 |
10人分のデータがあったとしても入っている種類は男か女で種類が2つしかない。
| id | gender |
|---|---|
| 1 | 男 |
| 2 | 女 |
| 3 | 男 |
| 4 | 女 |
| 5 | 女 |
| 6 | 女 |
| 7 | 女 |
| 8 | 男 |
| 9 | 女 |
| 10 | 男 |
こういった場合はデータの種類が少ない、つまりカーディナリティが低いと言います。
もう一つ、カーディナリティが低い例として血液型がある。 bloodカラムがあったとして、ここに入ってくるデータは4種類。 つまり - A - B - O - AB
となる。
| id | blood |
|---|---|
| 1 | O |
| 2 | A |
| 3 | AB |
| 4 | AB |
| 5 | B |
| 6 | A |
| 7 | A |
| 8 | O |
| 9 | AB |
| 10 | B |
逆にカーディナリティが高い状態はgenderカラムとbloodカラムの説明でつけたidカラムを言う。 idカラムは1から10の数値を示している。 このように1から順番に上がっていくサロゲートキーのような数値は、1から10まで種類があるのでカーディナリティが高い状態と言える。
「さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー2.0」を買って、実践してみた。
この本は自分の才能に気がつき、今後の人生をより良い方向へ進める指針となるものが分かる本になっている。 目次は次のようになっている。
1部では、なぜ才能に気づかなければいけないかが端的に書いてある。この部分は30ページほどだが、すぐにストレングスファインダーを受けたくなるように駆り立てる感じがあった。 2部では、ストレングスファインダーを実施し自分の資質を把握したあとに読むものとなっている。全て読んでも良いものなのだろうが、自分の資質とは関係がないのでひとまずは読まなくても良さそう。 「この資質を持っている人との付き合い方」といったような項目もあるので、友人と結果をシェアした際に読むと盛り上がりそうだ。
実際のストレングスファインダーは巻末にあるアクセスコードを使ってWebサイトから実施する。実施の時間は40分目安と書いてあり、テンポよく実施したつもりだったが自分は35分ほどかかった。深く考えないように1問20秒の制限もあるが、深く考えすぎる進めていくほうが良さそう。
自分の5つの項目は以下となった。
この結果にはあまり驚いておらず、普段自分自身に対して思っていることと同じで安堵する気持ちがあった。
原点思考は過去をふりかえる資質になる。過去を振り返ることで計画段階の原型だったり、その中から意図を知ることができる。 今の段階の現状を知らされたときに、まず最初に聞くことは「なぜ」「どうして」といった言葉が多いことに改めて気がついた。 何事にも軌跡があり、過去と現在があるからこそ、未来を描けていけるようなイメージを自分は持っている。 ソフトウェア開発においても、「昔はこうだったが、今はこうなっている、理由はこういうことだからである」と言われたほうがすんなり入っていくし、頭にも残っていることが多い。 こういった特性を改めて認識できると、例えば本を読んで学習する際にも歴史的な流れが記されているものを手にとったほうが良さそうといったことが自分の中でわかってくる。
回復思考は、要は問題解決することが好きという資質になる。 現在もエンジニアとして仕事をしているが、IT技術で課題を解決していくということでとてもあっていると感じた。 逆に言うと、問題解決が伴わない単純に作業などは苦手であることを再認識できた。できればそういうことからは離れていこうと思った。 今後、進んでいくべき方向としては、知識を高めてスキルをどうやって高めていくか、それをどうやって問題解決能力に転換していくのかが、人生単位では必要になっていくんじゃないかと思った。
ストレングスファインダーの紹介と、想像がつかない「原点思考」と「回復思考」についてどんな事が書かれており、それを受けて自分がどう感じたかを書いてみた。 自己分析だったり、今後の人生の指針に悩んでいる人がいたら参考になると思うのでぜひやってほしいと思った。
Azure SQL Databaseでは監査ログをかんたんに取得することができる。文字通り監査のタイミングで必要になるので、基本的には取得しておいたほうがいいものになる。Azure SQL Databaseではデータベースのイベントを追跡し、Blobストレージに監査ログを書き込む。
SQL Databaseにアクセスし、「セキュリティ」の「監査」へアクセスする。 「Azure SQL 監査を有効にする」をオンにする。
その後、出力先の「ストレージ」にチェックを入れ、対象のBlobストレージがある「サブスクリプション」と「Blobストレージ」を選択する。
設定が完了するとBlobストレージに専用のコンテナが作成されている。
Apache Airflowで自作ファイルを作成しようとしたが、設定できる項目多く迷うことが多かった。そこでチュートリアルで用意されているものから最低限必要なものを抜き出してみた。 それが以下になる。
from datetime import timedelta
from airflow import DAG
from airflow.operators.bash import BashOperator
from airflow.utils.dates import days_ago
with DAG(
"hello_airflow",
schedule_interval=timedelta(days=1),
start_date=days_ago(2),
) as dag:
t1 = BashOperator(
task_id="hello_world",
bash_command="date",
)
t1
with DAGの中には次のものがないと、正しく設定ファイルを読み取ってくれなかったり、エラーなる。エラーはAirflowの管理画面に表示されるので認識しやすい。しかし、値を正しく読み取ってくれないパターンはわかりやすく表示してくれるわけではないので注意が必要ということがわかった。
これらはDAG Detailsの中に表示される。
as dagのあとにコロンが付いていて、そのまま実際におこなう処理を記述する。直列で処理をつなげることもできるし、並列で動かすこともできる。今回の例ではわかりやすくするために1つとしている。また、処理の中に記述するものも最低限のものに絞った。
まずは感嘆なDAGファイルを作成した。このあと、後続に処理をつなげたり、並列実行してみたり、また様々なデータソースへもつないでいってみようと思う。