オンプレミスからクラウドにデータを移行する方法：Amazon S3

クラウドへの移行 2018年はクラウドの年であり、クラウドテクノロジーに移行する企業が増えるにつれて、ビジネスがクラウドを最大限に活用する方法を理解することが重要となります。企業が今日抱えている大きな問題の1つは、オンプレミスのデータベースからクラウドデータストレージへのデータの移行です。適切なツールがなければ、これは時間のかかる退屈なプロセスになります。幸いなことに、ここでTalendを役立てることができます。 Talendでは、オンプレミスのデータベースであるMySQLをクラウドストレージのAmazon S3に移行する必要がありました。Apache Sqoopの複雑さに対処する代わりに、いつでも新しいデータをクラウドへ移行できるジョブをTalend内に作成することにしました。この方法を使用することで貴重な時間を節約でき、その分を新しく移行したデータの分析に使用できました。このブログでは、このジョブをどのように構築したかを振り返ります。早速始めましょう。 接続の作成 Talendのジョブと同様に、最初に接続を作成します。MySQLデータベースに対しては、tMysqlConnectionコンポーネントを使用します。また、tS3Connectionを使用してS3クラウドストレージへの接続を作成する必要があります。このジョブを実行するたびに、毎回MySQLとS3の両方に接続することになるので、両方のコンポーネントの前にtPrejobを追加する必要もあります。 Talendはコード生成ツールであり、tPrejobを使用することで、常に最初にコンパイルするものを制御でき、常にデータベースに接続できるようになります。両方の接続コンポーネントを構成した後、次のスクリーンショットのようにtPrejob、tMysqlConnection、tS3Connectionを接続できます。 テーブルの取得と動的スキーマの設定 両方のストレージプラットフォームに接続したので、MySQLからAmazon S3へのクラウド移行プロセスを開始できます。まず、データベースから移動する、すべてのテーブルのリストを取得する必要があります。tMysqlTableListを使用して、「WHERE句」を使用してリストするテーブルを指定できます。ただし、今回は顧客テーブルからのみ取得します。 転送対象の全テーブルのリストを取得したので、次にそのテーブル内の列のリストを取得します。 「tMysql」グローバル変数を使用することは、コンポーネントから値を取得するのに最適な方法です。これらのグローバル変数は、他のコンポーネントが使用する「tMysql」コンポーネントからデータを取得できます。この場合、((String)globalMap.get(“tMysqlTableList_1_CURRENT_TABLE”))は、tMysqlTableListコンポーネントによって収集されるテーブルからコンポーネントに列を取得させます。Talendでは、グローバル変数を記憶しなくとも簡単に検索できます。「tMysql」と入力してCtrl + スペースキーを押すだけで、すべての「tMysql」グローバル変数がリストに表示され、必要な変数を選択できます。 次に、tFixedFlowInputを追加して、「tableName」列と「columnName」列を生成する必要があります。最初にこれらの列のスキーマを構成した場合、値はtFixedFlowInputコンポーネント内にのみ表示されます。スキーマを設定したら、これらの列の値を設定できます。「tableName」については((String)globalMap.get(“tMysqlTAbleList_1_CURRENT_TABLE”))、「columnName」については((String)globalMap.get(“tMysqlTAbleList_1_COLUMN_NAME”))になります。 固定フローの後にtLogRowを追加すると、実行コンソールに情報を表示することで、ジョブの取得元であるテーブルと列の名前を確認できます。以下は、これまでのジョブを示すスクリーンショットです。 次に、オンプレミスデータベースからデータを取得するときに、データが使用する動的スキーマを設定します。名前が示すように、動的スキーマは、その時点で読み取られる列に応じて変化するスキーマタイプであり、ジョブに不可欠です。 動的なスキーマを設定するには、tSetDynamicSchemaというコンポーネントを使用します。tSetDynamicSchemaを使用すると、値「columnName」に基づいてスキーマを動的に設定できます。スキーマが動的になったので、各テーブルを個別に移動する必要はなくなり、複数の異なるテーブルを簡単に移動できます。 データの読み取りとテーブルの書き込み 動的スキーマを設定したら、tSetDynamicSchemaコンポーネントから作成された動的タイプを使用して、テーブルデータの読み取りを開始する準備ができました。オンプレミスのデータベースからデータを読み取るため、MySQLデータベースのtMysqlInputから読み取る入力コンポーネントを使用する必要があります。最初に、tMysqlInputコンポーネントのスキーマを編集して、動的DBタイプを使用する必要があります。このスキーマの列に「dynamic_row」という名前を付け、タイプは（もちろん）「Dynamic」、DBタイプは「VARCHAR」を指定します。 スキーマを設定したら、tMysqlInputコンポーネントを構成し、tMysqlTableListによってリストされている現在のテーブルからデータが取得されることを確認します。 テーブル内のデータは現在リストされている現在のテーブルから読み取られますが、依然としてデータをCSVファイルに書き出す必要があります。このために、tFileOutputDelimitedを使用します。「ファイル名」が正しいファイルパスに従っていることを確認する必要があります。 もう少しで終わります。以下は、これまでに作成したジョブを示すスクリーンショットです。 Amazon S3へのファイルの配置 これまでのところ、このジョブはcustomerという名前のすべてのテーブルを読み取り、指定されたフォルダー内のCSVファイルに書き込みます。オンプレミスのデータベースにあるテーブルからデータを取得できるようになったので、これらのファイルをAmazon S3に移動してジョブを完了します。 tFileListを使用すると、指定したフォルダー内に含まれる全ファイルのリストを取得できます。ここでは、オンプレミスデータベースから取得した全テーブルのリストを取得できます。ファイルを配置するディレクトリを指定する必要があるだけです。 すべてのファイルのリストを取得したら、それらをS3バケットに移動し始めることができます。そのために、tS3Putコンポーネントを使用します。「Bucket」、「Key」、および「File」を指定するだけです。「Key」はS3内のファイルの名前であり、「File」はS3にアップロードされるファイルの名前です。 tFileListとtS3Putの構成が完了したので、あとは、クラウド移行ジョブに最後の仕上げをするだけです。ジョブの最初に開いた接続を覚えていますか？ tPostjob、tMysqlClose、tS3Closeを使用すると、ジョブが実行されるたびに開いた接続を閉じることができます。ここでも、メインループがコンパイルされた後に何が起こるかを制御でき、tPostjobコンポーネントの意義が発揮されます。簡単ですね。完成したジョブは、次のようになります。 ジョブの実行 ジョブが実行され、すべてが正常に処理すると、実行コンソールは下のスクリーンショットと一致するはずです。ご覧のとおり、コンソールには、読み取りおよび書き込み中のテーブルと、対応する列名が表示されます。 ジョブが完了したので、テーブルごとに複数のジョブを作成したり、厄介なハンドコーディングに煩わされたりすることなく、オンプレミスデータベースからクラウドストレージに任意のテーブルを移動できます。クラウド対応の準備が整うのは気持ちの良いことです。 デモをライブで視聴 このデモをライブで視聴するには、3月22日（木）にTalendのFacebookページに参加してください。#TalendDevLive ではジョブを構築する手順を紹介し、質問にも答えます。お見逃しなく！

Read Article

データモデルの設計とベストプラクティス（第2部）

  データモデルとは何を指すのでしょうか。毎日データモデルに接して熟知しているTalendの開発者は、以下のようにデータモデルを定義しています。 ビジネスシステムデータの構造的定義 ビジネスデータのグラフィカルな表現 ビジネスソリューションを構築するためのデータ基盤 これらはいずれも真実かもしれません。しかしあえて言うなれば、いずれも本質的な定義ではありません。それぞれ単独では、データモデルが本来実現すべき核心/目的あるいは目標に到達するものではなく、末梢的であるためです。 では、何が本当にデータモデルであると言えるのでしょうか。あれこれ思いつくものの、やはり一点に尽きるのではないでしょうか。私にとって、データモデルは、ビジネス情報システムをグラフィカルな方法で明確に特徴付けるものとして表現される構造基盤です。どう思われますか？ 上記の定義と同一というわけではありませんね。この定義は、すべての要素を単一の目的に包含します。つまり、データだけでなく、構造的にビジネスのユースケースに関する情報を識別するための手段なのです。 このブログシリーズの第1部では、50年間のデータモデリングの歴史を4つの短い段落にまとめました。省いた部分もありますが、前任者から学んだ教訓と改善の結果として、データモデリングに関する私たちの知識や達成がどのように実現したのかを理解できるのではないでしょうか。今日、ほとんどの企業が要件を検証するために活用してるデータモデルには、真のビジネス価値があります。しかし、これらの企業が正しい方法を理解しているかどうかを疑問に思うことがよくあります。多くの場合、永続性のあるデータモデルに対する幻想は、とりあえずモデルが存在するという事実のみによって推定され、それが正しいかどうかは確認または検証されていないのです。 私は、データアーキテクチャーとデータベース設計の実務家として、あまりにも多くの粗悪なデータモデルを目にしてきたため、ほとんどのデータモデルには何らかの問題があると言わざるを得ません。その一方で優れたモデルも多く見てきましたが、それではデータモデルの良し悪しをどのように判断できるのでしょうか。それは重要なことなのか、データの出入りに問題がなければ十分ではないのか、と疑問に思われるかもしれません。しかし、データモデルの良し悪しは明らかに重要なのです。データモデルを基盤として/データモデルと協調して運営されるビジネスシステムを確実に成功させるためには、データモデル自体が優れたものである必要があります。データモデルはビジネスの本質です。したがって、包括的であり、非の打ちどころがなく、回復力のあるものでなければなりません。 このことから、優れたデータモデルを使用する動機は明らかです。Talend StudioのようなETL/ELTツールを使ってデータを出し入れし始めると、それが明らかになります（ほとんどの人には）。どのようなソフトウェアプロジェクトでも、データモデルは欠かすことのできない3つの技術的要素の1つです。ほかの2つの要素は、アプリケーションコードとユーザーインターフェイスです。 本シリーズの第1部では、私が設計するすべてのデータモデルで採用されているデータベース開発ライフサイクル（DDLC）の方法論を取り上げましたが、お読みいただいたでしょうか。この方法論は私にとって役立つものであり、データベース開発に本気で取り組んでいるすべてのチームはぜひとも採用すべきです。このプロセスを理解して採用することで、データモデルの実装と保守を合理化/自動化/改善できます。しかし、このプロセスについては、ほかの事柄も検討する必要あります。ビジネスに貢献する信頼性、柔軟性、正確性を備えたデータモデルを促進できる、追加のベストプラクティスをご紹介します。 データモデリングのベストプラクティス 多くのデータモデルは、モデラーが論理モデルを作成してから物理モデルを作成するプロセスによって設計されます。通常、論理モデルは実体と属性、および両者を結び付ける関係を記述して、データのビジネス目的を明確に表現します。続いて、物理モデルは論理モデルを実装します（論理モデルは、テーブル、列、データ型、索引として、簡潔なデータ整合性規則と共に実装されます）。これらの規則は、プライマリーキーと外部キー、およびデフォルト値を定義します。さらに、必要に応じて実装をサポートするために、ビュー、トリガー、ストアドプロシージャーが定義されることがあります。物理モデルは、ほとんどのホストシステム（Oracle、MS SQL Server、MySQLなど）が提供する特定の構成オプションに基づいて、ディスク上のストレージ割り当ても定義します。 納得できることですね。それにもかかわらず、私は論理モデルと概念モデルの違いをめぐる激しい議論を何度も経験してきました。多くの人は、これら2つは同じであり、どちらもビジネスデータの実体と属性を提示するものであると言います。私も同意見です！概念モデルは、データに対するビジネス上の理解（技術的な理解ではありません）についてコンテキストを提供することを目的とします。概念モデルはすべてのステークホルダーが理解できるものであり、多くの人が実体と属性に取り組んでいます。適切な概念モデルは、すべての関係者にとってビジネスデータのコミュニケーションのために最善のツールになります。統一モデリング言語（UML）の側面を使用することで、概念モデルを図解して、細かい事柄にとらわれずにシンプルに保持できます。詳細は論理モデルと物理モデルで不可欠ですが、それぞれで洗練させればよいでしょう。 一般的に多くのアプリケーションシステムを使用しているエンタープライズビジネスでは、データのモデル化で高次の懸念が生じます。概念モデル、論理モデル、物理モデルだけでは十分ではありません。そこで登場するのが、全体論的データモデル（少なくとも、私がそれを改造したモデル）です！ 全体論的データモデルの目的は、企業全体でデータサイロを識別・抽象化することです。これにより、データサイロが存在する場所、必要な場所、相互に関連する場所、そして最も効果的に使用するために体系づける方法を大局的に説明します。 データモデリングプロセスの4つの階層 企業内に4タイプの異なるデータモデルが存在する可能性を考慮して、定義、理解の洗練化、および具体的な設計のために、「階層」としてトップダウン型で従うデータモデリングプロセスを次のように提案します。各レベルの主要な役割については、プロセスのどこで誰が関与したかを明確にします。 全体論的データモデル： 全体論的な層は、全社的なデータサイロの抽象的な環境を表します。このデータモデルは、広範なビジネスデータガバナンスを確立する機会を生み出し、それによって企業に固有のすべてのデータ関係に対する理解を深めることができます。それらのサイロは、社内外のアプリケーションからのデータを取り込むことを目的としています。バブルチャートを使用すると、全体論的データモデルを図解できます。以下のように設計します。 バブルチャート – データサイロ バブルチャートは、一意のデータサイロを表す単純なバブルで構成されます。2つ（2つだけ）のバブルを結ぶ線（「リンク」）は、2つの間に何らかの関係が存在することを示します。基本的には、バブルの各集合（多くの場合、放射状の「スポーク」を持つ中心の「ハブ」として示されます）は、企業全体で識別された特定のデータサイロのセットを具体化するものであり、それ以上でもそれ以下もありません。要素の詳細は以下のとおりです。 青色の実線で表されたリンクは、2つのデータサイロ間の直接的な関係を示します。赤色の破線で表されたリンクは、2つのデータサイロ間の間接的な関係を示します。緑色の点線で表されたリンクは、2つのデータサイロ間の拡張された関係を示します。これらのリンクは、複数の関係（概念層で定義）を表すことがあるため、主観的に使用します。単に関係が存在すると定義します。 バブルの周囲を、より大きいバブルが囲むことがあります。大きい方のバブルは、そのデータサイロに固有の分類を体系化するオントロジーが存在する（または存在すべきである）ことを意味します。オントロジーとその分類メタデータは、それが囲むサイロへの有意義なマッピングを提供します。これは、データを高度に検索可能にするのに大いに役立つものであり、この層で識別されるべきです。 バブルチャートは、ビジネス情報の特定の集合を定義します。その目的は、サポート対象のアプリケーション、実装または技術的詳細がない情報を識別、単純化、統合することです。全体論的データモデルのメリットは、すべてのオーディエンスが単一の包括的かつ単純化されたビューで企業データ環境を理解でき、基盤となるデータモデルをほとんど/まったく中断することなく新しいデータを識別してモデルに挿入する（後述）ための柔軟な出発点を提供できることです。 ここに示したのは、完全に定義された全体論的データモデルの図解の一例です。プリンターで大きく印刷して壁に貼り、皆で検討することで、活発で生産的な会話が生まれ、それがビジネスにとって効果的で価値ある資産になります。 概念データモデル: 概念層は、ビジネスデータ要素とそれらの関係の抽象的な定義を表します。このデータモデルは、アプリケーションの観点から企業データ環境のセマンティクスを定義し、これによって基盤となるビジネス情報の理解が深まります。UMLは、このモデルを設計するためのグラフィカルな手段となります。要素オブジェクトから成る概念データモデルは、全体論的モデルのデータサイロから抽出された情報クラスを定義します。基本的には、これを情報モデルと考えることができます。以下のように設計します。 UML情報アーキテクチャー 各要素オブジェクトは、データサイロの特定部分と、2つ（やはり2つだけ）の要素間の関係を定義する接続線（「リンク」）をカプセル化します。特定の要素項目（「特性」）は、オブジェクトの理解と目的をさらに支援するために定義され、以下のいずれかになります。 保護（値は事前に決定） パブリック（値は可変） プライベート（値の使用が制限） 直接的に相互接続された要素オブジェクトは、グレーの実線のリンクと意図的なラベルによって示される「関連付け」を持つと見なされます。これらの関連付けは、親要素に付けられた菱形により、次のいずれかの関係を表します。 単純（菱形なし） 共有（塗りつぶしのない菱形） 複合（塗りつぶされた菱形） 子要素が「ナビゲート可能」な場合は、矢印と関係基数（0.* = ゼロから多数、など）で示されます。 要素オブジェクトは、「一般化」を持つこともできます。つまり、オブジェクトのインスタンスは、特定または一意の特性や関係を持つことができます。この例では、オブジェクトは1つの親要素のサブクラスに似ており、親のすべての特性に加えて、関連する一意の特性をすべて追加的に含みます。サブクラス要素は、その名前と表現の両方で洗練化されることで、抽象化された全体論的データサイロの理解しやすい洗練化を提供します。要素オブジェクトに結合する一般化は、親オブジェクトに閉じた矢印が付いた青色の実線のリンクで示され、ラベルは不要です。 …

Read Article