月別: August 2018

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

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 Management Console(TMC)でプロジェクトを作成します。次に、Gitリポジトリを使用してジョブのアーティファクトを保管するようにプロジェクトを構成します。さらに、ホストされたNexusサーバーがジョブで必要な全てのサードパーティライブラリを保管するように、TMCでNexusを構成する必要があります。Talend Cloudのアカウントで、TMCを使用してプロジェクトとアーティファクトの管理を行います。 次に、Studioをインストールし、Talend Cloudアカウントで接続します。Studioは、Talendのメインとなるジョブ設計環境であり、ここで統合ジョブをビルドします。これらのステップに従ってStudioからクラウドアカウントでログインすると、TMCで定義されたプロジェクトを確認でき、Gitリポジトリに構成されたプロジェクトを使用できます。必要なプラグインをStudioに追加するには、後述のステップに従います。 最後に必要な2つのコンポーネントは、CI BuilderとTalend […]


オフィス・デポが、複数のタッチポイントにわたるカスタマージャーニーを統合

2017年1月にAurelius Group(ドイツ)がオフィス・デポ社のヨーロッパ事業部門を買収して創設したOffice Depot Europe社は、現在オフィス用品/サービスの大手リセラーとして、紙、ペン、フリップチャートからオフィスファーニチャーやコンピューターまで、あらゆるオフィス用品をヨーロッパ14か国で企業に提供しています。 データの一元化で小売の課題に対応 従来同社ではオフラインのメールオーダーカタログによる販売モデルを採用しており、主としてテレマーケティングを行っていました。その後、オフラインとオンラインのショッピングを組み合わせたハイブリッドの小売モデルに移行しましたが、そのためには、異なるチャネルを最適化するデータ統合戦略が必要となりました。 さらに、多様なバックエンドシステムやヨーロッパ各地から様々な種類のサプライチェーンデータが集まるようになり、データ分析が複雑化していきました。 現在Office Depot Europe社では、Talendを使用して広範な運用システムからデータを取り込めるようになっています。 このアーキテクチャーにはオンプレミスのHadoopクラスターが含まれており、ここでデータをハブのデータレイクに取り込む前にHortonworks、Talend Data Integration、Talend Data Qualityを使用してチェックし、データ品質を保っています。 サプライチェーンから財務までユースケースを支援 オンラインとオフラインのデータを統合することで、統一された360度の顧客ビューが提供され、カスタマージャーニーが明確化されました。 現在Office Depot Europe社は、顧客が好む購入方法に基づいて、より具体的にセグメントを分類し、オンラインや実店舗の区別なく最重要顧客に到達できる戦略を立てています。 たとえば、オフラインのさまざまな顧客体験を比較し、デジタル広告による影響を把握できます。 あるいは、カスタマーサービスオペレーターが顧客情報をすべて表示して詳細を把握したうえで顧客に対応できます。 また、同社のデータハブのアプローチは、サプライチェーンや財務部門を含む組織全体で、すべてのバックオフィス機能に高品質のデータを提供します。 サプライチェーンのバックエンドシステムのデータは国ごとに異なりますが、同社ではこれらのデータ統合が可能になったことで、ピッキング工程の効率が最も高い流通拠点を割り出してその理由を分析したり、また、売れ筋商品の在庫が少なくなるリスクが最も高い拠点を特定するなど問題に対処できるようになりました。


ビッグデータの波に乗る:「Forrester Wave™: Big Data Fabric, Q2 2018」から得られる3つの注目点

フォレスターが発表した今回のForrester Waveレポートは、データ市場で大きな変化が起こっていることを再び証明する形となりました。 新しいイノベーションによって、データからより大きな価値をかつてない速さで得られるようになってきています。  わずか18か月で、新しい変化の波が起こっているのです。このレポートで注目すべきポイントは次の3点です。 << 「Forrester Wave: Big Data Fabric, Q2 2018」レポートはこちらからダウンロードできます >> 1) レガシーが足かせとなる ビッグデータとクラウドの融合が進む中、イノベーションの加速がビジネスの俊敏性を高め、複雑性を排除してきました。 ビッグデータのワークロードがクラウドに移行している今日、データ駆動型の企業は事実上無限の拡張性を手に入れました。しかしながら、従来のコスト構造のままでは、この規模を維持できません。 ここで、既存企業と新興プレイヤーの違いが現れます。一般に既存企業は、主としてレガシーを活用しますが、新興プレイヤーはイノベーションをより迅速かつ容易に導入できるため、コストもわずかしかかかりません。つまり、レガシーシステムが足かせとなっているのです。 2) 継続的イノベーションが鍵となる フォレスターによると、「[ビッグデータファブリックは]、プロセス、ワークフロー、パイプラインを自動化し、コードを自動的に生成し、データを合理化して展開を簡素化することによって、複雑性を最小限に低減」します。また、Talendのプラットフォームは、「HadoopやSparkのディストリビューションだけでなく、サーバーレスコンピューティングやコンテナーのような新テクノロジーを使うプロセスを簡素化」すると評価されています。 Talendは、継続的イノベーションが最新データアーキテクチャーの鍵であると考えています。フォレスターレポートで「リーダー」の評価を受けたことは、次世代リーダーとしてのTalendの位置付けが確認されたものとみなすことができます。 3) クラウドがあらゆる可能性を実現する クラウドは、新しいワークロードの登場を促し、多種多様なユースケースの実現を後押ししました。 今やデータワークロードの数は著しく増え、複雑化を極め、データタイプも多岐にわたります。処理方法も変わり、自動化も進みました。 クラウドが未来を握り、クラウドを最大限に活用できるのがビッグデータファブリックなのです。 フォレスターレポートでも次のように述べられています。 リーダーは、[中略]より広範なユースケースをサポートし、AIや機械学習の能力を強化し、優れたスケーラビリティ機能を提供しています。 実力者(Strong Performer)から追い上げを受け、既存リーダーはより多くのデータ管理機能と展開オプションを提供するようになりました」 まとめ 本日、TalendはForrester Wave Big Data Fabricレポートでリーダーの評価を得たことを発表しました。私たちはこの位置付けをたいへん誇りに思います。 Talendは、レポートで評価の軸とされる3つのカテゴリのうち、「現行製品(Current Offering)」と「戦略(Strategy)」の2つのカテゴリで、調査対象ベンダー中最高のスコアを獲得しました。 データ駆動型のお客様各社がTalendの支援を得て実現した成果が、これらの評価に反映されていることは確かでしょう。 Talendの統一的なデータ統合プラットフォームは、すべてのデータを解放し、より大きなビジネスの知見をより迅速に得るうえで役立っています。しかし、この言葉をうのみにする必要はありません。フォレスターレポートをダウンロードして、実際にご確認ください。


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

最近、北米大手銀行の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 lack of big data skills, on both the […]


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

前回のブログでは、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 – uniqオブジェクトの一意のID x, y – 地図上の座標(整数) データの形式が有効でない場合にレコードをスキップするように、処理する必要があります。 パイプラインの作成 前回のブログで取り上げたバッチ処理と同様に、パイプラインを作成します。 Pipeline pipeline = Pipeline.create(options); コマンドラインオプションをパイプラインに渡すためのOptionsオブジェクトは、細かく指定できます。詳細については、Githubで例の全体を参照してください。 次に、Kafla入力トピックからデータを読み込みます。前述のとおり、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>() { @ProcessElement public void processElement(ProcessContext processContext) { […]


チームスポーツ型のデータ活用:IT部門とビジネス部門の連携によるデータクオリティの強化

データクオリティは、データエンジニアが単独で担うタスクと思われがちですが、これは完全に誤った認識です。ビジネス部門の人々は低品質なデータの影響を真っ先に受けるため、データ関連の課題の解決に熱心ですが、データの更新には積極的にかかわろうとしないことが多々あります。これは、データクオリティアプリがそのようなユーザーを念頭に設計されていなかったり、単に使用が許可されていなかったりするためです。このような理由から、低品質なデータが増え続けています。ガートナーによると、低品質なデータに起因するコストは2017年には50%増加し、1社あたり年間平均1,500万ドルに達しました。手をこまねいているだけでは、数年以内にコストは爆発的に増加するでしょう。 しかし、変化が訪れています。データクオリティは、今や全社をあげた戦略的な優先事項となり、さまざまな分野の専門家を巻き込みつつあります。スポーツチームのように組織が一丸となって臨むことが、あらゆるデータ品質の課題を解決するうえでの秘訣であると言えます。 チームスポーツのごとく、あらゆる角度からのアプローチが必要とされる。単一のアプローチでは成功は難しい チームスポーツのごとく、チームを成功させ勝利に導くために実践すべきことがある チームスポーツのごとく、ビジネス/ITチームがデータクオリティの課題に立ち向かうには、適切なツール、適切なアプローチ、そして適切な人材が必要である とは言え、これはそれほど難しいことではありません。課題を特定し、スタートから正しい方法で取り組んでいくだけです。 適切なツール:シンプルで相互接続されたアプリで複雑さを克服する 市場には多くのデータクオリティツールが溢れています。ビッグデータの展示会では、データプレパレーション/スチュワードシップ用ツールや、低品質なデータの課題に対応する新しいツールが紹介されています。しかし、その中で、誰でも使用できるデータクオリティを提供しているツールはごくわずかです。ツールには、高度な機能を持ち、使用には高い専門性が必要とされるツールがあります。 多くの場合、これらのツールは複雑で、使用するための十分なトレーニングが必要です。ユーザーインターフェイスも万人向けではなく、実際に使いこなせるのはIT担当者くらいです。データ品質管理について、短期間での対応に迫られたときには、締切に間に合わないでしょう。これは、新人パイロットに高性能機器が搭載されたジャンボジェット機の操縦を一任するくらい無謀な行為です。 他方では、シンプルで強力なアプリがありますが、多くの場合にデータ品質プロセスに使用するにはサイロ化されすぎています。シンプルなUIを使うことで、ビジネス部門のユーザーにうまく焦点を当てていても、コラボレーション型のデータ管理という重要な要素が足りません。この点こそが課題なのです。成功は、ツールや機能そのものでなく、ツール同士がいかにやり取りできるかにかかっています。そのためには、共同作業でのデータ/アクション/モデルの共有、操作、転送が可能なプラットフォームベースのソリューションが必要です。Talendは、まさにこのようなソリューションを提供します。 データを1人で管理することがほぼ不可能なユースケースに直面することが多々あるでしょう。共同作業ができれば、データのライフサイクル全体を通じてユーザーの活動が強化され、ビジネスはデータのクレンジング、調整、マッチング、解決などの従来の障害を克服できます。 正しいアプローチ 共同でデータクオリティを強化するには、要となるシンプルな段階的アプローチで分析、改善、制御に取り組む必要があります。 データ環境を分析する 最初に、大局的な観点からデータ品質の重要課題を特定します。分析を行うことで、データの全体像を把握できます。データエンジニアは、自分でTalend Studioのデータプロファイリングを使用して顧客データをプロファイリングする代わりに、それらの顧客を最もよく知るビジネスアナリストにその作業を任せることができます。Talend Data Preparationはシンプルながらも強力な機能を提供し、すべてのデータセット項目において、データクオリティ機能のリアルタイムインジケーターを確認することができます。Talend Data Preparationでは、データセットからプレパレ―ションを簡単に作成できます。 ここで例として、セールス部門と一緒にマーケティングキャンペーンを準備するうえで、SalesForce CRMシステムの低品質データが問題となっているチームの場合を考えてみましょう。Talend Data Preparationでは、SalesForceから取得したビジネスデータを自動的かつ対話的にプロファイリングし、参照できます。Talend Data Preparationを経由してSalesforceに接続すれば、全体的なデータ品質を明確に把握できます。問題を特定したら、単純でありながら強力な処理によって1人でも解決できますが、これは表面的な成果にすぎません。ここで必要となるのが、データエンジニアの専門性を生かして、データクオリティのフローを掘り下げて改善することです。 専門性の高いツールでデータを改善し、スチュワードシップキャンペーンを設計して改善を開始する IT部門のデータエンジニアは、Talend Studioをデータクオリティエンジンとして使用することで、Talend Studioの強力な機能を活用できます。たとえば、t-フィルターなどの単純なデータフィルタリング処理により、メールアドレスの不正なパターンを特定したり、ドメインリストから不適切なドメインアドレスを除外したりするなどの選別を実行できます。この段階では、低品質なデータをデータクオリティプロセスで隔離する必要があります。フィルタリングが完了したら、他のチームメンバーの支援を受けて、データクオリティの改善を続行します。ここでTalend Studioは、データクオリティプロセスの主軸としての役割を果たします。Talend Studioから、自分のクレデンシャルを使ってTalend Cloudにログインし、ビジネス部門寄りのユーザーへとデータクオリティを拡張できます。ビジネスユーザーでもデータエンジニアでも、Talend CloudのTalend Data Stewardshipでクレンジングキャンペーンを実施し、部門をまたいだ横断チームと一緒に低品質なデータの課題を解決できます。そのためには、まずキャンペーンを設計します。 Talend Data Preparationと同じUIを持つTalend Data Stewardshipは、ビジネスユーザーに使いやすい機能を提供します。これを完全に運用化してTalend Studioに接続することにより、ITやビジネスプロセスに携わるユーザーはデータクオリティを拡張できます。専門ツールになじみがないが、ビジネスの知識と経験を生かしてシンプルなアプリでデータクレンジングを行いたいと思っている新しいユーザーも、データクオリティのタスクを担うことができます。 これが協調的データ管理の本質であり、処理ごとに個別のアプリを使用しながら、データの取り込みから消費までを管理する単一プラットフォーム上でシームレスに連動させることができます。 一例として、関わる人すべてのためにデータを改善するクラウドベースのツールの使い方について、次のウェビナーで紹介しています。  https://info.talend.com/en_tld_better_dataquality.html スチュワードのネットワーク全体とともにデータクオリティプロセスを末端まで制御する データスチュワード用のキャンペーンを設計したら、データスチュワードに支援を依頼します。キャンペーンを実施して、データスチュワードに自由にデータを確認してもらいます。ここで、Talend Data Stewardshipが重要な役割を果たします。使いやすいUIのアプリケーションなので、データスチュワードもデータクオリティに関与しやすく、データに関する問題を簡単に解決し、実際にデータを業務に必要としているキーパーソンがデータクオリティに関与することができます。シンプルなアプリを使うことで、ビジネスデータを修正しやすくなります。 データクオリティプロセスにビジネスユーザーを巻き込むことには、いくつかの利点があります。ビジネスアナリストは適切なデータを選び出すための経験と必要なスキルを持っているため、データクオリティの精度が高くなります。ビジネスユーザーは、データクオリティを最も気にかける当事者として、積極的に関わり、一緒に課題に取り組むようになります。 ここでは、機械学習はデータ駆動型戦略の仮想の仲間として役立ちます。データスチュワードが足りない詳細を集めると、Talend Data Qualityソリューションの機械学習機能はデータスチュワードから学び、データスチュワードが解決した初期のレコードに基づいて将来のレコードのマッチングを予測します。システムはユーザーから学ぶため、ユーザーには余裕が生まれ、ほかのデータスチュワードシップキャンペーンを推進したり、データプロセスの影響と制御を強化したりできます。 最後に、データスチュワードシップキャンペーンからSalesForce CRMシステムにデータフローを戻して構築します。これにより、データスチュワードによりクレンジングされ解決された低品質なデータがSalesforce CRMシステムに再度取り込まれます。このような処理は、1つのプラットフォーム上でアプリを相互接続することで、簡単に実現できます。また、Talend […]