Amazon Web Services ブログ

【開催報告】Amazon Analytics （Data Lake）セミナー ～AWSで実現するビッグデータ＆ログ分析およびデータレイクの構築～

2018年6月21日に、「Amazon Analytics （Data Lake）セミナー」というイベントが開催されました。本セミナーでは、ビッグデータの取り扱いとデータ分析を中心とした利活用、またデータレイクによる効率的なデータの運用を中心テーマにおき、AWS クラウド上での最適な実現方法について、AWS ソリューションアーキテクトおよび Amazon Redshift サービスチームからご紹介しました。また、データの可視化については Amazon QuickSight のデモをご覧いただき、あとでお客さまご自身で QuickSight をお試しいただけるよう、セッション終了後にデモのガイドとサンプルデータを配布しました。

この記事ではそのイベントの内容をご紹介します。また、最後に各発表資料へのリンクも掲載しています。

 

Data Lake on AWS

アマゾン ウェブ サービス ジャパン株式会社 志村 誠

このセッションでは、AWSが考えるデータレイク像について紹介しました。

データを活用することで、ビジネスにおける問題の把握、効果的な施策の実施、新しい知見の獲得などが可能になります。データ活用、とりわけビッグデータ活用においては、生のデータを収集し、処理・分析し、可視化するといった一連のプロセスを経てデータに対する深い理解を得られます。この一連のプロセスでの各フェーズにおいて、必要とされるツールやリソースがあります。例えば、データの取得と保存、加工整形処理をおこなうためのツールや可視化のためのBIツール、集計のためのSQL、ディープラーニングのフレームワークやHadoopクラスタ、Notebookなどの分析ツールがあります。ここに挙げたようなツールやモデルを利用する際には、CPUやGPU、メモリ、I/O、クラスタなどのリソースが必要となります。また、データ活用は試行錯誤を伴うものです。データ量や内容は変化しますし、ビジネス状況の変化に伴い成功指標も見直されます。この試行錯誤のサイクルをいかに高速に回せるかが良い結果を導くためには重要となってきます。

このようなデータ活用は、従来はリレーショナル・データベース(RDB)を利用して実施していました。RDBの利点は、スキーマが定義されている、データ型を強制できる、アクセスするためのツールが簡単、トランザクション単位で処理できる、などがあります。しかし、近年ではデータ活用基盤に入ってくるデータの量と質が変わってきています。量は従来とは比較にならないほど膨大になり、質もビジネスやITで発生するログだけではなくなり機械が吐き出すデータやメディアデータなども含まれるようになってきました。また、同様にデータを利用する側の質と量も変化してきています。こうした状況で、RDBの限界が露呈されつつあります。例えば、スケーラビリティに限界がある、非構造化データに対応しづらい、リアルタイム分析や機械学習など新しい分析要件への対応が困難、などです。これらの課題に対して、それぞれの分析要件に応じて利用するテクノロジを分けて構築するようなケースも出てきました。例えば非構造化データはHadoopを利用するなどの工夫をしてきました。ですが、これではスケーラビリティの問題は解決されませんし、どこにどのデータがあるのか分からなくなってしまうなどの問題もあります。また、分断された「サイロ」をまたがった分析は非常に困難です。

このような状況で、データレイクという考え方が注目されるようになってきました。データレイクの根本的な発想は、「どのような分析をおこないたいのかは事前に完璧に把握することはできない」というものです。そのため、データレイクでは、どんな要望が出てきても対処できるようにすべてのデータを生のフォーマットで安全に保存し、データ活用時に必要な構造で取り出す、という考え方を採用しています。データレイクは、未来の不確実性に対処するための術とも言えます。データレイクは、「データ」そのものと「RDB」や「Hadoop」など分析基盤の間に位置し、ビジネスやIT、機器などから発生するデータをそのまま蓄積します。そのことにより、ストレージと計算処理を分離することで独立してスケールでき最適化しやすい、データが一か所に集まることでどのデータを正とすればよいかはっきりと定義できる、データのIN/OUTが独立しているので様々な手法に対応でき拡張もスムーズ、といった利点が生まれます。データレイクの定義を述べるとすると、多様なデータを一か所に保存、保存したデータは失わない、サイズ制限からの解放、決められたAPIですぐにアクセス、システム全体のHUB、と言えます。

AWSのテクノロジを利用して、データレイクを容易かつ低コストで構築できます。中心となるのは高い耐久性と可用性を持つスケーラブルなオブジェクトストレージであるAmazon S3です。データ処理にはフルマネージド型のリアルタイム大規模ストリーミング処理が可能なAmazon Kinesisやフルマネージド型ETLサービスであるAWS Glueを利用します。計算・集計処理にはフルマネージドでスケーラブルなHadoopクラスタAmazon Elastic MapReduce (EMR) やスケーラブルで高速なデータウェアハウスであるAmazon Redshiftを用います。また、Amazon S3上のデータに直接クエリを発行できるAmazon Athenaもあります。データ分析には高速なエンジンを持ち直観的な操作が可能なBIツールAmazon QuickSightが利用できます。

これまでの内容をまとめますと、データレイクでは多様なデータを一か所に保存して集中的に管理し、すべてのデータを失わずに残し続けることが重要と言えます。また、計算・集計処理とストレージを分離することで、スケーラビリティを確保できます。そのうえで、やりたいことによって適切なツールを選択することが重要となります。

 

データウェアハウス on AWS

アマゾン ウェブ サービス ジャパン株式会社 大薗 純平

このセッションでは、AWSでのデータウェアハウス構築について紹介しました。

始めに、データウェアハウスの歴史と昨今のトレンドについて説明しました。データウェアハウスがデータの置き場・分析の場として最適と考えられ、データウェアハウス専用アプライアンス製品やHadoop技術がその要求を支えていました。背景として、データを一か所に集めて横断的に分析したい、管理対象のサーバーをなるべく減らしたい、データの重複を避けたい、データ同期を減らしたい、業務で利用しているデータベースと同じ技術・ソリューションで標準化したい、などのニーズがありました。しかし、データベース統合が進みモノリシックな環境になることで、データ増加や分析ニーズ増加に応えられない、バックアップやリストアなどの運用が困難、アップグレードが困難、技術革新への対応の遅れなどの課題も出てきました。

これらの課題を解決する方法として、データベースのマイクロサービス化が考えられています。モノリシックな環境で発生していた、変更に大きな負荷がかかる、スケールが難しい、不具合や障害の影響が大きいなどの課題も、マイクロサービス化することで独立性が高くスケールしやすくなり、不具合・障害の影響度を小さくすることができます。

最近の潮流として、モノリシックなデータベースを分割して適材適所な製品やサービスを活用する、という動きがあります。データベースを分割するには、分離して扱うことのできる境界を洗い出すことが重要です。境界の例としては、接続される業務アプリケーションやプロジェクトなどが考えられます。このような単位でデータベースを分割することで、統合により生じたデメリットを排除することが考えられています。例えばAWSの提供するサービスであれば、業務システムはAmazon Aurora、自由分析はAmazon Athena、BIのソースはAmazon Redshift、データレイクはAmazon S3、といったように各々の得意分野を活用してシステムを構築する方法が考えられます。

データウェアハウスに求められる性能特性としては、ヒストリカルなデータをすべて参照して集計、といったシーケンシャルな読み取りが主となります。そのため、大量のデータを俊敏に収集・集計・計算する能力が必要です。AWSでは、これらの能力を様々なサービスで提供しており、データ分析用途ではAmazon Redshift、Amazon EMR、Amazon Athenaが主要なサービスです。

Amazon RedshiftはオープンなデータベースであるPostgreSQLをベースとしており、並列処理や列指向などデータウェアハウスに特化した拡張をしています。アーキテクチャとしては、クライアントからの要求 (SQL) を受け付けるリーダーノードとSQL処理をおこなうコンピュートノードで構成されています。コンピュートノードでの並列処理やデータの列指向化により、非常に高速なデータ処理を実現できます。また、Amazon S3と密に連携しており、Amazon S3からのロードやアンロードが可能です。さらにRedshift Spectrumという機能によりAmazon S3上の膨大な量のデータをSQLで操作し分析のソースにできます。もう一つの大きな特長は、マネージドサービスであるという点です。例えばAmazon S3へのバックアップや障害からの復旧は自動的におこなわれます。リストア時には、データを戻しながらリストアするストリーミングリストアという方法によりダウンタイムを削減できます。また、Amazon Redshiftは継続的に進化を続けており、2013年2月のリリース以降125個の修正パッチを提供、165個の機能追加をおこなっています（2018年4月現在）。なお、パッチや機能追加を継続しているものの、後方互換性も重視しており、アプリケーションへの影響を最小限に抑えています。

データベースの移行プロジェクトでは、「スキーマやSQLなどアプリケーションの移行」と「データの移行」があります。アプリケーションの移行についてはAmazon Schema Conversion Tool (SCT)、データの移行についてはAmazon Database Migration Service (DMS)を活用して工数および期間を削減できます。

最後に、実際にAmazon Redshiftに移行された全日本空輸様の事例を紹介しました。全日本空輸様では、20年以上オンプレミスで運用してきた 1つのデータウェアハウスで運航実績、貨物輸送実績の分析をおこなってきましたが、データの増加など状況の変化に対して柔軟で俊敏な対応が困難になっていました。そこで業務を分析、区分けした上で、Amazon RedshiftやAmazon Auroraなど適材適所のサービスに分割して構築しました。こうすることで、従来よりも変化への対応力の高いシステムを構築することができました。

 

ログ分析 on AWS

アマゾン ウェブ サービス ジャパン株式会社 八木 達也

このセッションでは、蓄積され続けるログの長期保存と分析に関するベストプラクティスを紹介しました。

情報システムにおいてログは溜まり続けます。種類も非常に多く、ロードバランサのアクセスログやアプリケーション・サーバーのエラーログなど多岐に渡ります。このようなログを蓄積するためにストレージ容量を確保したいと思っても、「ログ管理にお金をかけるのはちょっと・・・」と前向きに検討されないケースも散見されます。また、ログデータはログを出力した元のシステムによってフォーマットがまったく異なります。フォーマットがまったく異なる各種データをどのように統一的な手法で分析するのか、その設計は簡単ではありません。さらに、ログデータをどのように活用するかという展望を持っていないケースも多いです。「分析できるのであればしてみたい」という大まかな要望はあるものの、今の時点でどのように活用できるのか解が見出せていない、という状況です。

これらの課題に対して、データレイクというソリューションは非常に相性が良いと言えます。データレイクはデータを生のままフォーマットを変えずに保存できるため、データをロードする際には何も考える必要はなく事前に定義・設計する必要はありません。また、クラウド上にデータレイクを構築すれば、ストレージは必要な時に必要な量だけを確保できるようになります。さらにクラウド上のストレージは非常に安価なので、今現在使い道が不明でもいったんストレージに溜めておく、ということもできます。

AWSであれば、Amazon S3を利用することでデータレイクを構築できます。Amazon S3は容量無制限、99.99999999%の耐久性、利用した分のみの課金、多くのAWSサービスと連携できるなど、様々な特長があります。また、Amazon Athenaを利用してAmazon S3上のデータに対してSQLでクエリを発行できます。Amazon AthenaはETLサービスであるAWS Glueとも統合されており、データレイクとしての価値をより高めることができます。Amazon Athenaを利用したログデータ分析は非常に容易です。手順は以下のとおりです：

  1. Amazon S3コンソールを開く
  2. バケットを作成する
  3. バケットにログファイルをアップロードする
  4. Amazon Athenaコンソールを開く
  5. データベースを作成しテーブルを定義する
  6. クエリをかける

このように非常に簡単にログ分析環境を構築でき、1GB程度のログであればトータルで数円程度です。ログが大きくなってテラバイト級になっても、同じアーキテクチャで対応できます。

また、ログをどのようにデータレイクに転送するかについて言及しました。方法としては、各サーバーからログファイルを転送、syslogエージェントなどを使用してログを集約、fluentdなどのミドルウェアの利用、AWSのマネージドサービスの利用などを挙げました。AWSのマネージドサービスであれば、Amazon Kinesis Data FirehoseやAmazon CloudWatch Logsがあります。特にAmazon Kinesis Data Firehoseはストリーミングデータを直接Amazon S3などにロードでき、さらに「使い方が分からないと言われたことがない」というほど学習コストが低いのが特長です。

最後に、実運用を見据えた基盤の考え方と、その中で利用できるAWSのサービスについて説明しました。ここではストリーミングデータのロードで利用できるAmazon Kinesis Data Firehose、ストリーミングデータ分析アプリケーションを構築できるAmazon Kinesis Data Streams、AWSの各リソースを監視するCloudWatch、Amazon S3、ETLサービスのAWS Glue、HadoopクラスタのAmazon EMR、Amazon Athena、Amazon Redshift、BIサービスのAmazon QuickSightを紹介しました。AWSであれば、上記のように用途に応じた様々なサービスを提供しているため、ブロックを積み上げていくように、ビルディング・ブロック・アーキテクチャという考え方でデータレイクを構築できます。

 

モダンなデータウェアハウスの作り方：Dive deep on Amazon Redshift

Amazon Web Services, Inc. Maor Kleider, Michalis Petropoulos

このセッションでは、Amazon Redshiftのサービス開発担当者からAmazon Redshiftについて詳細に解説しました。

まずはMaorから、Amazon Redshiftの全体的な概要や利用者が得られるベネフィットについて説明しました。

AWSは100以上のサービスを提供していますが、データを収集・蓄積・分析するサービスも充実しています。そのため、ストリーミングデータなどをAmazon S3に収集し、EMRで前処理し、Amazon Redshiftにロードしてさらに深い分析、など要件に合わせて様々な方法が考えられます。AWSではAmazon QuickSightというBIサービスも含めてクラウドで提供しています。また、AWS Database Migration Service (DMS)はターゲットがAmazon Redshiftであれば６ヶ月間無料で利用できます。

Amazon Redshiftは2013年にリリースしましたが、10倍のパフォーマンスを1/10のコストで実現することを目指しています。Amazon Redshiftの高速性の肝は、洗練されたオプティマイザ機能と列指向ストレージです。Amazon Redshiftの大きな特長として、簡単に使うことができるということが挙げられます。数クリックで本番用途のデータウェアハウスが構築できます。またコミットメントなしで1時間あたり0.25USDから小さく始めて、1テラバイトあたり250USDまで容易にスケールできます。例えばギガバイトレベルから始めてペタバイトまで成長させても同じアーキテクチャで運用できます。他のAWSサービスと組み合わせることも容易です。また、フルマネージドサービスなので、データウェアハウスの運用管理で必要となるタスクの多くは自動化されており、オンプレミスのデータウェアハウスにおける管理の煩雑さ、複雑さから解放されます。増え続けるデータに対しては、Redshift Spectrumという機能を提供しています。この機能により、Amazon S3上のエクサバイト規模に渡るデータにまで、Amazon Redshiftにあるデータと同じ扱いでクエリをかけられます。そのため、ツールやSQLを変える必要はありません。Redshift Spectrumを利用すれば、Amazon S3のデータをAmazon Redshiftにロードする必要はなく、Amazon S3に置いておけばすぐにクエリできます。

アーキテクチャについても簡単に説明しました。クライアントはリーダーノードにアクセスしてSQLを発行します。Redshift Spectrumはサーバレスな存在で、同機能によってストレージ層とコンピュート層を分離できています。データをAmazon S3に置くことで、Amazon AthenaやAWS Glueなど他のサービスからも同じデータを活用できるようになりました。日本のお客様も非常に多くAmazon Redshiftをご利用頂いています。NTT DOCOMO様や全日本空輸様などミッションクリティカルな領域で多くのお客様にご利用頂いておりますし、我々Amazon.comも利用しています。もちろんスタートアップを含むまだ規模が小さいお客様にも数多くご利用頂いています。例えば配車サービスを展開するスタートアップもAmazon Redshiftを利用しています。Amazon RedshiftはForresterの調査でもリーダーとして位置付けられており、実効性とビジョンが優れていると評価頂いております。これは、常にお客様のフィードバックを取り入れてサービス開発に取り組んでいることもご評価頂いているものと考えています。Amazon Redshiftはリリースしてからまだ5年程度しか経っていませんが、リーダーのポジションに位置付けられており、現在ではペタバイト級のデータを運用しているケースも増えてきています。Amazon Redshiftは19リージョンで利用可能、日本では東京・大阪 (DR用途) ともに利用可能です。

ここで、Amazon.comの事例について説明しました。Amazon.comはOracleの大規模ユーザーでしたが、2013年にAmazon Redshiftへの移行を決めました。主に顧客の行動分析で使っています。Oracleを使っていた頃は、1週間前までの行動分析に1時間かかっていました。その後構築したHadoopでは1か月分の行動分析に1時間かけていました。それをAmazon Redshiftに移行することで、15ヵ月分の行動分析を14分で分析できるようになりました。また、Prime Dayではユーザアクセスが急激に増加するため、クラスタをスケールアップさせて運用し、終わればスケールダウンする、といった運用もおこなっています。Oracleを利用していた頃、DBAはハードウェアの問題への対応やバックアップ、メンテナンスなどの作業に追われていましたが、Amazon Redshiftへの移行後はユーザーの課題対応や知見の提供など付加価値を提供するワークにシフトできるようになりました。

続いてMichalisから、最近リリースされた機能について紹介しました。

Amazon Redshiftのイノベーションがどうベネフィットにつながるかを理解して頂ければと考えています。ここ最近で一番力を入れていたのはパフォーマンスの改善です。その成果として、ご利用中のお客様でも効果が出ており、リバティミューチュアル社 (保険会社) では新しいインスタンスタイプにすることでパフォーマンスが2倍に、DNA社 (フィンランド電気通信事業者) でもパフォーマンスが2倍以上になりました。新しいインスタンスタイプDC2の新規リリースにより、DC1と同価格で2倍のパフォーマンスを実現しています。Amazon Redshiftは2年に1回ぐらいのペースでハードウェアを更新しています。AWSの場合、追加費用なしで新しく更新されたインスタンスタイプをご利用頂けますし、マイグレーションも非常に容易です。

また、さまざまな新機能もリリースしています。

まず、Short Query Acceleration (SQA) という機能です。これはクエリの優先度をソフトウェアが自動で検知して対応するもので、SQAリリース後はキューの待ち時間によるスパイクがなくなり、ショートクエリのパフォーマンスが劇的に改善しています。Amazon Redshift側で機械学習のテクノロジを活用して、どのクエリがショートクエリか、またはショートクエリではないのかを判別しリソースを割り当てています。この機能はすでにリリースしていますが、今後2～３週間のアップデートによりデフォルトで有効になる予定です。少ないリソースでクイックにショートクエリを終わらせて、大きなクエリに迅速にリソースを割り当てるのがこの機能の肝です。

次はリザルト・キャッシュという機能です。クエリのスループット全体を向上させるための機能で、クエリの結果セットをリーダーノードにもつため、同様のクエリを発行したときのレスポンスが非常に高速になります。この機能はすでにリリース済みで、お客様にとっては非常にメリットが大きいと考えており、実際にすべてのAmazon Redshiftクラスタをベースに考えた場合、平均してクエリの処理量は35％増加しています。すべてのAmazon Redshiftクラスタで、クエリ処理量が35%増加しています。これは、同じクエリにかけていたリソースを他のクエリに割くことができるようになったためです。この機能を利用するにあたり、お客様側での事前設定は一切不要です。

また、コミット処理のパフォーマンスも向上しています。従来、更新処理は夜間バッチのみということが多かったのですが、最近では日中に更新処理をおこなうケースが多くなってきています。そのため、書き込み処理のパフォーマンスも重要になってきました。2017年11月時点のデータと比較すると、Commitのパフォーマンスが2倍向上しています。データ取り込みおよび挿入も16%程度高速化されています。

クエリのパフォーマンスも向上しています。ハッシュ結合の高速化により、TPC-HやTPC-DSなど結合を多用するワークロードでは、さまざまなクエリで約28%から2倍のパフォーマンス向上が得られました。ハッシュ結合では大量のメモリを使いますが、使用メモリ量を1/64にできたため他の処理のパフォーマンスが向上しています。

クエリモニタリング・ルールによって、重いクエリのキャンセルなどクエリ実行の制御が可能になりました。WLM (ワークロード管理機能） でホッピングさせることもできます。

Redshift Spectrumにもアップデートがあります。まず、14のリージョンで利用可能になりました。今後Redshiftが稼働する全リージョンで使えるようになる予定です。さらに、スカラーJSONやIONのサポート、DATEデータ型のサポート、COPYコマンドでのParquetやORCなどがサポートされるようになりました。

今後リリースする予定の機能についても少しお話します。

まず、ネストされたデータをサポートする予定です（※2018.8.8 正式にサポートを発表。詳細はこちら）。Parquet, ORCやJSONなどネストされたデータはこれまで活用前にノーマライズする必要がありましたが、今後はノーマライズする必要はなくなり直接クエリをかけられるようになります。これにより、前処理の負荷を削減できます。

また、さまざまな自己修復機能を拡張する予定です。機械学習を活用して性能低下しそうなコンポーネントを予測、修復する、というものです。

 

サーバレスのBI環境 Amazon QuickSight ご説明と持ち帰り可能デモ

アマゾン ウェブ サービス ジャパン株式会社 下佐粉 昭

このセッションでは、AWSが提供するBIサービスAmazon QuickSightについて紹介しました。

Amazon QuickSightはサーバレスのBIサービスです。よくある話として、BIは使っていくとどんどんユーザーが増えていく、と聞きますが、サーバレスでフルマネージドサービスなのでスケールは自動でやってくれます。また、Amazon S3やAmazon Athena、Amazon Redshiftと連携してすぐに分析を始められます。もちろん、AWS以外のデータソースにも接続できます。Amazon QuickSightは誰にでも使えて、多くの人のニーズを満たすBIサービスを目指しています。例えば自由分析やレポート作成、ダッシュボードの利用など、様々なニーズを満たすことができます。なお、Amazon QuickSightは5/31にライセンス体系を更新し、「Readers Pricing」という“見るだけユーザー向けのライセンス”を追加しました。ちなみに、見るだけとはいっても軸の変更やフィルタリングはできます。具体的な価格としては、セッション(30分)あたり$0.3、100ユーザーにアクセス権限を与えても使った人の分だけの課金、上限は1ユーザーあたり$5/月まで、となっています。このライセンス体系により、より「BIの民主化」を推進できると考えています。

分析環境としては、ブラウザだけで利用できます。もちろんモバイルからも使えますし、iOSアプリもあります。サーバレス、フルマネージドサービスのため、セットアップやメンテナンス不要です。様々なデータソースへのアクセスが可能です。AWS上のデータベースやデータレイクなど、これまで紹介してきた様々なデータを利用できます。また、3rd Partyのアプリケーションへのアクセスが可能です。具体的には、Salesforce.comやAdobe Analyticsなどにアクセスできます。さらに、ExcelやCSV、SQL ServerやTeradataなどオンプレミスのデータへのアクセスも可能です。Amazon QuickSightはSPICEというインメモデータベースを持っており、データソースに負荷をかけずに分析することができます。SPICEを利用せず直接データソースにアクセスすることもできます。Amazon QuickSightも含め、これまで紹介してきたサーバレスのソリューションを組み合わせて分析環境を構築することができるようになりました。例えばETLサービスであるGlueにより登録されたデータをAmazon AthenaやAmazon EMR、Redshift Spectrumに放り込み、Amazon QuickSightで様々な軸で分析する、などの処理を迅速かつ柔軟に構築できます。

Amazon QuickSightはエンタープライズレベルでの利用を想定したBIサービスです。そのため、セキュリティ＆コンプライアンスやグローバル展開、可用性について高いレベルでの稼働を実現しています。ここでは、特にセキュリティとコンプライアンスについて説明します。

Enterprise Editionでは、プライベートVPC内のリソースへのアクセスを許可することができます。また、Direct Connect (DX)（専用線）経由でオンプレのデータソースにも接続できます。また、Enterprise EditionではAD連携も可能です。さらにSAML2.0を用いてFederated SSOにも対応できます。ガバナンスの観点では、管理者が適切な権限管理をすることで、利用者から見えるデータを制御でします。その際、データセット単位での制御や行レベルでの制御(Enterprise Edition)も可能です。監査とロギングについては、Amazon CloudTrailにより操作のガバナンスを確保できます。

すでに事例も多数あります。資源会社であるRio Tinto社では、これまでは採掘場の作業員や監督者に対して現場の安全情報などExcelのデータをメールで配信していましたが、最新情報が分からないなどの課題がありました。そこで、Amazon QuickSightによりデータソースに直接アクセスして、データをリアルタイムに取得可能にしました。現在300人以上のAmazon QuickSightユーザーがいますが、今後Readersライセンスを活用して5,000人以上に増やす予定です。

最後にデモを実施し、実際のAmazon QuickSightの使い勝手などをご覧頂きました。CSVデータをSPICEに取り込んで可視化するというデモで、列名の日本語対応や多彩なグラフでの表現、フィルタリングなどをご覧頂きました。

 

Amazon Redshift への移行を支えるAPNパートナー

アマゾン ウェブ サービス ジャパン株式会社 相澤 恵奏

このセッションでは、Amazon Redshiftへの移行を支援するAPNパートナー様を紹介しました。

現在AWS Partner Networkには、SIパートナーとして222社、ISVパートナーとして299社が登録されており、様々な要件に応じてバラエティ豊かなご支援を提供できます。また、Amazon Redshiftを扱うService Delivery Partner（SDP）としては、セミナー時点でNRI様、クラスメソッド様、CTC様、クラウドパック様、NEC様、システムサポート様、サーバーワークス様、ウルシステムズ様、ナレッジコミュニケーション様の9社が登録されており、POCから計画立案、設計、実装、テスト、運用など、様々な観点でのご支援を提供しております。

 

上記でご紹介した各セッションの資料は下記よりダウンロードいただけます（約17.6MB）
ダウンロードはこちらから>>

 

アマゾンウェブサービスジャパン　諏佐 嘉之

著者はデータベース、データウェアハウス専門の営業として、日々お客様のデータベース環境のクラウド化を御支援する活動をしています。またAWS内にはデータベースを専門とするエンジニアがお客様の技術支援を行っています。データベース、DWHをクラウド上で構築したい、移行したいというお考えのお客様はぜひお気軽に、こちらまでご連絡ください。