データモデルとは何を指すのでしょうか。毎日データモデルに接して熟知している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つの親要素のサブクラスに似ており、親のすべての特性に加えて、関連する一意の特性をすべて追加的に含みます。サブクラス要素は、その名前と表現の両方で洗練化されることで、抽象化された全体論的データサイロの理解しやすい洗練化を提供します。要素オブジェクトに結合する一般化は、親オブジェクトに閉じた矢印が付いた青色の実線のリンクで示され、ラベルは不要です。 …
続きを読む
The Data Model is the essence of the business and therefore must be comprehensive, unimpeachable, and resilient.
詳細
データレイクの主な目的は、分散した異種のデータサイロにさまざまな（場合によっては限定的な）データセットを格納する代わりに、生の（フィルタ処理されていない）組織データに完全かつ直接アクセスすることです。
詳細
ビジネスアプリケーション、データ統合、マスターデータ管理、データウェアハウジング、ビッグデータデータレイク、機械学習といったものは、いずれもデータモデルが共通の基本的要素となります（または、そうあるべきです）。この点を常に念頭に置きましょう。あるいは、（よく見られることですが）完全に無視することがないように注意してください。 データモデルこそが、Eコマースから、PoS、財務、製品、顧客管理、ビジネスインテリジェンス、IoTまで、Talendの高価値でミッションクリティカルのビジネスソリューションのほとんどすべての支柱です。適切なデータモデルがなければ、ビジネスデータはおそらく失われてしまうでしょう！ Talendのジョブ設計パターンとベストプラクティスについて取り上げたブログシリーズ（第1部、第2部、第3部、第4部）では、32のベストプラクティスを紹介し、Talendでジョブを構築する最善の方法について述べました。その中で予告したデータモデリングについて、以下に述べたいと思います。 データモデルとデータモデリングの方法論は、ずっと以前（コンピューティングが始まった頃）からありました。構造は、データが意味を成すために必要であり、コンピューターが実際に処理するうえでの一手段を提供します。確かに、今日では非構造化データや半構造化データも処理されるようになっています。しかし、それは単に、一層洗練された規範へとデータ処理が進化したことを意味するだけではないでしょうか。したがって、データモデルの意義は現在も変わるものではなく、高度なビジネスアプリケーションを構築するための基盤となっています。Talendのベストプラクティスと同様、データモデルとデータモデリングの手法にも真剣に向き合う必要があります。 ダウンロード >> Talend Open Studio for Data Integration 新たな洞察を得るべく、データモデリングの歴史を振り返ってみましょう。 データモデルの進化 「コンピューティングの暗黒時代」には、フラットなレコードのレイアウト（配列）が使用され、すべてのデータは後で取得できるようにテープや大規模ディスクドライブに保存されていました。しかし、1958年に、J. W. YoungとH. K. Kentが、情報システムのモデリングは「データ処理の問題の情報的かつ時間的特徴を規定するための正確で抽象的な方法」であると論じました。その後すぐに（1959年）、CODASYL（Conference/Committee on Data Systems Languages）というコンソーシアムがミネソタ大学のチャールズ・バベッジ研究所により結成されました。これを契機として、COBOLのような標準プログラミング言語が作成され、1960年代にはGE/Honeywell社でIntegrated Data Store（IDS）という初期のデータベーステクノロジーがチャールズ・バックマンによって設計されました。IDSは使いにくいものであったため、Integrated Database Management System（IDMS）がB. F. Goodrich（米国のタイヤメーカーですが、当時は航空宇宙製造企業）により開発され、Cullinane Database Systemsにより販売されました（現在はComputer Associatesが所有）。これら2つのデータモデリングの方法論は、それぞれ「階層型データモデル」と「ネットワーク型データモデル」と呼ばれ、50年にわたってメインフレームコンピューティングで広く使用されてきました。現在でも使用しているケースがあります。 1960年代末、当時IBM社の社員だったエドガー・F・コッドは、クリス・J・デイト（『An Introduction to Database Systems』の著者）と協力し、自身の革新的なデータモデリング理論を確立して、1970年に「A Relational Model of Data for Large Shared Data Banks（大規模共有データバンクのデータ関係モデル）」という論文を発表しました。コッドは、ベンダーが方法論を正しく実装できるよう推進するため、1985に有名な「Twelve …
続きを読む
Talendのジョブ設計とベストプラクティスという取り組みは、新たな岐路にさしかかっています。役立つコンテンツの提供という私の努力は、1つの形になりました。好評をいただいているブログシリーズ（まだお読みになっていない方は、第1部、第2部、第3部をぜひご覧ください）、Technical Boot Campプレゼンテーション（参加いただいた方、ありがとうございます）、コンテンツの直接配信から、社内から組織の変革を求める声が生まれています。 この記事では引き続き、ジョブ設計パターンとベストプラクティスについて解説を進めます。まず、シンプルでありながら見逃されがちな事実をお伝えしましょう。それは、Talendは、Javaコードジェネレーターであり、開発者ガイドラインを確立することで、ジョブ設計パターンによって生成されるJavaコードを強化および合理化できる、という点です。これは明白な事実ですが、この概念に基づいてキャンバスを操作し、緻密なジョブ設計を行ってクリーンなJavaコードを生成することが、最善の結果への近道です。私はこれを、「成功主導のプロジェクト」と呼んでいます。 成功主導のTalendプロジェクト Talendジョブの作成は、非常に簡単な場合と、非常に複雑な場合があります。実装を成功へと導く秘訣は、良い習慣と必要な規範を採用し、適合させることにあります。 このシリーズの冒頭で「基本的指針」でお伝えしたように、私の目標は、ベストプラクティスに関する自由なディスカッションを行い、便利なジョブ設計パターンを確立することにあります。ジョブ設計および親子オーケストレーションは、ほとんどのユースケースにメリットをもたらします。そして、再利用可能なコードを含めることで、プロジェクト全体の成功が加速されます。もちろん、どの方法を選択するかは皆さんの自由ですが、一貫性の維持だけは必ず留意してください。 データベース開発ライフサイクル（DDLC） このシリーズではジョブ設計のみを扱ってきましたが、データについてはどうでしょうか。ジョブで処理するのはデータであり、ほとんどのデータはデータベースに格納されています。データベースにベストプラクティスは必要でしょうか。これは、修辞的な質問でしょうか。データモデル（スキーマ）は時間と共に変化しますから、データベース設計にもライフサイクルがあるのは当然です。 データベースは進化するので、開発者はこれに対応しなければなりません。われわれはSDLCプロセスを採用していますから、データベース開発ライフサイクルの必要性も簡単に理解できるはずです。環境（DEV/TEST/PROD）がどうであれ、データベースのサポートは必要です。 新規インストール – スキーマの現在のバージョンに基づきます アップグレード – アップグレードによりデータベースオブジェクトを削除/作成/変更します データ移行 – 破壊的な「アップグレード」（テーブルの分割など）を行います データベースライフサイクルと、それがジョブ設計にもたらす影響を理解することは、非常に重要です。ここで鍵となるのが、データベースモデルのバージョン管理です。規定された設計プロセスに従い、設計をグラフィック化し、「データ辞書」または「グロッサリー」を作成して変更履歴を追跡します。このトピックについては、ブログの別の記事でさらに詳しく解説する予定ですので、お楽しみに。それまでは、データベースモデルを作成する際には次のプロセスを検討してください。高度な規範ではありますが、効果的です。 さらなるジョブ設計のベストプラクティス では、すぐに役立つジョブ設計のパターンとベストプラクティスをさらにご紹介しましょう。よく使用するTalend機能やあまり使用頻度の高くない機能を詳しく解説します。ぜひ参考にしてください。 さらに検討すべき8つのベストプラクティス： tMapルックアップ ご存知のように、tMapの必須コンポーネントは強力な変換機能を備えているため、Tatlendジョブで広く使用されています。 tMapコンポーネントの最も一般的な用途は、ソース入力からターゲット出力へのデータフロースキーマのマッピングです。これは、シンプルな処理です。ソースとターゲットに複数のスキーマデータフローを使用することもできるため、データフローの複雑な結合や分割にも対応できます。また、変換式を使用すれば、どの入力データをどのような方法でダウンストリームに分割するかを制御できます。tMapコンポーネント内の式は、ソースとターゲットのスキーマに適用できます。また、tMapコンポーネントで定義した変数を使用することも可能です。以上の操作方法は、「Talend Components Reference Guide」で詳しく解説されています。使用する際には、「大いなる力には大きな責任が伴う」ことを念頭に置いてください。 tMapコンポーネントには、ソースデータフローと結合するルックアップを使用するという素晴らしい用途もあります。tMapコンポーネントに適用できるルックアップに物理的な上限はありませんが、実際には配慮すべき項目があります。 この基本的な例をご覧ください。ソースとルックアップという2つの行が生成されます。実行時には、まずルックアップデータが生成され、次にソースデータが処理されます。 ルックアップデータの結合が[Load Once]に設定されているため、レコードすべてがメモリにロードされ、ソースデータの結果セットに対して処理が行われます。これはデフォルト設定であり、結合で優れたパフォーマンスを発揮でき、非常に効率的です。 また、数百万のルックアップ行と数十のカラムをロードする場合には、かなりのメモリ容量が必要になります。数百万行のルックアップを複数回実行する場合はどうでしょうか。メモリ容量はどの程度必要でしょうか。レコード数が多い場合やカラム数が数百にのぼる場合には、ルックアップを慎重に検討してください。 では、メモリとパフォーマンスのトレードオフについて考えてみましょう。ルックアップには、3つのモデルがあります。 Load Once（一括ロード）– 該当するすべてのレコードをメモリに読み込みます Reload at each Row（行ごとに再ロード）– ソースレコードごとに該当する行を読み込みます Reload at …
続きを読む
このトピックに関する前回のブログ記事は大変好評だったようです。熱心な読者の皆様、ありがとうございます。 過去のブログ記事をまだ読んでいない方は、まずはこちら（Talendのジョブ設計パターンとベストプラクティス第1部と第2部）をお読みください。それぞれ異なるテーマを取り上げています。 ジョブ設計パターンとベストプラクティスの解説を始める前に、お知らせがあります。これまでのコンテンツを90分のテクニカルプレゼンテーションにまとめました。このプレゼンテーションは、「Talend Technical Boot Camps」にて、世界中で視聴いただけます。地域のイベントスケジュールは、TalendのWebサイトでご確認ください。プレゼンテーションでお会いできることを楽しみにしています。 このシリーズの内容について、コメント、質問、論点をお寄せください。ディスカッションを膨らませ、Talendコミュニティで展開できれば、と思います。「標準」ではなく「ガイドライン」であることを思い出してください。どうか、ご意見をお寄せいただき、ご協力をお願いいたします。 テーマを深める Talendプロジェクトをはじめとするソフトウェアライフサイクルを成功へと導くには、「開発者のガイドライン」の確立が不可欠であることを理解いただけたと思います。では、次に進みましょう。開発者のガイドラインの確立、チームによる採用、規律の段階的な浸透は、Talendで極めて大きな成功を収めるための鍵である、という点を解説します。これに、異論を唱える人はいないでしょう。Talendジョブの作成には、複雑な手順が必要です（ここでは詳しい説明はしません）。したがって、「ビジネスユースケース」、「テクノロジー」、「手法」を理解することによって、成功の確率が高くなります。時間をかけて、チームのガイドラインを作成することには十分な価値がありますし、成果があるはずです。 Talendユーザーが取り組んでいるユースケースの多くは、何らかの形でデータ統合プロセスに関連しています。データ統合はTalendのコアコンピテンシーであり、データの移動を意味します。データフローはさまざまな形態で発生するため、処理や操作の方法が重要になります。その重要性は非常に大きく、作成するあらゆるジョブの本質であるとも言えます。ビジネスデータの移動というユースケースにおいてTalendをテクノロジースタックの不可欠な要素として使用する場合、どのような手法を使用すればよいでしょうか。それはもちろん、これまでに解説したSDLCベストプラクティスなのですが、それだけではありません。データに関連する手法ですから、データモデリングも含まれます。これは、私の専門分野でもあります。私は、25年以上にわたるデータベースアーキテクトという経験の中で、数え切れないほどのデータベースソリューションの設計と構築に携わってきました。ですから、データベースシステムにもライフサイクルがあることを実感しています。フラットファイル、EDI、OLTP、OLAP、STAR、Snowflake、データボルトといったスキーマを問わず、データとそのスキーマが生成され、廃棄に至るまでのプロセスを無視することは、チームにとって弱点になり、最悪の場合は大惨事につながるのです。 このブログではデータモデリング手法は扱いませんが、適切なデータ構造設計を採用し、それに沿って使用することが非常に重要です。ぜひデータボルトのシリーズの記事をお読みいただき、今後掲載予定のデータモデリングの記事もご覧ください。現時点では、DDLC（Data Development Life Cycle）はベストプラクティスです。このことについて考えていただければ、私の意図を後で理解できるでしょう。 さらなるジョブ設計のベストプラクティス では、Talendのジョブ設計について、「ベストプラクティス」をさらにいくつかご紹介します。ここまでで、16のベストプラクティスを解説しました。あと8つあるのでお楽しみに（このシリーズには第4部があります。すべてを盛り込むことはできないので、記事を読みやすく分割しています）。 さらに検討すべき8つのベストプラクティス コードルーチン 状況によって、Talendコンポーネントではプログラミングのニーズを満たせない場合があります。それでも問題はありません。TalendはJavaコードジェネレーターです。キャンバスに配置し、プロセスやデータフローで使用できるPure Javaコンポーネントもあります。それでもニーズに対応できない場合があるはずです。そのようなときには、コードルーチンが役立ちます。これは、プロジェクトリポジトリに追加可能なJavaメソッドです。基本的に、ユーザー定義のJava関数であり、ジョブ内のさまざまな場所で使用できます。 Talendは数多くのJava関数を備えています。すでに使用されていると思います。 getCurrentDate – sequence(String seqName, int startValue, int step) – ISNULL(object variable) ジョブ、プロジェクト、ユースケースの全体像を考えた場合、コードルーチンにはさまざまな用途があります。ここで基本となるのは、再利用可能なコードです。それには、汎用な方法でジョブを合理化できるコードルーチンを作成することを、常に念頭に置く必要があります。適切なコメントを指定すれば、関数を選択する際に役立つテキストとして表示されます。 リポジトリスキーマ プロジェクトリポジトリのMetadataセクションでは、再利用可能なオブジェクトを作成することが可能です。これは、重要な開発ガイドラインですね。リポジトリスキーマは、ジョブで再利用可能なオブジェクトを作成する強力な手法です。以下が含まれます。 – ファイルスキーマ – さまざまなフラットファイル形式のマッピングに使用します。 Delimited Positional RegEx XML Excel JSON – 汎用スキーマ …
続きを読む
In my previous blog “Beyond ‘The Data Vault’” I examined various data storage options and a practical architecture/design for an Enterprise Data Vault Warehouse. As you may have realized by now I am quite smitten with this innovative data modeling methodology and recommend to anyone who …
続きを読む
前回掲載した、Talendのジョブ設計パターンとベストプラクティスの第1部は、非常に好評をいただきました。読んでくださった方、ありがとうございます。まだ読んでいない方は、ぜひお読みください。第2部では、第1部の内容をもとに、さらに詳細な内容を解説していきます。また、さらに高度な内容についてもいくつかご紹介しようと思います。 はじめに 私は、Talendの開発に長年携わってきましたが、他の開発者がジョブを作成する方法に対して常に興味を持っています。機能を正しく使用しているか、一般的なスタイルを使用しているか、それとも私が知らないスタイルなのか、他にはない優れたソリューションを開発しているか、キャンバス/コンポーネントデータ/ワークフローが持つ抽象的な特性に苦労しているのではないか。答えがどうであれ、重要なのは、設計の意図に沿ってツールを使用することです。これこそが、このブログでジョブ設計のパターンとそのベストプラクティスを解説している理由です。Talendの機能をすべて理解しただけでは十分ではなく、ジョブを作成する最適な方法を理解する必要がある、と私は考えています。 論理的には、「ビジネスユースケース」はあらゆるTalendジョブの基本的な推進要素です。実際には、同じワークフローでもさまざまなバリエーションがありますし、ワークフローにもさまざまなタイプが存在します。このような「ユースケース」のほとんどは、「データソースからデータを抽出して処理し、そのデータを変換した後、最終的には別のターゲットにロードする」という最もシンプルな形式で行われるデータ統合ジョブ、という大前提からスタートします。この点で、ETL/ELTコードは私たちの作業の活力源であると言えます。これは、Talendで日々コーディングに取り組んでいる開発者の皆さんがよくご存じなので、ここでは扱いません。第2部では、皆さんの視野を広げる内容をご紹介したいと思います。 Talendの最新リリース（v6.1.1）は、これまでで最高のバージョンだと思います。ビッグデータ、Spark、機械学習、UIのモダナイゼーション、継続的な統合と展開の自動化（他にも多彩な機能が実装されています）において、コンポーネントが新たに加わりました。今日販売されているデータ統合テクノロジーの中で最も優れた堅牢性と機能性を誇るバージョンです。少々手前味噌かもしれませんが、ユーザーの皆さんも私と同じ評価をしてくださると思います。ぜひ、ご自分で実感してみてください。 DIプロジェクトを成功へと導く3つの基本的指針 では、始めましょう。椅子が立つには、脚が少なくとも3本は必要です。これは、ソフトウェア開発にも当てはまります。データ統合プロジェクトの作成とデリバリーを成功させるには、3つの基本的な要素が存在します。 ユースケース – 明確に定義されたビジネスデータ/ワークフロー要件 テクノロジー – ソリューションを構築、展開、実行するツール 手法 – 一般的に合意された実行方法 上記を念頭に、明確に定義された「開発ガイドライン」ドキュメント（このシリーズの第1部を読んでいただけたでしょうか？ プロジェクト用のドキュメントは作成されていますか？）に沿って、前提となる条件を構築していきましょう。 基本的指針の拡張 Talendの「ジョブ」が「ユースケース」ワークフロー内のテクノロジーであれば、ジョブ設計パターンはそれを構築するベストプラクティスの「手法」です。このブログの内容で最も重要なことは、一貫した方法でジョブを作成する、という点です。もしもより良い方法が見つかり、それがうまく機能しているのであれば、そのまま進んでください。ただし、パフォーマンス、再利用性、保守性の向上に苦戦している方や、変化を続ける要件に合わせてコードのリファクタリングを続けている方には、これらのベストプラクティスが役立ちます。 さらに検討すべき9つのベストプラクティス： ソフトウェア開発ライフサイクル（SDLC） 億万長者のMarcus Leminos氏が提供する番組、「The Profit」（CNBC）によれば、「人、製品、プロセス」は、あらゆるビジネスの成否を分ける3大要素です。これには、私も同意します。SDLCプロセスは、ソフトウェア開発チームの要です。このプロセスを適切に行うことが非常に重要であり、それを無視すれば、プロジェクトに深刻な影響を及ぼし、プロジェクトは失敗に陥ってしまいます。TalendのSDLCベストプラクティスガイドには、Talendが開発者に提供する継続的統合と展開に関する概念、原則、仕様、詳細な説明が記載されています。前のブログ記事でご紹介した「開発ガイドライン」ドキュメントにSDLCベストプラクティスを反映することを、すべてのソフトウェア開発チームにお勧めします。 ワークスペースの管理 Talend StudioをノートPC/ワークステーションにインストールすると（管理者権限があるものとします）、デフォルトの[Workspace]ディレクトリがローカルディスクドライブ上に作成されます。多くのソフトウェアインストールと同様に、このデフォルトディレクトリは、実行可能ファイルと同じディレクトリ内に作成されます。私は、これは良いプラクティスだとは思いません。なぜでしょうか。 プロジェクトファイル（ジョブ、リポジトリメタデータ）のローカルコピーは、この[Workspace]に格納されます。これを、ソースコード管理システム（SVN、GIT）にTalend Administration Center（TAC）を介してアタッチすると、プロジェクトをオープンまたは保存するたびに同期が行われます。このようなファイルは、簡単に識別および管理できる場所に格納すべきです。ディスク（または別のローカルドライブ）上に格納するのがよいでしょう。 ワークスペースは、Talend Studioで接続を作成する際に使用されます。接続は、「ローカル」と「リモート」のいずれかです。この2つの相違点は、「ローカル」接続がTACで管理されないのに対して、「リモート」接続はTACで管理される、という点です。一般的に、サブスクリプションユーザーは「リモート」接続のみを使用します。 チーム全員が使用する「開発ガイドライン」ドキュメントでディレクトリ構造を明確に定義することで、最適なコラボレーションを実現できます。ここで重要なのは、チームの同意を得て、規範を徹底し、一貫性を維持することです。 参照プロジェクト 皆さんは、参照プロジェクトを使用していますか。参照プロジェクトをご存知でしょうか。参照プロジェクトは、シンプルであるにもかかわらず生産性を高める機能なのですが、使用していないユーザーが数多く存在します。再利用可能な汎用コードを作成し、複数のプロジェクトで共有することは、開発者共通のニーズです。開発者は、プロジェクトを開始する際、コードの一部をコピーし、別の（または同じ）プロジェクトやジョブに貼り付ける、という作業をよく行います。または、あるプロジェクトのオブジェクトをエクスポートし、別のプロジェクトにインポートすることもあるでしょう。かつては、私もこの方法を使用していました。このような方法に問題はないのですが、お勧めはしません。このプロセスには、保守において深刻な問題が発生する危険が潜んでいます。そこでお勧めなのが、参照プロジェクトです。私は、参照プロジェクトを見つけたとき、とても嬉しかったことを憶えています。 TACを使用してプロジェクトを作成している方は、ひっそりと存在する[Reference]チェックボックスに気付き、「これは何だろう？」を思ったことがあるのではないでしょうか。プロジェクトを作成し、このチェックボックスを選択して「参照プロジェクト」を作成すると、他のプロジェクトを「含める」設定や「リンク」することが可能になります。「参照プロジェクト」で作成したコードは、リンクしたプロジェクト内で使用できるようになるため（読み取り専用）、再利用可能性が非常に高まります。このプロジェクトには、共通のオブジェクトやコードをすべて格納すべきです。 ただし、「参照プロジェクト」は最小限に留める必要があります。ベストプラクティスでは、参照プロジェクトの数は1つに限定してください。場合によっては、2つまたは3つでも問題ありません。注意：「参照プロジェクト」の数が多すぎると、その効果が損なわれてします。参照プロジェクトでは、慎重な管理が非常に重要になります。その用途とルールを「開発ガイドライン」ドキュメントに明記し、チーム全体が順守することにより、最適なコラボレーションを実現できます。 オブジェクトの命名規則 …
続きを読む
Talend開発者が、経験が浅かろうが豊富であろうが共通して直面することが多いのが、「このジョブを記述する最善の方法は何か」という疑問です。 効率的で、読みやすく、記述しやすく、何よりも（ほとんどの場合）維持しやすいものであるべきなのは当然です。 また、Talend Studioという自由形式の「キャンバス」では、コンポーネント、リポジトリーオブジェクト、メタデータ、及びリンケージオプションの包括的で多彩なパレットを使用してコードを「描画」できることもわかります。 では、ベストプラクティスを使用してジョブ設計を作成したことを、どのように確認したらよいのでしょうか。 ジョブ設計パターン Talendを使い始めたバージョン3.4以降、ジョブ設計は私にとって非常に重要でした。 最初は、ジョブの開発でパターンを考慮することはありませんでした。それ以前からMicrosoft SSIS等のツールを使用していたので、Talendのようなビジュアルエディターには馴染んでいました。 パターンに焦点を当てる代わりに、基本的な機能、コードの再利用性、次にキャンバスのレイアウト、そして最後に命名規則に注目していました。 しかし、さまざまなユースケース向けに数百のTalendジョブを開発し、コードがより洗練されて再利用性や一貫性も向上したことから、一定のパターンが浮かび上がってきました。 今年1月にTalendに入社して以来、顧客が開発したジョブを目にする機会に多く恵まれました。その結果、全ての開発者にとって、それぞれのユースケースに複数のソリューションがあるという認識に確信を持ちました。 このことが、開発者の多くにとっての問題となっているようです。 私たち開発者は同じような考え方をしますが、自分のやり方が特定のジョブを開発するうえで最善であると思い込みがちです。一方で、さらに良い方法が存在する可能性に薄々気が付いてもいます。 そこで、ベストプラクティスが必要となり、この場合はジョブ設計パターンを探すことになります。 基本的指針の明確化 可能な限り最善のジョブコードを実現するために必要なことを考えるときには、常に基本的指針が適用されます。この指針は、長年にわたるミスと成功に基づく改善の積み重ねから生まれたものです。 これはコード構築の強固な基盤となり、（私見ですが）ないがしろにしてはならない重要な原則であり、次の事柄が含まれます（順序は問いません）。 – 読み取りやすさ：簡単に把握し、理解できるコードを作成する – 記述しやすさ：最短期間に平易で単純なコードを作成する – 維持性：変更の影響を最小限に抑えて適度な複雑さを組み込む – 機能：要件を満たすコードを作成する – 再利用性：共有可能なオブジェクトと小さな作業単位を作成する – 整合性：チーム、プロジェクト、リポジトリー、コードにわたる実質的な規範を作成する – 柔軟性：曲げることはできても折れることのないコードを作成する – 拡張性：要求に応じてスループットを調整する弾力のあるモジュールを作成する – 一貫性：全てにわたる共通性を作り出す – 効率：最適化されたデータフローとコンポーネント利用を作り出す – 区画化：単一の目的に対応する、焦点を絞った小さなモジュールを作成する – 最適化：最小限のコードで最大限の機能を作り出す – パフォーマンス：最速のスループットを生む効果的なモジュールを作成する これらの指針全体で実質的なバランスをとることが重要です。特に最初の3項目は常に相反するため、調整が欠かせません。 2つの項目を満たして3つ目を犠牲してしまうことはよくあります。 できるだけ重要度に基づいて順序付けるようにします。 （基準ではなく）規範としてのガイドライン 実際にジョブ設計パターンの検討に入る前に、前述した基本的指針と併せて、考慮すべきいくつかの詳細事項について確認しておきましょう。 設定されている基準に想定外の状況に対処する余地がなく、融通が利かないために、支障が出ることがしばしばあります。 …
続きを読む
In my last blog “What is ‘The Data Vault’ and why do we need it?” I introduced a fresh, compelling methodology for data warehouse modeling authored and invented by Dan Linstedt (http://danlinstedt.com) called ‘the Data Vault’. Solving the many characteristic and inherent problems found in crafting …
続きを読む
