Day11_AzureDataFactoryの続き【備忘録】
始まる前に少しカンパ先生からあった解説。
Azure Data Factoryのデータフローにおける「sink（シンク）」は、データの出力先を意味します。データは「ソース」から取り込まれ、さまざまな変換や処理を経て、最終的に「シンク」に書き出されます。
クラウドサービスでは従量課金制を採用しているため、処理が完了したデータのみが保存されます。途中段階のデータを自動的に保存すると、その分も課金対象となってしまうため、自動保存は行われません。これにより、未完成のデータによる不要なコスト発生を防いでいます。
またデータレイクとデータウェアハウスを分かりやすく説明するために、2つを「大量の積本」と「本棚」に例えて解説を試みます。
データレイク＝大量の積本
データレイクは、部屋に無造作に積み上げられた大量の本の山のようなものです。
これらの本（データ）はジャンルや種類を問わず混在しており、あるものは整理されているかもしれませんが、多くはそのままの状態で積まれています。
専門書、漫画、小説、雑誌などが一緒くたになっており、必要な本を見つけ出すには時間と労力が必要となります。
つまり、データレイクは大量の未処理データをそのままの形式で保存し、後で必要に応じて取り出し、処理・分析できるものと解釈することが出来ます。
すべてのデータが「そのままの形で保管」されている点がポイントです。
データウェアハウス＝仕分けされた棚
一方、データウェアハウスは、きちんと仕分けされた棚に整理された本のようなものです。
ジャンルやテーマごとに本が並べられ、ラベルや番号が付けられているため、探したい本をすぐに見つけることができます。
この棚にある本は、特定の目的や利用のために事前に分類・整理されており、必要な情報に迅速にアクセスできます。
つまり、データウェアハウスは、整理されたデータを格納し、効率的にレポート作成や分析を行うためのデータベースであり、データが「整理されて」保存されています。
【注意点】データウェアハウスでのデータ欠損
データウェアハウスでは、データを事前に整理・加工して保存するため、元のデータから一部の情報が除外される可能性があります。
不要と判断されたデータや形式に合わないデータが削除されることで、後から必要になる情報が欠落し、分析結果に影響を与えるリスクがあります。
この例から分かるように、データレイクは柔軟性が高いものの、データの整理や検索には手間がかかります。
一方、データウェアハウスは、特定の目的に最適化されたデータを迅速に扱えますが欠損データが発生してしまう可能性があります。
前回までのAzureDataFactory利用の続き
前回の状態からのスタートになります。
まだの方はDay10からの見直しが必要です。
まずは前回の状態から始めますが、データフローのデバックが出来ていなければ、それを操作しておきましょう。
下記の様に前回つくった新しい列が出ている状態を確認します。
データフローのデバッグって、つまり何のこと？（僕なりの解釈）
デバッグ＝プログラムやデータ処理において発生するエラーや問題点を見つけて修正する作業。
つまり、処理が正しく動作しているかを確認し、不具合を取り除くためのプロセスを指す。作業が正しく行われているかをテストする機能。各ブロックでデータがどのように変化するかをリアルタイムで確認できる。エラーや問題を作業工程ごとに発見し、それに応じて修正が可能。運用本番となる前段階でデータフローを検証しながら作成することができる。
ここから、次は選択を行って必要な列だけを残す手順を行います。
付け足すと第一階層に何が記されているかが出てきます。
「としての名前」はどう表示するかという意味になります。
※Asを意味するものでSQL（後述）の名前変換などに使われるとのこと。
【ワンポイント調べ】
DataFactoryでの「としての名前」は、SQLのASと同じように、別名を付けることを意味します。データフローの中で、特定のデータ列や変数に対して別名を付けて扱う際に使われます。これにより、後の処理や表示でその名前を使ってデータを簡潔に参照できます。
今回は【body】と【headers】は不要なので、右のゴミ箱マークで捨ててしまいましょう。
表示としては残るのが下記画像の4つとなります。
データのプレビューを最新にすると、必要な項目だけが残されて表示されるようになりました。
こういった形で状況確認が工程の途中で出来るのも、先のデータフローのデバックを行っていたからです。
今回は元の天気予報APIから取得したデータが4つの項目で整理された状態に変換されたことになります。
もし必要なデータが他にある場合は、元データであるデータレイクから変換の手順を変えていく必要があります。
NULLがあるデータ部分を修正していく
今はNullと表示されているデータがあります。
それを修正していきましょう。
Null（ヌル）は「値が存在しない」または「未定義」であることを示す。空やゼロとは異なります。
例えば、ある銀行口座があったとして、まだ何も入力されていない状態が「空」となります。
そして残高0円が「ゼロ」を意味します。
Nullは「口座そのものがない」ような状態を指します。
【端的に言うと】
Null＝データの不存在
空＝データが未入力
ゼロ＝０というデータ
今回は、元データの中から取れている左側のpublicTimeから情報を取るようにします。
これをderivedColumnから修正を行います。
Nullだった時間が修正されて表示されるようになりました。
日付と時間を分離させて表示させる
どうやればいいのか分からない時、Googleで検索するのが今までの流れだったと思います。
しかしながらマイナーな作業を行っている場合は調べても最適解が出ない可能性もあります。
その場合はChatGPTに聞いて確認してみましょう。
※特にプログラミング類に強いと言われるChatGPTなので、積極的に利用してみると良いです。
一度でChatGPTが正しい回答が出るか分からないので、エラーが出たら修正を依頼して何度も試すことになります。
今回は僕が成功した数式の下記を利用します。
カンパ先生がSlackでも表示しているので、それを利用しても良いです。
●日付だけを表示する
substring(toString(body.publicTime), 0, 10)
●時間だけを表示する
substring(toString(body.publicTime), 11, 8)【式ビルダーを開く】からコードを入れられるページを開きます。
この式の部分にChatGPTに指示されたものを入れます。
timeの方も同じ様に実施しましょう。
それが出来たら、次に【設定の選択】を一度リセットして、新たな【forecast_date】と【forecast_time】を残して、完了です。
データのプレビューを行うと、日付と時間が分離された状態で表示されているのが分かったと思います。
ChatGPTに作業を依頼することで、たとえば時間の部分の「T」の表示や、ロケーションの「の天気」を「天気」に修正することも出来ます。
ここは作業工程が分かりやすいように、新たなブロックを作って表示を変化させています。
（同じ様にこれに該当する数式をChatGPTが教えてくれます）
SQLデータベースを作る
次にデータベースを作ります。
データベースと、前回作ったコンテナは概念が違うものとなります（まっちゃんさんの質問から）。
コンテナ＝データレイク。生のデータを管理している。
例：「大量の積み上げられた未整理の本」
データベース＝整理されたデータを管理している。
例：「整理された本棚」
※ちなみにデータウェハウスは更に必要な情報が統合されたもので、言ってみれば「ビジネス分析のために整理された大規模な書店」のイメージです。
今回作るのはSQLと呼ばれるデータベースです。
SQLはテーブル形式（エクセルのような形）で構造管理するデータベース。WEBサイト作成をしたことがある人ならMySQLというデータベースを聞いたことがあるかもしれません。
まずはAzureポータルのトップ画面から検索窓に「SQL」と入力し、SQLデータベースを選択する。
SQLデータベースを新規で作成します。
リソースグループはいつも通り、自分のものを検索して入力。
次にデータベース名も本来は分かりやすくプロジェクト名などにしますが、今回はai1stとして名前と番号を入れておきます。
そして【サーバー】の部分のみ新規作成を選択しましょう。
サーバー名は過去の入力（世界の誰とも）と被らないものを入力します。
今回はいつも通りai1stから番号と名前を入れています。
そして場所は自分の住所と近い場所にしておきましょう。
下にスクロールしていき、認証を今回は【SQL認証】を使用します。
要するにIDとパスワードによる認証です。
※IDとパスワードを忘れないように（パスワードは生成ツールを検索して利用すればOKです）
次に表示される部分で【ワークロード環境】については確実に【開発】にしておきます（金額が上がるため）。
次にコンピューティングとストレージについては【汎用目的】になっているかを確認しましょう。
その確認が終わったら【確認および作成】を押します。
確認の画面で右側に推定の費用が出ているので確認しておきましょう。
問題が無ければ【作成】を実施。
デプロイが進行するので、待機です。
デプロイとは、ソフトウェアを開発環境から実際に利用される本番環境に移すプロセスを指す。要するに、作ったソフトウェアをユーザーが実際に使えるようにすることです。
完了画面が出たらこれでMicrosoft社のサーバーの中に自分の使うリソース部分を手にしたことになります。
確認したらリソースに移動します。
作成したSQLが出来上がっていることを確認しましょう。
次にSQLへのアクセスを許可する権限付与を行います。
まずAzureポータルのメイン画面を表示させましょう。
その中で自分自身の【リソースグループ】を選択します。
そこで新たに、先程つくったSQLデータベースと、SQLServerが出来ています。
この【SQLServer】の方を選択します。
SQLServerの中の【セキュリティ】タブから【ネットワーク】を選択します。
デフォルトでは【無効化】になっているので、ここで【選択したネットワーク】を選択しましょう。
これによって「アクセス出来ません」という状態から「この環境からなら接続可能」という状態に変更できます。
画面をスクロールして【ファイアウォール規則】にある【クライアント～】を選択して、今接続している環境からのアクセスを許可します。
次に【Azureサービスおよびリソースにこの～】の部分にチェックを入れます。
それが出来たら【保存】を選択しましょう。
これで今の環境下でもSQL上の作業が可能になりました。
次に先ほど作成したSQLデータベースから【クエリエディター】のタブを選択し、SQLにログインをしましょう。
ログインが問題なく出来ればOKです。
次回は、データを利用して表やグラフを作成する手順を行っていきます。
データ分析の意義を再考する
現代のビジネス環境において、データ分析は企業の成長と発展を支える不可欠な要素となっています。
しかし、分析を学び始めたばかりの段階では、手順や作業に集中しすぎて、その本質的な意味や目的を見失いがちです。
今回はデータ分析を学ぶ過程で「作業」に囚われず、俯瞰的な視点を維持する重要性についてお伝えします。
作業ベースはダメ、分析の意味を見失わない
データ分析を学ぶ初期段階では、データの収集や整理、基本的な統計手法の習得といった具体的な作業に多くの時間と労力を費やします。
これらの作業の大枠理解は確かに重要ですが、作業自体に執着しすぎると、分析の本来の目的である「課題の発見と解決」を見失ってしまう危険性があります。言わば組み立て家具の各パーツを丁寧に組み立てることに集中しすぎて、完成図を見ていないような状態と言えます。そうすると「これは一体どの部分だ？」という本末転倒な状態になってしまうでしょう。
作業に没頭すると、最終的な目標を見失いがちです。
これ防ぐためには、常に全体像を意識し、分析の最終目的を明確にすることが重要です。
データ分析は単なる作業の積み重ねではなく、企業の成長を導くための羅針盤として機能するのが望ましいものと言えます。
作業に没頭しすぎず、なぜその作業を行っているのか、その結果何を達成したいのかを常に問い続ける姿勢が求められるのです。
スイムレーン図を活用してボトルネックを探し出す
分析の目的を見失わないためには、まず業務プロセス全体を俯瞰的に理解する必要があります。
ここで有効なのがスイムレーン図などの可視化ツールというのは前半の講座でもありました。
『ザ・ゴール』という著書でも紹介されているように、業務プロセスの中でのボトルネックを見つけ出すことは、全体の効率を向上させるために不可欠です。
例えば、ある製造業の企業が生産ラインの効率を向上させたいと考えたとします。スイムレーン図を用いることで、各工程の担当者や部門ごとの作業の流れを視覚的に把握できます。
すると、特定の工程で作業が滞っていることが明らかになり、その原因を探ることが可能です。これにより、どの部分に改善の余地があるのかを具体的に見つけ出すことができるでしょう。ナビ上で高速道路の渋滞箇所を特定するように、スイムレーン図は業務プロセス全体を一目で理解し、効率化への道筋を見つけ出す手助けをしてくれます。
改善に必要なデータを取得するための合意形成
ボトルネックを特定した後、その改善に必要なデータを取得することが次のステップとなります。
しかし、データは簡単に手に入るものではありません。
多くの場合、異なる部門やチームからデータを集める必要があり、その過程で関係者間の合意形成が不可欠です。
生産ラインの改善を図るためには、生産部門からの詳細な生産データ、品質管理部門からの検査データ、販売部門からの売上データなど、多岐にわたる情報が必要となります。
これらのデータを統合し、信頼性の高い分析を行うためには、各部門の協力と理解が求められるのは言うまでもありません。
合意形成を円滑に進めるためには、分析の目的や期待される成果を明確に共有し、各部門の意見や懸念を尊重しながら進めることが求められます。
以前、ナカマコ氏が語っていた自らの手持ちでヘルメットなどを準備して向かう姿勢などが、それに該当してきます。
これにより、データの取得がスムーズになり、効果的な分析が可能となります。
改善作業の意味を考える
データ分析を行う手順は、単なる作業の連続ではありません。
その背後には、企業の持続的な成長と競争力の維持といった大きな目的があります。
データを分析し、課題を発見し、解決策を実行する一連のプロセスは、企業が変化する市場環境に適応し、常に最適な状態を保つために欠かせないものと言えるでしょう。
レストランがメニューを改善する際に、売上データや提供速度、顧客のフィードバックを分析することで、人気のない料理や厨房リソースを食いすぎている商品を見つけ出し、メニューから外す決断をすることも出来ます。
結果として顧客満足度を高め、売上を向上させることができるのです。
このように、データ分析は具体的な成果をもたらし、企業の成功に直結する重要な活動となります。
また関係者との合意形成を通じて、分析結果に基づいた改善策を実行することで、組織全体の協力体制が強化され、持続的な成長が可能となるでしょう。
データ分析は、企業内のコミュニケーションを促進し、共通の目標に向かって一丸となるための基盤を築く役割も果たします。
改めて考える
作業に囚われず、分析の本質的な意味を見失わないことが、効果的なデータ分析を行うために常に意識すべき点となります。
今やっている作業ベースのものも、すべては後に訪れる航海においての灯台になるべく、マクロな視点での観察を忘れないようにしていきましょう。
この記事が気に入ったらサポートをしてみませんか？