ビッグアイアン、ビッグデータを満たす：HadoopとSparkでメインフレームデータを解放する

2024

Techopediaスタッフ、2016年6月2日

まとめ：ビッグデータを迅速かつ効率的に処理するために、メインフレームでHadoopエコシステムが使用されています。

あなたは現在ログインしていません。ビデオを見るにはログインまたはサインアップしてください。

エリック・カバナ：みなさん、木曜日は東部標準時の 4時です。最近は、Hot Technologiesの時間です。はい、私の名前はエリック・カバナです。今日のウェブセミナーのモデレーターになります。「ビッグアイアン、ビッグデータと出会う」という良いものです。「HadoopとSparkでメインフレームデータを解放する」という見出しが大好きです。古いミートと新しいミートについてお話します。うわー！私たちは、エンタープライズITの過去50年間で話したすべてのことを網羅しています。 Sparkはメインフレームと出会って、大好きです。

あなたについてのスポットが本当にあり、私については十分です。今年は暑いです。このシリーズのホットトピックについては、特定の分野、特定の空間を人々が理解できるように努めているためです。たとえば、分析プラットフォームがあるとはどういう意味ですか？メインフレームからビッグデータを解放するとはどういう意味ですか？これらはすべてどういう意味ですか？特定の種類のテクノロジーを理解し、それらがどのようなミックスに収まるか、どのように活用できるかを理解しようとしています。

今日は2人のアナリストがいますが、もちろんSyncsortのTendüYogurtçu氏もいます。彼女は私たちのスペースで先見の明があり、私たち自身のDez BlanchfieldとDr. Robin Bloorと一緒に今日彼女をオンラインにしたことを非常に喜んでいます。簡単な言葉をいくつかお話しします。 1つは、皆さん、このプロセスであなたが大きな役割を果たしているということです。そのため、良い質問を恥ずかしがらないでください。 WebキャストのQ&Aコンポーネント（通常はショーの最後）でそれらにアクセスしたいと思います。そして、私が言わなければならないのは、私たちがたくさんの良いコンテンツを持っているということだけです。ですから、これらの少年たちが言わなければならないことを聞いて興奮しています。それで、私はそれをDez Blanchfieldに引き渡します。デズ、床はあなたのものです。

Dez Blanchfield：ありがとう、エリック、そして今日は参加してくれてありがとう。だから、世界で一番好きなものの1つであるメインフレームについて話をする機会を得たとき、私は非常に興奮します。最近はあまり愛されていません。私の見解では、メインフレームは元のビッグデータプラットフォームでした。一部のコンピューターは当時唯一のコンピューターであり、それが正当なポイントであると主張する人もいますが、60年以上にわたって、実際にビッグデータが最近人気を集めているエンジンルームになっています。そして、なぜそうだと思うのか、ちょっとした旅にあなたを連れて行きます。

メインフレームが現在画面に表示されているイメージから移行するという状況で、テクノロジーハードウェアスタックの旅を見てきました。これは古いFACOMメインフレームで、私のお気に入りの1つです。私たちは大きな鉄の時代、90年代後半、そしてドットコムブームに身を投じました。これは、Sun Microsystems E10000です。これは96 CPUの絶対的な怪物でした。当初は64でしたが、96 CPUでアップグレードできました。各CPUは1, 024スレッドを実行できます。各スレッドは、同時にアプリケーションレートになる可能性があります。それは単なる怪物であり、実際にドットコムブームを支えました。これは、大企業だけでなく、いくつかの大きなウェブサイトであり、私たちが呼んでいるすべての大きなユニコーンです。

そして、この一般的な市販のPCモデルになりました。多くの安価なマシンを束ねてクラスターを作成し、大きな鉄の課題に取り組み、特にオープンソースの検索エンジンであるNutchを生み出したHadoopプロジェクトという形でビッグデータになったものに取り組みました。そして、基本的にメインフレームと、多数の小さなCPUが接着され、Lパスのように動作し、個別のジョブまたはジョブの一部を実行する形で動作するように再作成しました。小規模で始めた方が安くなりますが、これらの大きなクラスターの多くは常にメインフレームよりも高価になります。

これらのことについての私の見解は、ドットコムブームからWeb 2.0になり、ユニコーンを追いかけるまでのラッシュでは、このプラットフォームがまだ私たちの最大のミッションクリティカルなシステムの多くを動かしていることを忘れていたということです。メインフレームプラットフォームで何が実行されているかを考えるとき。それは非常にビッグデータ、特にデータの主力ですが、確かにビッグデータです。特に銀行、資産管理、保険などの従来の企業および政府システムは、私たち全員が毎日使用しています。

航空会社の予約およびフライト管理システム、特にリアルタイムが重要なフライト管理。ほぼすべての州政府および連邦政府がメインフレームを保有しており、常に多くの人がメインフレームを保有しています。小売および製造。いくつかの古いソフトウェアは、現在使用されているだけで、消えることはありません。製造環境を強化し続け、確かに大規模に小売りします。医療システム。防衛システム、確かに防衛システム。

この数週間、ミサイル制御システムの一部が、部品を見つけるのに苦労している古いメインフレームでまだ実行されているという事実に関する多くの記事を読みました。彼らは新しいメインフレームにアップグレードする方法を考えています。輸送および物流システム。これらはセクシーなトピックのように聞こえないかもしれませんが、これらは私たちが行全体で日常的に扱っているトピックです。また、一部の非常に大規模な通信環境は、メインフレームプラットフォームで実行されています。

そこにあるデータの種類について考えると、それらはすべてミッションクリティカルです。それらは本当に重要なプラットフォームであり、私たちが毎日当たり前のように考えているプラットフォームであり、多くの点で生活を可能にします。だから、まだメインフレームを使用しているのは誰ですか？これらの大きなプラットフォームを保持し、このデータをすべて保持しているこれらの人々は誰ですか？さて、私がここで言ったように、メディアがビッグアイロンから一般的な市販のクラスターや安価なPCやx86マシンのラックに移行し、メインフレームが死んでなくなったと考えるのは簡単だと思います。しかし、データによると、メインフレームは決して消えることはなく、実際にはそこにとどまっています。

ここ数週間で私がここでまとめた調査では、企業、特に大企業のデータの70％が実際には何らかの形のメインフレームに存在していることが示されています。フォーチュン500の71％は、メインフレームでどこかでコアビジネスシステムを実行しています。実際、ここオーストラリアでは、都市の中央にデータセンターを持つ多くの組織があります。事実上、実際のアンダーグラウンドコンピューターであり、メインフレームの数だけがそこで実行され、仕事を刻み、楽しくやっています。そして、街のある特定の場所に足を踏み入れて通りを歩いていると、メインフレームで満たされたこの巨大なデータセンターがあることを知っている人はほとんどいません。世界中の100銀行のうち92銀行、つまり上位100銀行は、依然としてメインフレームで銀行システムを実行しています。世界中の上位25の小売チェーンのうち23がメインフレームを使用して、EIPおよびBIプラットフォームで小売管理システムを実行しています。

興味深いことに、トップ10の保険会社のうち10社は依然としてメインフレームでプラットフォームを実行しており、実際にはメインフレームでクラウドサービスを強化しています。インターフェイスがあるミドルウェアがある場所のどこかでWebインターフェイスまたはモバイルアプリを使用している場合、実際にはバックエンドで非常に大きくて大きなものと通信します。

メインフレームプラットフォームで稼働している世界中の225以上の州および地方政府機関がまだ見つかっています。その理由はたくさんあると確信しています。新しい鉄を検討する予算がないかもしれませんが、それは非常に重要なデータを備えたメインフレームで実行されている非常に大規模な環境の大きなフットプリントです。そして、前述したように、ほとんどの国は依然としてメインフレーム上で主要な防衛システムを実行しています。多くの点で彼らはそこから降りようとしていると確信していますが、そこに行きます。

2015年、IDCは調査を実施し、調査対象のCIOのうち350人がメインフレームの形でビッグアイロンを所有し管理していると報告しました。そして、世界中で生産されている大規模なHadoopクラスターの数を超えている可能性が高いと思いました。私は先に進んでそれを検証しますが、それは大きな数字でした。 350人のCIOが、1つ以上のメインフレームがまだ生産されていると報告しました。

昨年2015年、IBMは、メインフレームプラットフォームの13 ^回目の反復である強力なZ13を提供しました。 IBMがまだメインフレームを製造していることに驚いたため、メディアはこのことについて熱狂しました。彼らがフードを持ち上げて、その下にあるものを見たとき、彼らはビッグデータ、Hadoop、そして確かにクラスターの形で私たちが興奮したほとんどすべての現代のプラットフォームと同等であることを実感しました。このことはSparkを実行し、Hadoopをネイティブに実行しました。その上で何千ものLinuxマシンを実行でき、他のクラスターのように見え、感じられました。それは非常に驚くべき機械でした。

多くの組織がこれらのことを取り上げ、実際、これらのマシンのうちどれだけが占めているかについてのデータをいくつか作成しました。今では、3270テキストターミナルがしばらくの間Webブラウザーとモバイルアプリに置き換えられ、それをサポートするデータがたくさんあるという見方がありました。今、これらのメインフレームがなくなることはなく、かなりの量のデータがあることに気付いた時代に入っていると思います。そして、私たちが今やっていることは、単に市販の分析ツールと呼ぶものを追加することです。これらはカスタムビルドのアプリではありません。これらは一回限りのオーダーメイドです。これらは、パッケージ化されたボックス自体を購入し、メインフレームにプラグインして分析を行うだけで、文字通りできます。

前にも言ったように、メインフレームは実際には60年以上も使用されています。それがどれくらいの長さかを考えると、それはほとんどの生きているIT専門家のキャリアが実際に及ぶよりも長いです。そして実際、おそらく彼らの生活の一部でさえ。 2002年、IBMは2, 300個のメインフレームを販売しました。 2013年には、2, 700のメインフレームに成長しました。これは、2013年の1年間でのメインフレームの2, 700の販売です。2015年の正確なデータを取得できませんでしたが、2015年、2013年に1年に販売された3, 000台に急速に近づいていると思います。

メインフレームプラットフォームの13 ^回目の反復であるZ13のリリースでは、ゼロから開発するのに約12億ドルまたは13億ドルかかると思います。IBMは、他のクラスターと同じように見えるマシンです。今日、私たちはネイティブにHadoopとSparkを実行しています。また、他の分析ツールやビッグデータツールから確実に接続することも、既存または新規のHadoopクラスターのいずれかに常に接続することもできます。私は、ビッグデータ戦略にメインフレームプラットフォームを含めることは必須だと考えています。明らかに、データがある場合は、大量のデータがあり、そこからデータを取得する方法を見つけたいと思います。そして彼らは、ビジネスの世界が行く限り、精神的および感情的に多くの方法で塵を集めるために残されていますが、彼らはここにとどまります。

メインフレームでホストされるデータへのすべての分析ツールの接続性とインターフェースは、企業、特に政府のビッグデータ計画の重要な部分である必要があります。そして常にソフトウェアはそれらに気づき、それらをよく見て、これらのものの中にあるものを理解し、実際に内部にあるものについて少し洞察と感じを得るようになる心をつなげます。それで、私は私の大切な同僚であるロビン・ブロア博士に引き渡します。彼はその小さな旅に追加します。ロビン、取り去ってください。

ロビン・ブロア：まあ、ありがとう。さて、Dezがメインフレームの歌を歌ったので、古いメインフレームの世界と新しいHadoopの世界の観点から私が考えていることを説明します。ここでの大きな疑問は、すべてのデータをどのように管理するかです。メインフレームがビッグデータ機能に関して課題を抱えているというのは私の意見ではありません。ビッグデータ機能は、Dezが指摘したように、非常に優れています。実際には、Hadoopクラスターを配置できます。それが挑戦されているのは、その生態系の観点からであり、私はそれについて少し詳しく説明します。

メインフレームの配置を次に示します。メインフレームの人気が低下し始めた90年代半ば以降、エントリーコストが高く、過去に実際に起こったことは、ローエンド、つまり安価なメインフレームを購入した人々を失いがちでした。それらの人々にとっては特に経済的ではありません。しかし、実際にはメインフレームのミッドレンジとハイレンジで実際より高い位置にありますが、実際には信じられないほど安価なコンピューティングでした。

言うまでもなく、メインフレームに実装されたLinuxによってすべてのLinuxアプリケーションを実行できるようになったため、Linuxによって救われました。多くのLinuxアプリケーションは、ビッグデータが1語、あるいは2語になる前にそこに行きました。実際には、プライベートクラウド用のかなり優れたプラットフォームです。そのため、ハイブリッドクラウドの展開に参加できます。問題の1つは、メインフレームのスキルが不足していることです。存在するメインフレームスキルは、人々が年々退職して業界を去るという意味で高齢化されており、人数の点で置き換えられているだけです。それが問題です。しかし、まだ安価なコンピューティングです。

もちろん、チャレンジされた領域は、このHadoop全体です。これは、元のHadoop象を使ったDoug Cuttingの写真です。 Hadoopエコシステムは、今後も引き続き主要なビッグデータエコシステムです。メインフレームが実際に達成できるよりも優れたスケールアウトを提供し、データストアとしてのコストを大幅に削減します。 Hadoopエコシステムは進化しています。これについて考える最良の方法は、特定のハードウェアプラットフォームとそれを使用するオペレーティング環境が支配的になり、エコシステムが生き生きとなることです。そして、それはIBMメインフレームで起こりました。まあ、後でDigital VAXで、Sunのサーバーで、Windowsで、Linuxで起こった。

そして何が起こったのかというと、Hadoopは、データの一種の分散環境として常に考えている、または考えたいと思います。エコシステムは信じられないほどの速度で進化しています。オープンソース、Spark、Flink、Kafka、Prestoのさまざまな印象的な貢献について言及した後、その中にHadoopに搭載されているNoSQLおよびSQL機能を追加します。 Hadoopは、実際に企業コンピューティングに存在する最もアクティブなエコシステムです。ただし、データベースとして扱いたい場合は、現時点では、特にデータウェアハウスの分野で、実際のデータベースと考えがちなものと比較することはできません。そして、CouchDBなどのようにHadoopで実行されない多くの大きなNoSQLデータベースの成功をある程度説明しています。

データレイクとして、他のどのプラットフォームよりもはるかに豊かなエコシステムを備えており、そこから排除されることはありません。そのエコシステムは、オープンソースのエコシステムだけではありません。現在、Hadoop向けに基本的に構築された製品またはHadoopにインポートされた製品を所有しているソフトウェアメンバーが劇的に増えています。そして、彼らはエコシステムを作成したばかりで、その幅の点で競合できるものはありません。そして、それは本当にビッグデータの革新のためのプラットフォームになることを意味します。しかし、私の意見ではまだ未熟であり、Hadoopで運用上成熟しているものとそうでないものについて長い議論ができるかもしれませんが、この特定の領域を検討しているほとんどの人は、Hadoopがメインフレームより数十年遅れていることをよく知っていると思います運用能力の面で。

進化するデータレイク。データレイクは定義によってはプラットフォームであり、企業のコンピューティングにデータレイヤーがあると考えると、固定データベースとデータレイヤーを構成するデータレイクの観点から考えるのは非常に簡単です。データレイクアプリケーションは多種多様です。 Hadoopをステージングエリアとして使用する場合、またはHadoopとSparkをステージングエリアとして使用する場合に実行する必要があるさまざまなデータの問題を説明する図があります。また、データ系統、データクレンジング、メタデータ管理、メタデータ検出など、ETL自体に使用できますが、多くの場合、データを取り込むにはETLが必要です。マスターデータ管理、データのビジネス定義、サービス管理Hadoopで何が起こっているのか、データのライフサイクル管理、HadoopからのETL、そしてHadoopで実行できる直接的な分析アプリケーションもあります。

そして、それが非常に強力になり、正常に実装および実装された理由です。通常、少なくともこの種のアプリケーションのコレクションがその上で実行されています。そして、それらのアプリケーションのほとんど、特に私が簡単に説明したものは、現在メインフレームでは利用できません。ただし、メインフレーム、メインフレームのパーティションで実行されているHadoopクラスターで実行できます。

私の意見では、データレイクは高速データベース分析とBIの自然なステージングエリアになりつつあります。企業データであろうと外部データであろうと、データを取り込む場所になり、使用するのに十分なほどきれいになり、使用に適した構造になったら、それを引き渡します。そして、これらすべてはまだ初期段階にあります。

私の意見では、メインフレームとHadoopの共存という考え方は、最初に大企業がメインフレームを放棄する可能性は低いということです。実際、最近見た兆候は、メインフレームへの投資が増えていることを意味しています。しかし、Hadoopエコシステムも無視するつもりはありません。多くの企業が実際にプロトタイピングと実験を行っているだけでも、Hadoopを使用している大企業の60％の数字を見ています。

問題は「データを共有する必要があるため、これら2つのことをどのように共存させるか」です。メインフレームに転送する必要があるデータレイクに持ち込まれるデータ。メインフレーム上のデータは、他のデータに結合するために、データレイクに移動するか、データレイクを経由する必要がある場合があります。そして、それは起こるでしょう。そしてそれは、高速データ転送/ ETL機能が必要であることを意味します。メインフレーム環境で、またはHadoop環境で何かと作業負荷を動的に共有することはほとんどありません。共有されるデータになります。また、大部分のデータは、Hadoopが最も低コストのプラットフォームであるという理由だけで、必然的にHadoopに保存されます。そして、エンドツーエンドの分析処理もおそらくそこにあるでしょう。

要約すると、最終的には、多くの企業にとってメインフレームを含む企業データレイヤーの観点から考える必要があります。そして、そのデータ層は積極的に管理する必要があります。そうしないと、2つはうまく共存しません。私はあなたにボールを渡すことができますエリック。

エリック・カバナ：繰り返しになりますが、テンデュはあなたをプレゼンターにしたばかりです。

TendüYogurtçu：ありがとう、エリック。呼んでくれてありがとう。みなさん、こんにちは。組織内の資産がメインフレームから分析プラットフォーム上のビッグデータに平準化されているとみなす方法に関連して、顧客とのSyncsortの経験について話します。また、セッションの最後に聴衆からの質問をする時間があり、それがこれらのウェブキャストの中で最も貴重な部分だからです。

Syncsortが何をするのか分からない人のために、Syncsortはソフトウェア会社です。私たちは実際に40年以上になります。メインフレーム側で開始され、当社の製品は、メインフレームからUnix、そしてオンプレミスとクラウドの両方のHadoop、Spark、Splunkなどのビッグデータプラットフォームにまで及びます。私たちの焦点は常にデータ製品、データ処理、データ統合製品にありました。

ビッグデータとHadoopに関する私たちの戦略は、本当に最初からエコシステムの一部になることです。非常に軽量なエンジンでのデータ処理に真剣に取り組んでいるベンダーの所有者として、データ処理プラットフォームとなるHadoopに参加し、組織のこの次世代データウェアハウスアーキテクチャの一部になる大きな機会があると考えました。 2011年以来、MapReduceをはじめとするオープンソースのApacheプロジェクトに貢献してきました。 Hadoopバージョン2でトップ10に入り、Sparkパッケージを含む複数のプロジェクトに実際に参加しました。当社のコネクタの一部はSparkパッケージで公開されています。

完全にフラットなファイルベースのメタデータである非常に軽量なデータ処理エンジンを活用し、Hadoop Distributed File Systemのような分散ファイルシステムに非常に適しています。そして、ビッグデータ製品を発表する際に、メインフレームの伝統、アルゴリズムに関する専門知識を活用しています。そして、Hortonworks、Cloudera、MapR、Splunkなどの主要なベンダーとの緊密なパートナー関係を築いています。 Hortonworksは最近、Hadoopを使用したETLオンボーディング用に製品を再販すると発表しました。デルとClouderaとの緊密なパートナーシップにより、ビッグデータアプライアンスの一部としてETL製品も再販されています。そして実際にSplunkを使用して、メインフレームのテレメトリとセキュリティデータをSplunkダッシュボードに公開します。私たちは密接なパートナーシップを結んでいます。

すべてのCレベルの幹部の心には何がありますか？本当に、「データ資産をどのように活用すればいいのですか？」と誰もがビッグデータについて話している。誰もが、Hadoop、Spark、ビジネスの俊敏性を生み出し、新しい変革的なアプリケーションを開くのに役立つ次のコンピュータープラットフォームについて話している。新しい市場参入の機会。すべてのエグゼクティブは、「データ戦略とは何か、データイニシアチブとは何か、競合他社に遅れをとらないようにするにはどうすればよいのか、そして今後3年間この市場にいるのか」と考えています。これは、お客様と話しているとき、グローバルな顧客ベースと話しているときに見てください。これは、ご存知のように、かなり長いです。

これらすべての組織と話をするとき、Hadoopで起こった混乱のテクノロジースタックでもこれを見ています。資産としてのデータに関するこの要求を満たすためです。組織が持つすべてのデータ資産を活用します。また、エンタープライズデータウェアハウスアーキテクチャが進化し、Hadoopが現在のデータアーキテクチャの新しい中心的存在であることがわかりました。そして、ほとんどのお客様は、それが金融サービスであろうと、保険であろうと、小売業の電話会社であろうと、イニシアチブは通常、サービスとしてのHadoopまたはサービスとしてのデータです。誰もが外部クライアントまたは内部クライアントのいずれかでデータ資産を利用可能にしようとしているからです。また、一部の組織では、顧客にとってほとんどデータマーケットプレイスのようなイニシアチブを見ています。

そして、それを達成するための最初のステップの1つは、すべてエンタープライズデータハブを作成することです。時々、人々はそれをデータ湖と呼びます。このエンタープライズデータハブの作成は、実際にはエンタープライズ内のほぼすべてのデータにアクセスして収集する必要があるため、思ったほど簡単ではありません。また、そのデータは、モバイルセンサーやレガシーデータベースなどのすべての新しいソースからのものであり、バッチモードとストリーミングモードになっています。データ統合は常に課題でしたが、データソースの数と多様性、さまざまな配信スタイル、バッチであろうとリアルタイムのストリーミングであろうと、5年前、10年前と比較してさらに困難になっています。私たちは時々、「もうあなたの父親のETLではない」と言います。

そこで、さまざまなデータ資産について説明します。企業は、自動車メーカーのセンサーであれ、モバイルゲーム会社のユーザーデータであれ、モバイルデバイスから収集した新しいデータを理解しようとしているため、多くの場合、最も重要なデータ資産を参照する必要があります。顧客情報などの企業。これらの最も重要なデータ資産は、多くの場合メインフレームに存在します。メインフレームデータをこれらの新しいソースと関連付け、クラウドで収集、モバイルで収集、日本の自動車会社の製造ライン、またはモノのインターネットアプリケーションで収集し、レガシーデータセットを参照してこの新しいデータを理解する必要があります。そして、これらのレガシーデータセットは、多くの場合メインフレーム上にあります。

そして、これらの企業がそれを行うことができず、メインフレームのデータを活用できない場合、チャンスを逃します。そして、サービスとしてのデータ、またはすべてのエンタープライズデータを活用することは、実際には組織内の最も重要な資産を活用していません。ほぼすべてのトランザクションデータがメインフレーム上に存在するため、テレメトリとセキュリティデータの部分もあります。

ATMに行くと想像してください。取引データがほぼグローバルにメインフレーム上にあるというカードをスワイプしているときに、出席者の1人が銀行システムを保護するためにここの参加者にメッセージを送信したと思います。そして、メインフレームからセキュリティデータとテレメトリデータを保護および収集し、それらをSplunkダッシュボードまたは他のSpark、SQLで利用できるようにすることは、データの量とデータの多様性により、今まで以上に重要になっています。

スキルセットは最大の課題の1つです。一方で、ビッグデータスタックが急速に変化するため、どのプロジェクトが生き残るか、どのプロジェクトが生き残るかがわからないため、HiveまたはPig開発者を雇う必要がありますか？ MapReduceまたはSparkに投資する必要がありますか？または、次のこと、Flink、誰かが言った。これらのコンピュータープラットフォームのいずれかに投資する必要がありますか？一方では、急速に変化するエコシステムに対応することが課題であり、他方では、これらのレガシーデータソースがあります。新しいスキルセットは実際には一致せず、これらのリソースが実際に廃止される可能性があるため、問題が発生する可能性があります。これらのレガシーデータスタックを理解し、新しいテクノロジースタックを理解している人々のスキルセットに関しては、大きなギャップがあります。

2番目の課題はガバナンスです。プラットフォームを越えてすべてのエンタープライズデータに実際にアクセスしているとき、「自分のデータが上陸したくない。可能な限り複数のコピーを避けたいので、データを複数の場所にコピーしたくありません。このデータを管理することは課題になります。もう1つは、ボトルネックのデータにアクセスする場合、クラウドでほとんどのデータを収集し、レガシーデータにアクセスして参照する場合、ネットワーク帯域幅が問題、クラスタープラットフォームになるということです。このビッグデータイニシアチブと高度な分析プラットフォームを持ちながら、すべてのエンタープライズデータを活用するという点では、多くの課題があります。

Syncsortが提供するものは、単に最高だからではなく、「単に最高」と呼ばれますが、顧客はメインフレームデータへのアクセスと統合で単に最高と呼んでいます。メインフレームのすべてのデータ形式をサポートし、ビッグデータ分析に使用できるようにします。 Hadoop、Spark、または次のコンピュータープラットフォームのいずれであっても。私たちの製品はコンピュータプラットフォームの複雑さを本当に絶縁しているからです。開発者は、潜在的にラップトップで開発し、データパイプラインとデータ準備、分析用にこのデータを作成する手順、次のフェーズに焦点を合わせ、MapReduceで同じアプリケーションを使用するか、 Sparkでの同じアプリケーション。

YARNが利用可能になり、MapReduceバージョン1からYARNにアプリケーションを移動する必要が生じたときに、それを行うお客様を支援しました。 Apache Sparkでも同じことができるように支援しています。私たちの製品である新しいリリース9は、Sparkでも実行されており、将来のコンピューターフレームワークのためにこれらのアプリケーションを隔離する動的最適化を備えています。

そのため、VSAMファイル、DB2、Splunkダッシュボードで視覚化する必要があるSMFレコード、Log4j、syslogなどのテレメトリデータなど、メインフレームデータにアクセスできます。また、その一方で、組織は既存のデータエンジニアまたはETLスキルセットを活用できるため、開発時間が大幅に短縮されます。実際、DellとClouderaには、スポンサー付きの独立したベンチマークがあり、そのベンチマークは、手動コーディングやSyncsortなどの他のツールを使用している場合にかかる開発時間に焦点を当てており、開発時間は約60、70％短縮されました。スキルをつなぐと、グループ間、それらのデータファイルホスト間、さらにはデータファイルホスト間で、人の観点からギャップが生じます。

通常、ビッグデータチーム、データ取り込みチーム、またはこのデータをサービスアーキテクチャとして開発するタスクを担当するチームは、必ずしもメインフレームチームと話をする必要はありません。彼らは、ほとんどの組織でその相互作用を最小限に抑えたいと考えています。そのギャップを埋めることで、前進しました。そして最も重要な部分は、プロセス全体を本当に保護することです。企業では、この種の機密データを扱う場合、多くの要件があるためです。

保険や銀行などの規制の厳しい業界では、お客様から「このメインフレームのデータアクセスを提供しています。これは素晴らしいことです。 HadoopとApache Sparkがメインフレームデータを理解できるようにするため、このEBCDICでエンコードされたレコード形式を元の形式のままにして、監査要件を満たすことができますか？データを元のレコード形式で保持し、処理およびレベルディストリビューターのコンピュータープラットフォームを実行することができます。それを戻す必要がある場合は、レコードが変更されておらず、レコード形式が変更されていないことを示すことができ、規制要件を遵守できます。

また、ほとんどの組織は、データハブまたはデータレイクを作成しているため、1回のクリックでこれを実行して、Oracleデータベースの数百のスキーマのメタデータをHiveテーブルまたはORCまたはParquetファイルにマッピングできるようにしています。必要になります。ツールを出荷し、これをワンステップのデータアクセス、自動生成ジョブまたはデータ移動、およびデータ生成のための自動生成ジョブにするツールを提供しています。

接続性の部分、コンプライアンス、ガバナンス、データ処理について話しました。そして、当社の製品はオンプレミスとクラウドの両方で利用できます。パブリッククラウドとハイブリッドの両方で完全に移行することを決めた場合、企業は来年または2年に何が起こるかを考える必要がないため、非常に簡単です。一部のクラスターはオンプレミスまたはクラウドで実行されている可能性があるため、環境。また、当社の製品は、Amazon Marketplace、EC2、Elastic MapReduce、Dockerコンテナの両方で利用できます。

簡単にまとめると、Q&Aに十分な時間があるので、データガバナンスにアクセスし、統合し、それを順守することでありながら、このすべてを単純化しています。そして、この製品をHadoopデータフローでネイティブに実行し、Sparkでネイティブに実行するオープンソースの貢献により、このシンプルな「一度設計してどこにでも展開」できるようになり、急速に変化するエコシステムから組織を隔離します。また、バッチとストリーミングの両方に対して、単一のデータパイプライン、単一のインターフェイスを提供します。

また、これは組織がこれらのフレームワークを評価することもあります。実際にアプリケーションを作成し、MapReduceとSparkで実行して、自分で確認したい場合があります。はい、Sparkはこの約束を持ち、最良の機械学習のための反復アルゴリズムのすべての進歩を提供しますおよび予測分析アプリケーションはSparkと連携しますが、このコンピューターフレームワークでストリーミングおよびバッチワークロードを実行することもできますか？当社の製品を使用して、さまざまなコンピュータープラットフォームをテストできます。そして、スタンドアロンサーバー、ラップトップ、Google CloudとApache Sparkのどちらで実行するかにかかわらず、動的最適化はお客様にとって大きな価値のある提案です。そして、それは彼らが抱えていた課題によって本当に推進されました。

ケーススタディの1つを取り上げます。これはガーディアン生命保険会社です。また、Guardianのイニシアチブは、データ資産を一元化し、クライアントが利用できるようにし、データ準備時間を短縮することでした。そして、データ処理パイプライン全体の80％を占めるデータ準備について、誰もが話していると言いました。彼らは75〜80％であり、分析プロジェクトのデータ準備、変換時間、市場投入までの時間を短縮したいと考えていました。新しいデータソースを追加するときに、その俊敏性を作成します。そして、すべてのクライアントが集中データアクセスを利用できるようにします。

Syncsort製品を含む彼らのソリューションは、基本的にはHadoopであるデータレイクとNoSQLデータベースによってサポートされるAmazon Marketplaceのようなデータマーケットプレイスを持っています。また、当社の製品を使用して、メインフレーム上のVSAMファイルを含むメインフレーム上のDB2、データベースレガシーデータソース、および新しいデータソースなど、すべてのデータ資産をデータレイクに持ち込みます。そしてその結果として、彼らはクライアントが検索、アクセス、利用できる再利用可能なデータ資産を一元化しました。そして、彼らは本当に新しいデータソースを追加し、以前よりもはるかに迅速かつ効率的にクライアントにサービスを提供することができます。また、分析イニシアチブは、予測側でもさらに進歩しています。したがって、一時停止します。これが役に立つことを願っています。関連するトピックについて質問がある場合は、大歓迎です。

エリック・カバナ：確かに、テンデュ、私はただ1つを投げるだけです。「私はこのデザインが好きで、どこにでも展開できます」と言った観客からコメントがありました。つまり、そのような俊敏性を実現するために何をしたのですか。税金はかかりますか？たとえば、仮想化について話すときのように、パフォーマンスには常に多少の負担がかかります。 2％、5％、10％と言う人もいます。一度デザインを有効にし、どこにでも展開するために行ったこと-どうやってそれを行い、パフォーマンスの点でそれに関連する税金がありますか？

TendüYogurtçu：もちろん、ありがとう。いいえ。他のベンダーの一部とは異なり、Hive、Pig、またはエンジンにネイティブではない他のコードを実際には生成しないためです。これは、Hadoopベンダー、Cloudera、Hortonworks、MapRと非常に緊密に連携しており、オープンソースの貢献により、実際にエンジンがフローの一部としてネイティブに実行されているため、オープンソースの貢献が大きな役割を果たした場所です、Hadoopフローの一部として、Sparkの一部として。

それが翻訳するもの、この動的最適化もあります。これは、お客様がコンピューターフレームワークに挑戦している結果として生まれたものです。一部のアプリケーションで本番環境に移行すると、彼らは戻ってきました。次のこと、そして一部の人々はFlinkが次のものになると言っています。どうすればこれに対処できますか？」

そして、これらの課題は本当に明白になりました。インテリジェントな実行と呼ばれるこの動的な最適化に投資しました。実行時、ジョブ、このデータパイプラインが送信されるとき、クラスターに基づいて、Sparkか、MapReduceかLinuxスタンドアロンサーバーか、その一部として、エンジンでネイティブにこのジョブを実行する方法を決定しますHadoopまたはSparkデータフロー。すべてがこの動的な最適化によって行われるため、オーバーヘッドはありません。また、オープンソースの貢献によりエンジンがネイティブに統合されているため、すべてが行われます。それはあなたの質問に答えますか？

エリック・カバナ：うん、いいよ。そして、もう1つ質問を投げかけたいと思います。そして、Dez、多分私たちもあなたとRobinを引き込みます。参加者の一人から陽気なコメントをもらいました。それは本当に非常に簡潔なので、私はそれを読みます。彼は、「物事の歴史上、HOT」と思われます-それを手に入れますか？IoTのように-「本当に複雑なものを「単純化」しようとすればするほど、物事を行うのが簡単に見えるよりも、より多くの吊りロープが提供されます。データベースクエリ、爆発、マルチスレッドなどを考えてください。」彼が参照しているこのパラドックスについて、コメントしてください。単純さvs複雑さ、そして基本的にカバーの下で実際に何が起こっているのでしょうか？

TendüYogurtçu：もちろん。それは非常に有効なポイントだと思います。物事を単純化してこれらの最適化を行う場合、隠れた方法で、誰かがその複雑さを実現する必要がありますよね？何かを麻痺させている場合、またはコンピューターフレームワークに関して特定のジョブを実行する方法を決定している場合は、ユーザーエンド、メニューコーディング、またはエンジン最適化であるかどうかに関係なく、プッシュされているジョブの一部があることは明らかです。その一部があります。ユーザーエクスペリエンスを簡素化することで、企業に存在するスキルセットを活用できるという点で大きなメリットがあります。

そして、そのパラドックスを緩和し、「ええ、でも、エンジンの下に隠れているすべてを制御することはできません」という課題を軽減することができます。そのような制御が必要です。いくつかの保守性タイプにも投資することにより。この出席者が与えた例のように、SQLクエリおよび実行中のエンジンに対して、より多くの運用メタデータ、より多くの運用データを提供できること。私はそれが答えを願っています。

エリック・カバナ：うん、いいね。デズ、それを奪って。

Dez Blanchfield：オープンソースの貢献におけるフットプリントと、メインフレームとプロプライエタリの世界での伝統的な長期の経験から得た旅について、もう少し洞察を得たいと思っています。オープンソースへの貢献とその方法。そして、私が理解したいもう1つのことは、IT部門だけでなく、ビジネスがデータハブやデータレイクに関して今人々が言っているので、ビジネスがこの傾向を見るかどうかについてあなたが見ている見方です単一の統合されたデータレイクだけですか、それとも分散データレイクがあり、人々がツールを使用してそれらをまとめるのですか？

TendüYogurtçu：もちろん。最初のものは、IBMに続く最初のものの1つである所有者ソフトウェア会社としての非常に興味深い旅でした。しかし、繰り返しになりますが、すべては伝道者のお客様がHadoopを見るところから始まりました。 ComScoreのようなデータ企業がありました。彼らは世界中でデジタルデータを収集していたため、Hadoopを採用した最初の企業の1つで、1, 000万ドルのデータウェアハウスボックスを投資しない限り90日間のデータを保持できませんでした環境。彼らはHadoopを見始めました。それに伴い、Hadoopも検討し始めました。

そして、Hadoopが本当に将来のデータプラットフォームになることを決定し、それを認めたとき、私たちはこれでプレーすること、これで成功するプレーをすることはできないという理解に至りました。エコシステムの一部でした。そして、Hadoopベンダー、Cloudera、Hortonworks、MapRなどと非常に緊密に連携していました。ベンダーがもたらす価値を検証するためにパートナーシップが非常に重要になり、共同で企業に行くこともできるので、本当に話し始めましたより意味のある何かを提供します。 Apacheオープンソースプロジェクトには知られていないため、多くの関係構築が必要でしたが、これらのHadoopベンダーからは多大なサポートを受けていたと言わざるを得ません。

私たちは一緒に仕事を始め、ハブを検討しました。私たちは、スペースに所有者のソフトウェアさえなくても価値をもたらす方法を探しました。それは重要でした。製品を実行できるAPIを配置するだけではありません。Hadoopは将来のプラットフォームになると考えているため、これに投資すると言うことができます。成熟し、エンタープライズ対応になります。実際に、貢献する前に利用できなかったいくつかのユースケースを有効にすることができます。それはエコシステム全体に利益をもたらし、私たちはそれらのパートナーシップを非常に密接に発展させることができます。

かなり時間がかかりました。 2011年と2013年1月21日に貢献を開始しました。最大の貢献がコミットされた日付を覚えています。これにより、その時点から製品を一般的に入手できるようになりました。、価値を示し、パートナーはオープンソースコミュニティのベンダーやコミッターとのデザインパートナーになります。しかし、それはとても楽しかったです。そのエコシステムに参加し、素晴らしいパートナーシップを築くことは、私たちにとって会社として非常にやりがいのあることでした。

データハブ/データレイクに関する2番目の質問です。ほとんどの場合、このデータをサービスの実装として見ると、はい、クラスター、物理的に単一または複数のクラスターであるかもしれませんが、単一の場所になるよりも概念的ですすべてのデータに対して。一部の組織では大規模なクラスター展開がオンプレミスで見られますが、オンラインセクションから収集されたデータの一部は実際にクラウドに保持されるため、パブリッククラウドなどにもクラスターがあります。これらの両方を実際に活用できる単一のデータパイプラインを持つことができ、それらを単一のデータハブ、単一のデータレイクとして使用することが重要になります。必ずしも物理的な場所だけでなく、クラスター間、地理的、場合によってはオンプレミスとクラウドにまたがるデータハブとデータレイクを持つことが非常に重要になると思います。特に前進。今年、より多くのクラウド展開が見られるようになりました。すごい。今年の前半は、これまで多くのクラウド展開を見てきました。

エリック・カバナ：オーケー、カッコイイ。ロビン、質問がありますか？あと数分で終わります。

Robin Bloor：わかりました、よく彼女に質問することができます。私が最初に思いついたのは、Kafkaについて多くの興奮があったことです。Kafkaについてのあなたの意見と、Kafkaの使用方法との統合方法に興味がありましたか？

TendüYogurtçu：もちろん。はい、カフカは非常に人気が高まっています。顧客の中では、データトランスポートレイヤーの一種であり、データはバスであると見ています。たとえば、顧客の1人が実際に、数千人のオンラインユーザーのように、このKafkaにプッシュされる一種の消費データを使用し、それを分類してプッシュスルーすることができました。

繰り返しになりますが、Kafkaはこのデータのさまざまな利用者へのデータバスです。一部の上級ユーザーとそれほど高度ではないユーザーを分類し、そのデータパイプラインで前進するために異なることを行います。 Kafkaとの統合方法は、基本的に、製品DMX-hが信頼できる消費者、Kafkaの非常に効率的で信頼できる消費者になることです。データを読み取ることができます。これは、他のデータソースからデータを読み取ることと同じです。私たちは、ユーザーが持っている時間要件またはKafkaバスから消費する可能性のあるメッセージの数のいずれかに関して、ウィンドウを制御する機能をユーザーに提供します。そして、製品を通過してKafkaにプッシュされるときに、そのデータを強化することもできます。これをテストしました。お客様のサイトでベンチマークを実施しました。 Confluentの認定も受けています。 Confluentのメンバーと緊密に連携しており、非常に高性能で使いやすいです。繰り返しになりますが、APIは変更されますが、製品はそれを別のデータソース、ストリーミングデータソースとして実際に処理するため、心配する必要はありません。実際、私たちの製品とカフカを使って作業するのはとても楽しいです。

Robin Bloor：さて、私は一般的なビジネスの質問のような別の質問がありますが、私は長い間Syncsortを知っていて、あなたは常に評判があり、ETLとメインフレームの世界に非常に高速なソフトウェアを提供しました。あなたのビジネスのほとんどが現在Hadoopに移管されているということですか？何らかの形で、メインフレームの世界からあなたのビジネスをかなり劇的に広めたということですか？

TendüYogurtçu：メインフレーム製品は、メインフレームの50％を世界中でまだ稼働しています。そのため、ビッグデータとHadoopの終わりで行っていることに加えて、非常に強力なメインフレーム製品ラインがあります。また、ビッグデータMultexプラットフォームのメインフレームデータを活用してすべてのエンタープライズデータを活用できるようにするための一端がありますが、非常に重要なトランザクションワークロードもあります。メインフレームで引き続き実行されます。これらのアプリケーションをより効率的にし、zIIPエンジンで実行して、処理サイクルとMIPSをあまり消費せず、費用対効果の高い方法をお客様に提供します。

メインフレーム製品への投資を継続し、実際にメインフレームのビッグアイロンからビッグデータに移行し、これらのプラットフォームでも製品ラインを広げるこの分野に実際に取り組んでいます。したがって、必ずしも事業全体を一方にシフトするわけではなく、両方の事業で非常に成功し続けています。そして、買収も私たちにとって大きな焦点です。ビッグデータプラットフォーム用のこのデータ管理およびデータ処理スペースが進化するにつれて、かなりの数の無料の買収も行っています。

ロビン・ブロア：まあ、私はあなたが私に話すことを許されないので、彼らが何であるかをあなたに尋ねることができないと思います。メインフレームで実際にHadoopまたはSparkの多くの実装を見たことがあるかどうか、またはそれが非常にまれなことかどうかに興味があります。

TendüYogurtçu：まだ見ていません。それについてさらに質問があります。メインフレームのHadoopは、コア構造の種類のためにあまり意味をなさないと思います。ただし、メインフレーム上のSparkは非常に意味があり、Sparkは機械学習と予測分析で非常に優れており、メインフレームデータを使用してこれらのアプリケーションのいくつかを実際に実行できることは、非常に意味があると思います。まだ誰もそれを見ていませんが、実際にこれらのことを推進するユースケースです。企業としてのユースケースがそのメインフレームデータをより多く持ち込み、ビッグデータプラットフォームの残りのデータセットと統合する場合、それは1つのストーリーです。ビッグデータMultexプラットフォームからメインフレームデータにアクセスする必要があります。これは、データセットをオープンシステムから持ち込んでメインフレームにコールバックする可能性が低いためです。ただし、調査したいメインフレームデータがあり、データ探索ディスカバリーを少し行い、高度なAIと高度な分析を適用する場合は、Sparkがメインフレーム上でそのように移動して実行する良い方法かもしれません。

エリック・カバナ：聴衆からの質問がもう1つあります。実際には2つです。タグチームの質問をお送りします。その後、まとめます。ある参加者は、「IBMはあなたのオープンソースの貢献をパブリッククラウドエコシステム、つまりBluemixに統合していますか？」と尋ねています。すでにそれを持っているが、企業が彼がCEと呼んでいるものを支持して新しいメインフレームを放棄すると、すべてがクラウド化され、おそらく低下するだろうが、あなたはオペレーティングシステムを毎秒ギガバイトまでバイパスすることでデータを移動するのが本当に上手であることを指摘する彼が述べたように、あなたのコアの強さについて、そしてIBMがあなたのものをBluemixに統合しているかどうかについて話していただけますか？

TendüYogurtçu： IBMとはすでにIBMとパートナー関係にあり、製品を提供するデータクラウドサービスについて話し合いました。私たちのオープンソースの貢献は、それらを活用したいすべての人に開かれています。メインフレーム接続の一部はSparkパッケージでも利用できるため、IBMだけではありません。誰でもそれらを活用できます。 Bluemixでは、まだ具体的には何もしていません。そして、あなたは2番目の質問を繰り返すことを気にしますか？

エリック・カバナ：ええ、2番目の質問は長年の機能の中核領域に関するものでした。それは実際にETLのボトルネックを処理していました。明らかに、それはあなたがまだメインフレームとしてやっていることですポイントは、まだ揺れ動いているようなものです。しかし、出席者は、Syncsortがオペレーティングシステムをバイパスし、1秒間に1ギガバイトまでデータを移動するのに非常に優れていることを指摘しました。それについてコメントしていただけますか？

TendüYogurtçu：はい、本当に全体的なリソース効率が私たちの強みであり、スケーラビリティとパフォーマンスが私たちの強みです。私たちは妥協せず、単純化には多くの意味があり、それらから妥協しません。たとえば、2014年に人々がHadoopについて話し始めたとき、多くの組織は最初は実際にパフォーマンスに注目していませんでした。彼らは、「ああ、何か問題が発生した場合、ノードをさらに2つ追加すれば問題ありませんが、パフォーマンスは私の要件ではありません」と言っていました。

既にネイティブで実行されているため、最高のパフォーマンスを得るという話をしていましたが、複数のMapReduceジョブでHiveが最初に発生した一時的な障害や、それらを開始するオーバーヘッドがありませんでした。「ああ、それは私の心配ではありません。現時点では心配しないでください。」

2015年になったとき、お客様の一部が既に実稼働クラスターのストレージを超えていたため、その状況は変わりました。 Syncsortが提供できるものを見ることが彼らにとって非常に重要になりました。データベースまたはメインフレームから一部のデータを取得してクラスター内のParquet形式に書き込む場合、着陸してステージングして別の変換を行うか、または機内変換および着陸したターゲットファイル形式を実行するかに関係なく、ストレージ、ネットワーク帯域幅の節約、追加のジョブを実行していないためクラスターのワークロードの節約になります。私たちが非常に意識的であるという点で果たすこれらの強みは、私たちの肌の下での資源効率を感じているようです。

それが私たちの説明です。それは私たちにとって重要です。私たちはそれを当たり前だとは思わない。私たちはそれを決して当たり前だとは思っていなかったので、Apache Sparkまたは次のコンピューターフレームワークでのレバレッジを引き続き活用していきます。それが引き続き焦点です。また、データ移動部分とデータアクセス部分に関しては、間違いなくそれが当社の強みの1つであり、HadoopまたはSparkのコンテキストでメインフレーム上のDB2またはVSAMデータにアクセスしています。

エリック・カバナ：まあ、それはウェブキャストを終わらせる素晴らしい方法です、皆さん。ご清聴ありがとうございました。 TendüとSyncsort、ブリーフィングルームに来てラウンドに参加してくれた彼らに感謝します。聴衆からのたくさんの素晴らしい質問。人々は絶えず動いている環境です。他のすべてと同様に、このホットテックをアーカイブします。 Insideanalysis.comおよびtechopedia.comで私たちを見つけることができます。通常、約1日で上がります。そしてそれで、私たちはあなたに別れを告げるつもりです、皆さん。どうもありがとうございます。すぐにお話しします。気を付けて。バイバイ。