注目の投稿

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

詳細情報
注目の投稿

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

詳細情報
注目の投稿

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

詳細情報
注目の投稿

Talend Winter’20で、データからインテリジェンスを引き出す

詳細情報
注目の投稿

Pipeline Designerの紹介:データ統合の革新

詳細情報

Apache Beamの紹介

| 2016年5月2日 | ビッグデータ統合

  この記事は、Apache Beamプロジェクトの包括的な目標と目的について説明するシリーズ第1回です。 今後のブログでは、Apache Beamを使用してデータ処理ジョブを実装する方法について説明していきます。 すでにビッグデータプラットフォームを使用中であれば、そのプラットフォームの継続的な進化が重要です。 現在Apache Hadoop MapReduceジョブを使用してデータを処理している場合、Apache Sparkに移行することで、新しい機能を活用してパフォーマンスを向上できます。 既存のバッチ処理機能に加えて、ストリーミングデータ処理を実装することもお勧めします。 または、簡単な統合パターンを探したり、他のテクノロジーにアップグレードしたりしてもよいでしょう。 たとえば、現在Apache Sparkを使用している場合は、何らかのユースケース向けとして、またはメリットを評価するための概念実証(PoC)の一環として、Apache Flinkを使用することを検討できます。 オンサイトでさまざまなランタイムを使用している場合、異なるテクノロジーの間での切り替えは非常に難しく、またコストがかかる場合があります。 現在ASFでインキュベーションプロジェクトとなっている新しい分散処理ツールのApache Beamは抽象化レイヤーを提供し、これによって開発者はBeamプログラミングモデルを使用してBeamコードに注力できます。※2017年1月現在、トップレベルプロジェクトに昇格しました。 Apache Beamによって実装が使用中のランタイムテクノロジーに依存しなくなるので、テクノロジーをすばやく簡単に切り替えることが可能です。 Apache Beamは、その範囲についても非依存型プログラミングモデルを提供します。つまり、このプログラミングモデルは統一的であり、これによって開発者はバッチとストリーミングの両方のデータ処理を実装できます。 この特長は、Apache Beamという名称の由来でもあります (BatchのBとstrEAMのEAM)。 Beamプログラミングモデルを使用してデータプロセスを実装するには、Beamが提供するSDKまたはDSLを使用します。 使用するSDKは1つ(Java SDK)だけです。 ただし、Python SDKのリリースが見込まれており、Beamは近い将来にScala SDKと追加のDSL(XMLを使用する宣言的DSL等式)を提供予定です。 Apache Beamの場合、まずBeam SDKを選択してから、Beamパイプラインとしてデータ処理を実装します。 プロセスを展開して実行する実際のランタイムを考慮する必要はありません。 Apache Beamはランナーを提供し、 ランナーがパイプラインをターゲットランタイムに変換します。 Apache Beamは、Apache Spark、Apache Flink、及びGoogle Cloud Dataflowプラットフォーム用のターンキーランナーを提供します。 また、Apache Hadoop MapReduce、Apache …

Read Article

Utilizing the Kerberos Protocol in Talend

| 2016年4月7日 | ビッグデータ統合

  Blog authored by Nitin Kudikala, Customer Success Architect at Talend As companies try to become data driven enterprises, new distributed data architectures such as Hadoop create new opportunities to derive more information and intelligence from their Data assets. As these technologies evolve, securing the data stored in …

Read Article

Talendのジョブ設計パターンとベストプラクティス(第2部)

| 2016年3月30日 | Developer Step-by-Step ETL / ELT

  前回掲載した、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つでも問題ありません。注意:「参照プロジェクト」の数が多すぎると、その効果が損なわれてします。参照プロジェクトでは、慎重な管理が非常に重要になります。その用途とルールを「開発ガイドライン」ドキュメントに明記し、チーム全体が順守することにより、最適なコラボレーションを実現できます。 オブジェクトの命名規則 …

Read Article