この問題をPythonで解いた。
#6 Sum square difference - Project Euler
日本語の問題文はこちら
最初の10個の自然数について, その二乗の和は,
12 + 22 + ... + 102 = 385 最初の10個の自然数について, その和の二乗は,
(1 + 2 + ... + 10)2 = 3025 これらの数の差は 3025 - 385 = 2640 となる.
同様にして, 最初の100個の自然数について二乗の和と和の二乗の差を求めよ.
ans1 = 0 for i in range(1,101): ans1 += i ** 2 print(ans1) ans2 = 0 for i in range(1,101): ans2 += i ans2 = ans2 ** 2 print(ans2) print(ans2 - ans1)
この問題をPythonで解いた。
#5 Smallest multiple - Project Euler
日本語の問題文はこちら
2520 は 1 から 10 の数字の全ての整数で割り切れる数字であり, そのような数字の中では最小の値である.
では, 1 から 20 までの整数全てで割り切れる数字の中で最小の正の数はいくらになるか.
from math import gcd
from functools import reduce
def lcm(a,b):
return a*b//gcd(a,b)
print(reduce(lcm, range(1,21)))
この問題をPythonで解いた。
#4 Largest palindrome product - Project Euler
日本語の問題文はこちら
左右どちらから読んでも同じ値になる数を回文数という. 2桁の数の積で表される回文数のうち, 最大のものは 9009 = 91 × 99 である.
では, 3桁の数の積で表される回文数の最大値を求めよ.
ans = []
for a in range(999, 99, -1):
for b in range(999, 99, -1):
result = str(a * b)
if result == result[::-1]:
ans.append(int(result))
print((max(ans)))
この問題を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)
この問題をPythonで解いた。
#2 Even Fibonacci numbers - Project Euler
日本語の問題文はこちら
フィボナッチ数列の項は前の2つの項の和である. 最初の2項を 1, 2 とすれば, 最初の10項は以下の通りである.
1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ... 数列の項の値が400万以下のとき, 値が偶数の項の総和を求めよ.
sum,a,b, MAX = 0, 1, 2, 4000000
while b < MAX:
if b % 2 == 0:
sum += b
a, b = b, a+b
print(sum)
この問題をPythonで解いた。
#1 Multiples of 3 or 5 - Project Euler
日本語の問題文はこちら
10未満の自然数のうち, 3 もしくは 5 の倍数になっているものは 3, 5, 6, 9 の4つがあり, これらの合計は 23 になる. 同じようにして, 1000 未満の 3 か 5 の倍数になっている数字の合計を求めよ.
three_or_five = [i for i in range(1,1000) if i % 3 == 0 or i % 5 == 0] ans = sum(three_or_five) print(ans)
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まで種類があるのでカーディナリティが高い状態と言える。
