注目の投稿

データの健全性、予後から治療まで

詳細情報
注目の投稿

正しいデータについての問題をついに解決できます。

詳細情報
注目の投稿

15歳になったTalendは、データに関わる作業を自動化し続けます

詳細情報
注目の投稿

自社のデータの健全性を信頼していますか?

詳細情報
注目の投稿

Talend、Q2 2020 Forrester WaveTMのEnterprise Data Fabricリーダーの一社に選ばれる

詳細情報

Microsoft AzureとTalendによって完全なエンドツーエンドのCI/CDパイプラインを自動化する

| 2019年10月14日 | Azure Cloud Integration

Talendは、CI/CDの実装を進化させ、簡素化し続けています。このブログでは、Talend Cloud on Microsoft Azureを利用することで、どのように継続的統合(CI)およびデリバリーのパイプラインの完全な自動化、ゼロインストール、およびエンドツーエンドデリバリーを実現して、すべてのDevOpsの目標を達成できるか説明します。 これまでの経緯 Microsoft AzureでのエンドツーエンドのCI/CDパイプラインの構築について詳しく説明する前に、当社のCI/CDの歴史について説明します。Talendは、2016年夏に最初の継続的インテグレーション機能を展開しました。このとき、統合プロジェクトのデリバリーまでの時間を短縮する進化が始まったのでした。データインテグレーターは、単体テスト機能とMaven互換性標準をTalend Studioに組み合わせることで、Jenkinsなどの使い慣れたCIオーケストレーションツールを利用して、自動的なビルド、単体テスト、および成果物リポジトリへのTalendジョブのパッケージングを行えるようになりました。これは大きな第一歩ですが、継続的デリバリーの要素をすべて満足させるものではありませんでした。さらに、Jenkins内で大幅な構成が必要であるとともに、追加のソフトウェアを手動でインストールする必要がありました。 現在では、データ駆動型企業は、より多くのデータに関する知見を絶えず得ようとし、短時間での信頼性の高いデータプロセスを開発チームに求めています。このような需要の増大に対応するため、IT組織は、ダウンタイムゼロの完全なエンドツーエンドCI/CDパイプラインを含むDevOps手法を活用しています。   進化した点 TalendをCI/CDプロセスに統合することは、決して目新しいことではありません。実際、私は今年のこれまでに、Microsoft Azure DevOpsとTalendを活用してCI/CDパイプラインを構築した例について記事を書いています。ただし、Talend CI Builderサービスをホストするために、Azureプラットフォームでホステッドエージェントを構築して構成するには大変な労力が必要でした(「記事」を参照)。ほんの数か月後、TalendはゼロインストールCI機能を提供しました。この機能によって、その労力は不要になり、これまでにないほど容易にクラウドで継続的インテグレーション(CI)を実現できるようになりました。現在、Talend Cloud on Microsoft Azureの最新の機能によって、TalendのゼロインストールCI機能を利用したAzure DevOps Orchestrationエンジンと新しいネイティブクラウドサービスという2つのそれぞれの長所を組み合わせて、完全に自動化された方法で、継続的インテグレーション(CI)、継続的デプロイ、および継続的デリバリーという最終的な目標を達成できます。   技術的詳細 具体的な例について見ていきましょう。Microsoftホステッドエージェントを使用するために、ゼロインストールCI機能を活用して、AzureパイプラインにCIパイプラインを作成します。以下のステップは、エージェントの設定以外は以前の記事「TalendとAzure DevOpsを使用したCI/CDパイプラインの構築」で説明したステップと基本的に同じです。この記事では、エージェントを設定する必要はありません。Azure DevOpsプラットフォームによって提供されるエージェントを使用します。目標は、CIパイプラインを利用して、ジョブをTalend Cloudにパブリッシュすることです。 以前の記事で詳しく説明しているため、ここでは最初のステップについて詳しく扱いません。ここでは、ゼロインストールCIの使用に関する詳細についてのみ説明します。   ファイルはGitHubのこちらにあります。 1.前提条件 主に次の2つの前提条件があります。 Talend StudioおよびNexusからのサードパーティライブラリを同期してCIが機能するように、Nexusを設定する必要があります。詳細については、このページでブログの「Configure the Nexus for third-party libraries(サードパーティライブラリ向けのNexusの設定)」を参照してください。 第2の要件は、P2リポジトリと呼ばれるものをホストする必要があることです。その内容とその目的についてはこの記事で既に説明しました。ライセンス電子メールまたはTalend CloudからこのP2リポジトリをダウンロードしたら、たとえば、通常のHTTPサーバーやAzure Blob Storageでホストする必要があります。 Azure Blob …

続きを読む

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

| 2019年5月20日 | Database Integration Developer Step-by-Step ETL / ELT ビッグデータ統合

  データモデルとは何を指すのでしょうか。毎日データモデルに接して熟知している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つの親要素のサブクラスに似ており、親のすべての特性に加えて、関連する一意の特性をすべて追加的に含みます。サブクラス要素は、その名前と表現の両方で洗練化されることで、抽象化された全体論的データサイロの理解しやすい洗練化を提供します。要素オブジェクトに結合する一般化は、親オブジェクトに閉じた矢印が付いた青色の実線のリンクで示され、ラベルは不要です。 …

続きを読む

『データプレパレーションに関するガートナーマーケットガイド2019』の3つの重要点

Jean-Michel Franco          2019年4月26日 ガートナーは、データプレパレーションに関するマーケットガイド2019([1])(2019 Market Guide for Data Preparation)を公表しました。マーケット黎明期の2015年、データプレパレーションが主にセルフサービスのユースケースを支援することを想定していた時代に初めて作られたガイドで、今回が第4版となります。 マジック・クアドラントと比較すると、この マーケットガイドシリーズは主に初期、成熟、または小規模なマーケットを取り上げており、ベンダー間の競争の位置づけに関する情報は少ないですが、マーケットの状況や長期的に見た市場の発展についての情報は充実しています。このような資料では、多くの人がまずベンダーのプロフィールをチェックされるかと思います(Talend Data Preparation も詳細なプロフィールと一緒に紹介されています)。このレポートが提供するリーダーシップについての思考と市場分析にもぜひ注目していただけると幸いです。 組織内でのデータプレパレーションの価値と拡張を成功させる方法について、著者のEhtisham ZaidiとSharat Menonのコメントも参考にしてください。 このレポートを調べた後に、私はデータプレパレーションという刺激的なマーケットでのお客様のニーズに対応する3つの重要な点をお伝えしたいと考えました。   データプレパレーションは、データ管理をチームスポーツへ データプレパレーションの市場が誕生したきっかけは、セルフサービス機能がトレンドになったことでした。これは、TableauやPower BIといった最新のデータディスカバリーツールを使用して権限が与えられていても、ビジネスユーザーが知見を得る前に新しいデータソースを効率よく見つける方法がなかったことから発生しました。ビジネスユーザーはIT部門に頼るか、ガバナンスの十分ではない方法でMicrosoft Excelなどのツールを使用してデータをサイロ化するしかありませんでした。データプレパレーションツールはこうした生産性の面での課題に対応するものでした。 レポートによると、データ専門家やビジネスアナリストは、データから実際に知見を引き出せるようにするために、データの検索や保護の準備に業務時間の80%を費やしています。データプレパレーションは、より多くの関係者がデータ統合やデータ品質管理を利用できるようにすることによって、このような状況を改善するために登場したのです。これは21世紀初頭では大きな課題でしたが、それ以降、データ関連業務はより規模の大きなゲームになっていきました。個人の生産性の問題ではなくなり、データ駆動型の知見の活用に向けた企業文化の育成も重要になってきています。 ガートナーのマーケットガイドは、このような動向に焦点をあて強調したことにあります。手法やツールが完成しつつある現在、データプレパレーションを社内とIT部門の誰もが連携してデータを活用できるチームスポーツにすることが主な課題になっています。結果として、もっとも重要なことは運用です。 ビジネスユーザー、ビジネスアナリスト、データサイエンティストやデータエンジニアが別々にその場しのぎで行っていることを集約し、生産時に十分にガバナンスされた方法で繰り返し実行できる、社内全体で活用できる資産にする必要があります。 最終的にこのアプローチは、データ統合、データ分析やビジネスインテリジェンス、データサイエンス、データウェアハウス構築、データ品質管理といった会社全体での取り組みに役立ちます。   スマートな人にはスマートなツールを…逆もまたしかり ガートナーのマーケットレポートでは、データカタロギング、パターン認識、スキーマオンリード、機械学習といった最新鋭のテクノロジーがツールに組み込まれていることも強調しています。 これによってスキルの低いユーザーでもデータを使って複雑な活動ができるようになり、一方でデータ変換、統合、照合や復旧は、それらが繰り返し作業になった時点で自動化できるようになりました。 さらに興味深いのは、ガートナーがこうしたテクノロジーのイノベーションを市場の収束に結び付けているということです。レポートでは次のような予測が書かれています。 「2024年までには、機械学習によって強化されたデータプレパレーション、データカタログ、データ統一化およびデータ品質管理ツールは、統合された最新のエンタープライズ情報管理プラットフォームにまとめられるだろう」。 実際、データプレパレーションを特定のビジネスユーザーを対象にした単独の規律であると考えるのは思い違いといえるでしょう。むしろ、潜在的にはあらゆる人が作業に関与できるようにする機能が整っていることから、情報管理における革新的テクノロジーとみなすべきです。革新的なテクノロジーを活用し、企業は新しい共同作業を通じてデータバリューチェーンを組織することができます。 Talendでは「コラボレーション型データ管理」と呼び、このマーケットガイドでのガートナーを含む一部のアナリストはDataOpsとして言及している手法です。 データ品質管理を例にとってみましょう。 多くの企業では、データ品質の対応に苦労しています。中央IT部門やCDOオフィスといった中央組織の少人数しかいないデータ品質管理の専門家に頼りすぎるアプローチをとっているためです。こうした専門家は、データ品質プロファイリングの調整や復旧では重要な役割を果たしますが、社内で最もデータを熟知しているというわけではありません。データの取得源に近いところで働いている同僚に、データクリーニング作業の一部を依頼する必要があります。こうした人々が手軽なデータプレパレーションツールを使えると、データ品質管理の効率は非常に高くなります。   ハイブリッドクラウドの価値 ガートナーはまた、革新的なPaaS(Platform as a Service)デプロイメントモデルを通じて提供されるデータプレパレーションに対する顧客の需要の高まりを把握しています。ガートナーが強調するのは、基本的なSaaSを超えるはるかに洗練されたデプロイメントモデルが必要であるということです。 レポートでは「企業が必要としているのは、事前にデータを移動させなくても、もっとも意義のある場所でデータプレパレーションを行うことができるような柔軟性が必要である」と説明しています。 …

続きを読む

TalendでCI/CDとコンテナー型仮想化を使用してサーバーレスアーキテクチャに移行する

| 2018年8月13日 | Cloud Integration Containers

CI/CDとコンテナーの重要性 CI/CD(継続的インテグレーション・デリバリー・デプロイ)は、ソフトウェアプロジェクトを成功させるための重要な要素であり、プロジェクトを進めるうえで明らかにメリットがあります。既に、コンテナーは現在あらゆる場所で使用され、開発者から絶大な人気を博しています。CI/CDを使用するユーザーは、構築しているアプリケーションを自動的かつ継続的にテスト/検証できるので、アプリケーションの品質を確かなものにします。一方で、コンテナーは、企業が採用する標準的な手順に基づき、一度構築すれば「どこにでも」デプロイできるので、ソフトウェアの配布と実行をより俊敏に行えます。このような一般的なDevOpsプラクティスにより、「特定のマシンしか動作しない」という状況は、回避されます。結果として、サービスを市場投入するまでの時間が短縮されるとともに、デリバリーの頻度を高めることができます。 Talendのシステム環境へどのように適応できるか? Talendでは、CI/CDとコンテナーの両方のメリットを利用できます。Talend 7.0のリリース以降では、標準的なMavenビルドにより、Dockerイメージ内でTalendジョブをビルドできるようになりました。そして、このプロセスをCI/CDのパイプラインにスムーズに接続できます。 サーバーレスアーキテクチャとは? 最後の段階で活用されるのはサーバーレスアーキテクチャです。Talendでは、サーバーレスでジョブがデプロイされます。実際に、ジョブをコンテナー内で送ることによって、統合ジョブを任意の場所に自由にデプロイできるようになりました。様々な選択において、サーバーレスとして定義される新しいサービスのカテゴリーが登場しています。AWS FargateやAzure Container Instancesなど、ほとんどの大手クラウドプロバイダーはコンテナー用のサーバーレスサービスの提供を開始しています。これらのサービスを利用すると、コンテナーを実行する際にインフラストラクチャ(サーバーやクラスター)を管理する必要がなくなります。発生するコストはコンテナーの使用料だけです。 これらの新しい機能は、Talend Connect US 2018の基調講演で紹介され、AWS FargateやAzure ACIでジョブのビルドから実行までのパイプライン全体のデモンストレーションを使用して解説されました。このブログでは、Jenkinsを利用してCI/CDパイプラインを作成する方法について説明します。最初にDockerイメージ内でジョブをビルドし、Dockerレジストリでイメージを利用できるようにします。そしてAWS FargateやAzure ACIを呼び出してイメージを実行します。 このプロセスを再現する方法を見ていきましょう。 まず、次の要件を満たしていることを確認して下さい。 Talend Studio 7.0 以降 Talend Cloud Spring 18’ 以降 Jenkinsサーバーを利用できること Jenkinsサーバーが、同じマシンにインストールされたDockerデーモンにアクセスできること Talend CommandLineがJenkinsのマシンにインストールされていること Nexus version 2 または 3 Talend CI BuilderがTalend CommandLineと共に構成されていること * 上記のTalendコンポーネントは全て、Talend Cloudの30日間の試用版で利用できます。 Talend環境 Talendを初めて使用する方向けに、各コンポーネントの概要について説明します。Talend Cloudから使用を開始し、Talend …

続きを読む

データレイク構築で陥りやすい3つの落とし穴とその回避方法

| 2018年8月8日 | Big Data/Data Lake

最近、北米大手銀行のIT部門のSVP(シニアバイスプレジデント)とデジタルトランスフォーメーション戦略について話す機会がありました。その中で、ビッグデータやデジタルトランスフォーメーションに対するアプローチが絶え間なく進化しているという話が印象的でした。市場に新しく登場してきたテクノロジーの機能をビジネスに生かすには、新たな軸足やアプローチが必要です。データとアナリティクスの成長を維持/拡張できる俊敏性の高いアーキテクチャーを使用することが、これまで以上に重要になっています。ここでは、データレイクの構築で陥りやすい3つの落とし穴と、その回避方法について説明したいと思います。 「取り込みツールさえあればよい」 データレイクを構築すれば、あらゆる課題を解決できると思われがちです。確かに、データの格納場所ができることは成果と言えます。多くの場合、最初に課題となるのがデータの取り込みです。データレイクに流れ込む種類も量も莫大なデータの収集/取り込みに対処する必要があり、データさえ収集できれば簡単に目標を達成できると考え、データ取り込みソリューションを購入します。データのキャプチャーと収集は可能になりますが、これで問題が解決したのではありません。一時的には問題ないかもしれませんが、真の取り組みはこれからです。 データをデータレイクに格納することが始まりでしかないことは、すぐに明らかになります。多くのプロジェクトは、「データスワンプ(沼)」の問題により失敗します。これは、データレイクが構造を持たず、品質が低いうえに、人材も不足し、実際にデータがどこから来たのかトレースすることもできない状況を指します。生データは、そのままでは有用性が低く、データから質の高いアナリティクスを行うには、まずデータを処理し、クレンジングし、変換する必要があります。これが、2つ目の落とし穴につながります。 データレイクのハンドコーディング We have had many blogs in the past on this, but you can’t emphasize this topic enough. It’s strikingly true that hand coding may look promising from the initial deployment costs, but the maintenance costs can increase by upwards of 200%. The …

続きを読む

Apache Beamを使用したデータ処理ジョブの開発 – ストリーミングパイプライン

| 2018年8月7日 | Open Source Streaming Data

前回のブログでは、Apache Beamを使ったデータ処理ジョブの開発について紹介しました。今回は、現代のビッグデータ処理で非常にニーズの大きなストリーミングデータの処理について説明します。 バッチとストリーミングの主な違いは、入力データソースのタイプです。データセットが限られていて(サイズが巨大でも)、処理中に更新されない場合は、バッチパイプラインを使用する可能性が高くなります。この場合、入力ソースはファイル、データベーステーブル、オブジェクトストレージ内のオブジェクトなど、何でもかまいません。もう一度強調しますが、バッチ処理では、処理の期間全体でデータが変更可能であり、入力レコードの数は一定です。この点に注意しなければならないのは、ファイルについても、常にファイルの追加や変更が行われるとデータストリームが無限になる可能性があるためです。その場合は、データを処理するためにストリーミングアプローチを適用する必要があります。したがって、データが限られていて不変であることがわかっている場合は、バッチ処理パイプラインを開発する必要があります。 データセットが無制限(継続的に到着)/可変の場合は、処理がより複雑になります。ソースの例としては、メッセージシステム(Apache Kafkaなど)、ディレクトリー内の新しいファイル(Webサーバーログなど)、その他のリアルタイムデータを収集するシステム(IoTセンサーなど)といったものがあります。これらすべての情報源に共通しているのは、常に新しいデータを待たなければならないという点です。もちろん、データを(時間ごとまたはデータサイズごとに)バッチに分割し、分割ごとにバッチ処理することも可能です。しかし、一部の関数については、すべての消費データセットに適用し、そのためのパイプラインを丸ごと作るのが困難です。幸いなことに、この種のデータ処理に簡単に対処できるストリーミングエンジンとして、Apache Spark、Apache Flink、Apache Apex、Google DataFlowを使用できます。これらはすべてApache Beamによってサポートされ、コードを変更することなく、異なるエンジンで同じパイプラインを実行できます。さらに、最小限の変更でバッチ処理でもストリーミングモードでも同じパイプラインを使用できます。入力パイプラインを正しく設定するだけで、即座に使用できます。バッチジョブをストリーミングジョブに書き換えていた頃から、このような機能があれば素晴らしいだろうと考えていました。 理屈はさておき、例を使用して最初のストリーミングコードを記述していきましょう。Kafka(無制限のソース)からデータを読み込み、簡単なデータ処理を実行し、結果をKafkaにも書き戻します。 リアルタイムで到着する地図上のいくつかのオブジェクトの地理座標(XとY)の無限の流れ(この例では、オブジェクトは車だとしましょう)があり、特定地域にあるものだけを選択したい場合を考えます。つまり、我々はKafkaトピックからテキストデータを消費し、それを解析し、指定された制限でフィルタリングし、別のKafkaトピックに書き戻す必要があります。Apache Beamを利用してこれを実現する方法を見ていきましょう。 それぞれのKafkaメッセージには、次の形式のテキストデータが含まれています。 id,x,y このとき: id – オブジェクトの一意のID x, y – 上の座標(整数) 形式に注意し、有効でない場合はスキップします。 パイプラインの作成 前回のブログでのバッチ処理と同じ方法でパイプラインを作成します。 Pipeline pipeline = Pipeline.create(options); Optionsオブジェクトを詳細に指定することで、コマンドラインオプションをパイプラインに渡すことができます。詳しくはGithubを参照してください。 次に、Kafkaの入力トピックからデータを読み込みます。すでに述べたように、Apache BeamはさまざまなIOコネクターを提供しています。KafkaIOもその1つです。したがって、指定されたKafkaトピックからの着信メッセージを消費し、それらをさらに次のステップに伝播する新しい無制限のPTransformを作成します。 pipeline.apply( KafkaIO.<Long, String>read() .withBootstrapServers(options.getBootstrap()) .withTopic(options.getInputTopic()) .withKeyDeserializer(LongDeserializer.class) .withValueDeserializer(StringDeserializer.class)) デフォルトでは、KafkaIOは消費されるすべてのメッセージをKafkaRecordオブジェクトにカプセル化します。ただし、次の変換は新しく作成されるDoFnオブジェクトによってペイロード(文字列値)を取得するだけです。 .apply( ParDo.of( new DoFn<KafkaRecord<Long, String>, String>() …

続きを読む

効果的なTalendジョブ設計レビューの実施 – 入門編

どこの開発チームでも、一般的なプラクティスとしてコードレビューが実施されています(少なくとも、そうあるべきです)。コードレビューは、複数の開発者が記述されたコードを調べ、品質と正確さを向上させるために、その設計、実装、構造について議論するプロセスです。正式な手法、あるいは、より簡易な手法(ペアプログラミングなど)のどちらを実施するにせよ、実稼働前に欠陥や不足を見つけるために、コードレビューは効果的であることが証明されています。 さらに、コードレビューを実施することで、チーム内で確立されたベストプラクティスに沿って全員が作業を進めることができます。このチーム内でのコラボレーションにより、途中で新しいベストプラクティスを特定することも容易になります。それだけでなく、定期的にコードレビューを行うことで一定レベルの情報共有が実現され、すべての開発者がお互いから学ぶ機会が得られます。これは、経験の浅い開発者にとって特に有効ですが、上級の開発者もこのプロセスから学ぶことがあります Talendはコードジェネレーターなので、開発者が実際にコードを記述することはありませんが、その裏で、ジョブの開発中には行単位のコーディングで多くの要素を共通しています。すなわち、Talendは非常に柔軟なプラットフォームであり、開発者は様々な方法でジョブを構築できるのです。ジョブの設計、設定、オーケストレーションのフローをレビューするだけであっても、コードレビューを実施することのメリットを100%得ることができます。 Talendジョブレビューの「意義」 Talendジョブレビューの目的を一語で表すとすれば、「品質」でしょう。戦略的には、長期的にはジョブレビューによって当然のことながら開発者のスキルが向上し、ベストプラクティスが洗練されます。つまり、将来のジョブについては、ジョブレビュー前の段階からパフォーマンスが改善され、欠陥が減少し、そして保守が容易になるのです。 Talendジョブ設計レビューのメリットについて、上記の説明だけでは確信を持てない方もいるでしょう。開発者はそれなりのプライドをもってジョブを構築しているので、反応にばらつきがあるのも当然です。しかし、レビューのメリットに注目し、お互いから学び、全員のスキルを向上させる場として前向きに捉えることが重要です。レビューに参加している間は、関与する開発者に対して常に思いやりと敬意を持つべきです。チームによっては、正式なチーム全体のレビューよりもペアで行うレビューの方が効果的な場合もあります。ペアで実施する場合でも、オフラインではなく直接顔を合わせてのレビューの実施を推奨します。そのほうが、レビューのコラボレーションから得られるものが多いのです。実利をとることが重要です。コードレビュープロセスを改善する方法を提案するようにチームに求めましょう 定性的側面と定量的側面 Talendジョブをレビューするときには、質と量の両方から考えることが重要です。 質の面では、ベストプラクティスの適用と、それを採用することが必要です。Talendの推奨するベストプラクティスをまだ読まれていない場合は、ぜひ目を通してください。現在、4回シリーズのブログ記事で紹介しています。 Talendの「ジョブ設計パターン」とベストプラクティス - 第1回 Job Design Patterns & Best Practices PART 2(英語) Job Design Patterns & Best Practices PART 3(英語) Job Design Patterns & Best Practices PART 4(英語) ベストプラクティスに関するこれらの記事では、効果的なジョブ設計の定性的側面について説明しています。読みやすく、書きやすく、保守しやすいジョブを設計する方法について、推奨事項を紹介しています。さらに、より良いジョブを構築するために事前に知っておくべき、以下のような基本事項についても述べています。 機能 再利用可能性 拡張性 一貫性 パフォーマンス その他 これらの基本事項をうまく選択してバランスを取ることが成功の秘訣です。 成功するジョブ設計パターンの方法論と実践に関する後続シリーズ(現在のところ2回分)も参考にしてください。 Successful Methodologies …

続きを読む

Apache SparkとTalend:パフォーマンスと調整

| 2018年4月12日 | ビッグデータ統合

このブログシリーズでは、すでに2つの記事でTalendとApache Sparkに関して説明してきました。 このブログシリーズのこれまでの記事をまだ読んでいない場合は、最初に第1部「TalendとApache Spark:技術的な手引きと概要」と第2部「Talend Sparkジョブ vs. spark-submitの構成:2つの違いとは?」をお読みください。 Apache Sparkに関するシリーズの最初の2回は、Talendとspark-submitの類似点、およびTalendのSparkジョブで使用可能な構成オプションの概要について説明しました。 このブログでは、Apache Sparkのパフォーマンスと調整について説明します。これは、Talendユーザーに限らず、Apache Sparkを使用しているほとんどのユーザーに共通の議論です。最初のSparkジョブを開発して実行するときには、常に次のような疑問が浮かびます。 Sparkジョブにはいくつのエクゼキューターを割り当てる必要があるのか? 各エグゼキューターに必要なメモリー量は? コアをいくつ使用する必要があるのか? 一部のSparkジョブは10GB程度のデータを処理するのに何時間もかかるが、この問題をどうやって解決できるか? このブログでは、これらの質問を取り上げ、答えと洞察を提供します。その前に、このブログで使用されるいくつかの重要な概念を紹介します。 パーティション:パーティションは分散データセットの一部です。デフォルトのHDFSブロックサイズで作成されます。Sparkはパーティションを利用してデータセットを並列処理します。 タスク:タスクは、エクゼキューター内で実行できる作業単位です。 コア:コアは、エクゼキューター内で実行できるSpark内の並列タスクの数を決定する、CPU内の処理単位です。 Sparkエグゼキューター:ワーカーノード上で開始され、メモリーまたはディスク内でジョブのサブミットを実行するプロセスです。 アプリケーションマスター:各YARNアプリケーションは、リソースマネージャーからリソースを要求する責任を持つアプリケーションマスタープロセスをスピンアップします。リソースが割り当てられると、プロセスはノードマネージャーと連携して、ノードマネージャー内で必要なコンテナーを起動します。 Sparkの調整 最初に、Talend内のApache Sparkジョブを調整する方法を検討しましょう。前述のように、Talend Sparkジョブには、[Spark Configuration]タブがあり、ここで調整プロパティを設定できます。Talendでは、これはデフォルトでは常にオフになっています。 このセクションには、アプリケーションのマスターとエグゼキューターが使用するメモリーとコア、およびジョブが要求するエグゼキューターの数を設定するオプションがあります。このセクションで値を指定する際の主な疑問は、「アプリケーションマスターやエグゼキューターがパフォーマンスを向上させるために必要なコア数またはメモリー数をどのように決定するのか」ということです。 Sparkジョブのコア数を選択する方法 この時点では、先に進む前に考慮しなければならない要素がいくつかあります。 データセットのサイズ ジョブが完了する必要がある時間枠 ジョブが実行している処理とアクション これらの要素を念頭に置いて、パフォーマンスを最大化するようにジョブを構成し始めることができます。まずアプリケーションマスターの調整から始めましょう。アプリケーションマスターの場合、リソースのオーケストレーションを行うだけで、処理は行わないため、デフォルト値をそのまま使用できます。つまり、メモリーやコアの値を大きくする必要はありません。 次のステップは、エクゼキューター用にメモリーとコアを構成することです。ここでの主な問題は、エクゼキューター、メモリー、コアをいくつ使うべきかということです。その答えを見つけるために、それぞれに32コアと120GBのメモリーを使用する6つのワーカーノードを持つHadoopクラスターがあるとします。おそらく頭に浮かぶ最初の考えは、エグゼキューターごとに持つことができる同時タスクが多いほど、パフォーマンスが向上するということです。これについて調べると、Hadoopディストリビューションのパフォーマンスチューニングガイド(Clouderaの例はこちら)では、1エクゼキューターあたり5コアを超えるとHDFS I/Oが低下することがわかります。したがって、高いパフォーマンスのためのコアの最適値は5です。 次に、いくつのエグゼキューターを起動したいのかを見てみましょう。コアとノードの数に基づいて、この数を簡単に判断できます。前述したように、5コアがエグゼキューターごとに使用するのに最適な数です。さて、ノードあたりの32個のコアのそれぞれから、ノードで実行されているオペレーティングシステムとHadoopデーモンで必要とされているために、ジョブに使用できないものを削除する必要があります。Hadoopクラスター管理ツールはすでにこれを行っているので、ノードあたりのSparkジョブに使用できるコアの数を簡単に判断できます。 この計算を行った後、使用可能なノードあたり30コアが残っているとしましょう。5コアがエグゼキューターあたりの最適な数であるとすでに決定したので、ノードあたり最大6つのエグゼキューターを実行できることを意味します。簡単に特定できましたね! 最後に、使用可能なメモリー量を計算します。上記のハードウェア仕様に基づいて、ノードごとに120GBのメモリーがあることがわかりますが、コアについて説明したときに述べたように、オペレーティングシステムが一部を使用する必要があるため、ジョブ用にそのメモリーをすべて使用できません。ここでも、Hadoopクラスター管理ツールは、メモリーのうちどれだけをジョブに使用できるかを判断できます。オペレーティングシステムとHadoopデーモンに2GBのメモリーが必要な場合、Sparkジョブに使用するために118GBのメモリーが残ります。ノードごとに6つのエクゼキューターを持つことができると決定済みなので、エクゼキューターごとに最大約20GBのメモリーを使用できることになります。ただし、これは100%正しいわけではありません。各エクゼキューターが持つメモリーオーバーヘッドも計算する必要があるためです。前のブログで、オーバーヘッドのデフォルトは384MBであると述べました。これを20GBから差し引くと、1エグゼキューターあたり最大19GBを指定できると言えます。 クラスターリソースの動的割り当て vs. 固定割り当て 上記の数値は、Sparkジョブ内のクラスターリソースの固定または動的割り当てに使用できます。両者の違いは動的割り当てです。動的割り当てでは、使用されるエクゼキューターの最初の数、それほどワークロードがない場合にジョブが使用できる最低限のエクゼキューター、より多くの処理能力が必要な場合の最大数を指定できます。ジョブのためにクラスターのすべてのリソースを使うことができれば素晴らしいですが、その処理能力をクラスター上で実行される他のジョブと共有する必要があります。そのため、Talend Sparkジョブの調整を検討するために先に定義した要因を検討する際に、要件として特定したものに基づいて、最大値の何パーセントを使用可能か決定します。 ジョブを構成したので、次は実際にジョブを実行しましょう。上記で定義した最大設定でもSparkジョブが完了までに時間がかかることがわかった場合は、最大のパフォーマンスを引き出すために、ジョブに戻り、さらにいくつかの設定を確認する必要があります。 Sparkのパフォーマンス まず、Sparkのジョブで2つのテーブルを結合しましょう。Sparkジョブの最適化を開始する前に検討した要因の1つは、データセットのサイズです。テーブルのサイズを確認し、1つが50GBで、もう1つが100MBであると判断したら、Talendコンポーネントのレプリケート結合を利用しているかどうかを確認する必要があります。 …

続きを読む

Apache Sparkのパーティショニングの基礎知識

| 2018年3月5日 | Developer Step-by-Step ビッグデータ統合

Apache SparkのResilient Distributed Dataset(RDD)は、サイズが大きすぎて1つのノードに収まらないため、複数のノードに分割する必要があるさまざまなデータの集合です。Apache Sparkは自動的にRDDをパーティションに分割し、複数のノードに分散します。この操作は遅延評価され(たとえば、アクションがトリガーされるまで実行を開始しないことで管理性が高まり、計算量が低減するため、結果的に最適化と速度が向上します)、変換はDirected Acyclic Graph(DAG)として格納されます。したがって、RDDに対して何らかのアクションが実行されると、Apache SparkがDAGを再計算します。 Apache Sparkのパーティションの特性を理解しておくことで、パフォーマンスの向上、デバッグ、およびエラー処理が容易になります。 以下に、パーティション分割の基本情報をいくつか紹介します。 Sparkクラスター内の各ノードには、1つ以上のパーティションが含まれています。 Sparkで使用されるパーティションの数は設定が可能で、少なすぎると同時実行性の低下、データの偏り(データスキュー)、不適切なリソース利用の原因となり、多すぎるとタスクスケジューリングの所要時間が実際の実行時間より長くなるなどの問題が発生します。デフォルトでは、すべてのexecutorノード上のコアの総数に設定されています。 Sparkのパーティションが複数のマシンにまたがることはありません。 同じパーティション内のタプルは、同じマシン上にあることが保証されています。 Sparkはパーティションごとに1つのタスクを割り当て、各Workerは一度に1つのタスクを処理できます。 Apache Sparkでのハッシュパーティショニングとレンジパーティショニング Apache Sparkは「ハッシュパーティショニング」と「レンジパーティショニング」の2種類のパーティショニングをサポートしています。データ内のキーの分散方法または配列方法や、データに対して実行するアクションに応じて、適切な手法を選択します。以下のような多くの要因が、パーティショニングの選択に影響を与えます。 利用可能なリソース — タスクを実行できるコアの数。 外部のデータソース — ローカルコレクション、Cassandraテーブル、またはHDFSファイルのサイズによってパーティション数が決まります。 RDDの派生に使用される変換 — RDDが別のRDDから派生する際にパーティションの数を決定するためのルールが多数存在します。 Apache Sparkの使用に際しては、留意すべき点がいくつかあります。このブログでは、ビジネスデータ、そのデータのキー、Spark処理における物理リソース、そして何よりもネットワーク、CPU、メモリーを完全に認識しておくことの重要性について説明します。 Apache Sparkのパーティショニングでよく見られる問題には次のようなものがあります。 データの偏り(データスキュー)とシャッフルブロック Apache Sparkのデフォルトのパーティション分割ではデータの偏りが発生し、その結果、データ集約操作中のシャッフルや単一のエグゼキューターのメモリー不足に関連した問題が発生する可能性があります。 この例では、「key-a」のパーティション内のデータ量が大きいため、Exec-5のタスクの完了には他の5つのタスクよりもはるかに長い時間を要します。もう1つの重要なのは、Sparkのシャッフルブロックは2GB以下でなければならないという点です(内部的にByteBuffer抽象化ではMAX_SIZEが2GBに設定されているため)。たとえば、集約、結合、キャッシュ操作などの操作を実行している場合、Sparkシャッフルが発生し、パーティションの数が少ないことやデータスキューが原因でシャッフルブロックの問題が発生する可能性があります。したがって、シャッフルによるMAX_SIZE制限の違反に関連するエラーが発生し始めた場合には、データの偏りが原因であることがわかります。 賢明なパーティショニング では、どうすればデータの偏りとシャッフルブロックを回避できるのでしょうか。非常に重要なのは、メモリープレッシャーを管理し、エグゼキューターのノードでリソースをフル活用できるよう、賢明な方法でパーティション分割を行うことです。そのためには、データのサイズ、タイプ、分散方法を常に把握しておく必要があります。覚えておくべきベストプラクティスは次のとおりです。 ドライバーに負荷をかけないように、またエグゼキューター上でタスクが適切に実行されるように、reduceByKeyやaggregateByKeyなどのアクションの正しい演算子を理解し選択します。 いくつかの大規模で分割不可なファイルでデータを受け取った場合、InputFormatによるパーティション分割では各パーティションに大量のレコードを配置される可能性があります。しかし、利用可能なすべてのコアを活用するのに十分なパーティションは生成されません。この場合、データのロード後に多数のパーティションを使用する再パーティションを呼び出すことで、後続の操作でクラスターのCPUをより多く利用できるようになります。 また、データが偏っている場合は、負荷を均等に分散できる適切なキーを使用して再パーティション化することも推奨されます。 Talendは、選択された適切なキーに基づいて、再パーティション化に必要なtPartitionコンポーネントを提供します。 最適なパーティション数を算出するには Apache Sparkは、RDDの各パーティションに対して1つの同時タスクしか実行できず、その最大数はクラスター内のコア数(またはその2~3倍)になります。したがって、「最適な」数のパーティションを選択するためには、一般的に最低でも並列処理用のエクゼキューターの数と同数のパーティションが必要です。この数値を算出するには、sc.defaultParallelismを呼び出します。パーティションの最大サイズは、最終的にはエグゼキューターの利用可能なメモリーによって決まります。 適切な再パーティション化キーを使用してデータを均等に分散することが不可能な場合もあります。そこで、新しい「偽の」キーを追加し、現在のキーと一緒に使用することでデータを均等に分散させるソルトなどの方法を使用します。次に例を示します。 …

続きを読む