Amazon Web Services ブログ

Category: Analytics

Amazon Athena を使用したクロスアカウントの AWS Glue データカタログ

多くの AWS のお客様は、複数アカウント戦略を用いています。一元化された AWS Glue データカタログは、異なるアカウント間におけるメタデータの共有に関連する管理の量を最小化するために重要です。この投稿では、Amazon Athena が異なる AWS アカウント間で一元化されたデータカタログをクエリすることを可能にする機能を紹介します。 ソリューションの概要 2019 年後半、AWS は、Amazon Athena を Apache Hive Metastore に接続する機能を導入しました。この機能により、別のアカウントのデータカタログをポイントするように Athena を設定することもできます。Hive Metastore 機能は、AWS Lambda 関数を使用して、選択したデータカタログにクエリをフェデレーションします。この同じ機能で、カタログクエリを別のアカウントのデータカタログにプロキシできます。 次の図は、2 つの異なるアカウントで使用される必要なコンポーネントと、Athena を使用したクロスアカウントの Glue データカタログアクセスのためのアカウント間のフローを示しています。 このチュートリアルでは、Athena クエリを実行するのと同じアカウント (アカウント B) で Lambda 関数を作成します。リソースポリシーを使用して Lambda 関数にクロスアカウントアクセスを許可します。これにより、アカウント B の関数がアカウント A のデータカタログをクエリできます。アカウント B のユーザーは、テーブルがポイントし、Lambda 関数を実行するためのアクセス権を有する Amazon S3 リソースへのアクセス権を持っている必要があります。Lambda 関数の実装の詳細は、Github リポジトリを参照してください。 この投稿では、Lambda 関数およびその関数の読み取り専用 IAM […]

Read More

FactSet が Amazon DynamoDB から Amazon S3 Parquet へのデータのエクスポートを自動化して、データ分析プラットフォームを構築する方法

この記事は、FactSet のリードソフトウェアエンジニアである Arvind Godbole と AWS プリンシパルソリューションアーキテクトの Tarik Makota によるゲスト投稿です。「FactSet は、世界中の何万人もの投資専門家向けの柔軟でオープンなデータとソフトウェアソリューションを作成し、投資家が重要な決定を下すために使用する金融データと分析に即座にアクセスできるようにします。FactSet では、製品が提供する価値を常に向上するために取り組んでいます」 私たちが検討してきた分野の 1 つは、クライアントの検索結果の関連性です。さまざまなクライアントの使用例と 1 日あたりの検索回数が多いため、匿名化された使用データを保存し、そのデータを分析してカスタムスコアリングアルゴリズムを使用して、結果を高めることができるプラットフォームが必要でした。計算をホストするために Amazon EMR を使用するのは明らかな選択肢でしたが、匿名化されたデータを Amazon EMR が使用できる形式に変える方法について疑問が生じました。そこで私たちは AWS と協力し、Amazon DynamoDB を使用して Amazon EMR で使用するデータを準備することにしました。 この記事では、FactSet が DynamoDB テーブルからデータを取得し、そのデータを Apache Parquet に変換する方法について説明します。Amazon S3 に Parquet ファイルを保存して、Amazon EMR でほぼリアルタイムの分析を可能にします。途中で、データ型変換に関連する課題に直面しました。これらの課題をどのように克服できたかについて説明しようと思います。 ワークフローの概要 ワークフローには次の手順が含まれています。 匿名化されたログデータは DynamoDB テーブルに保存されます。これらのエントリには、ログの生成方法に応じて異なるフィールドがあります。テーブルに項目を作成するたびに、DynamoDB ストリームを使用してレコードを書き出します。ストリームレコードには、DynamoDB テーブルの単一項目からの情報が含まれます。 AWS Lambda 関数は DynamoDB ストリームにフックされ、DynamoDB […]

Read More

Amazon QuickSight: 2019 年の振り返り

2019 年は、Amazon QuickSight にとって刺激的な年でした数千社におよぶお客様をオンボーディングし、グローバルに 10 箇所の AWS リージョンに拡張し、60 以上の機能 (各週間に 1 つ以上の機能) をリリースしました お客様や Amazon QuickSight で実施する全てのことに活気づけられています。面談、電話会議、メール、ディスカッションフォーラム、そして AWS サミットを通して、皆様と時間を共にできたことを感謝いたします。今年の締めくくりとして、ハイライトの概要を簡単に紹介いたします。 re:Invent 2019 Amazon QuickSight チームは、 re:Invent で Best Western、Capital One、Club OS などのお客様といっしょに行った、分析ニーズの実装や Amazon QuickSight の使用に関する体験について語りました。また、新しくリリースされた API を使った 2 つの実践的なワークショップを実施しました。 ANT324:Amazon QuickSight を使用して、企業規模でビジネス分析を展開する このセッションでは、企業がすべてのユーザー向けに Amazon QuickSight Enterprise Edition を展開し、 Active Directory 、Federated SSO (SAML/OpenID Connect) 認証、AWSのデータへのプライベート 接続性、E […]

Read More

患者記録を AWS Lake Formation FindMatches 変換と一致させる

患者のマッチングは、医療の相互運用性を実現する上で大きな障害です。患者レコードの不一致や患者の履歴の取得ができないと、十分な情報に基づいた臨床上の意思決定に大きな支障が生じ、診断ミスや治療の遅れを招く可能性があります。さらに、医療従事者は、患者データの重複排除にお金をかけることがよくあります。データベースで患者レコードの数が急速に増加している場合は特にそうです。電子医療記録 (EHR) により、患者の安全とケアの手配は近年大幅に改善しましたが、多くの医療機関は、患者の正確なマッチングの課題に未だに頭を抱えています。 患者レコードの重複は、人為的な番号の挿入、削除、置換、または置き間違えなど、さまざまな理由で発生します。患者レコードをデジタル化する光学式文字認識 (OCR) ソフトウェアもエラーを引き起こす可能性があります。 この問題を解決するために、複数のタイプのレコード一致アルゴリズムが存在します。これらのアルゴリズムには、関連フィールド (SSN、名前、生年月日など) 、音声符号化システムをグループ化して比較するといった基本的な決定論的方法に加えて、機械学習 (ML) を使用したより高度なアルゴリズムも含まれます。 AWS Lake Formation は、いくつかの簡単な手順を踏むだけで安全なデータレイクを構築できる HIPAA 対象サービスです。Lake Formation には FindMatches も含まれていて、さまざまなデータセットにわたってレコードを一致させたり、重複レコードを特定して削除したりできます。 この記事では、FindMatches ML 変換を使用して、合成的に生成されたデータセット内で一致する患者レコードを識別する方法を説明します。FindMatches を使用するのに、コードを書く必要も ML の仕組みを知っている必要もありません。これは、フィールドが完全に一致しない場合でも、信頼できる一意の個人識別子が含まれていない場合に、データ内で一致を見つけるのに役立ちます。 患者データセット 患者データは、その機密性により、さまざまな国のさまざまな規制を受けています。そのため、マッチングアルゴリズムをトレーニングする患者データが不足していることが多く、モデル開発が複雑になります。このような課題を回避するためによく用いられているのは、合成データを使う方法です。この記事では、オープンソースの Freely Extensible Biomedical Record Linkage Program (FEBRL) に基づいて患者データを生成します。FEBRL は、隠れマルコフモデル (HMM) を使用して、患者レコードの一致を調べるために名前と住所のデータを用意します。また、重複につながる実際の患者データセットを模倣することもできますが、これには以下の不一致が生まれる可能性があります。 空白のフィールド。 スペルミス、文字の転置、記入欄の取り違えなどの誤植。 ミドルネームの短縮形がある一方、ミドルネームを略さずに記述したレコードもある。 さまざまな形式の住所と詳細。 OCR 関連のエラー。 音声エラー。 グローバルに一意の患者または個人の識別子なし。医療従事者はどこも、その人に割り当てられた患者識別子を持っているかもしれませんが、SSN のような人の識別子を持っていない可能性もあります。そのため、キーのないデータセットを持っています。 FEBRL は、設定可能なパラメータに基づいてこれらのタイプのデータセットを生成して、各タイプのエラーの確率を変更できるため、重複に至るさまざまなシナリオを組み込むことができます。合成データセットの生成については、この記事の範囲外です。この記事では、事前に生成されたデータセットについて説明します。FindMatches の実行に使用する合成データセットを生成する手順は、簡単に説明すると次のとおりです。 FEBRL をダウンロードしてインストールします。 パラメータを変更して、期待どおりのデータセットを作成します。詳細については、FEBRL […]

Read More

UltraWarm for Amazon Elasticsearch Service を使用して少ないコストでより多くのデータを維持する

機械によって生成されたデータは、ソリューションを強化すると共に問題も引き起こします。これは今日の最新ソフトウェアアプリケーションで運用上の問題を特定するために必要不可欠ですが、それをリアルタイムで分析するには Amazon Elasticsearch Service のような柔軟でスケーラブルなツールが必要です。このログデータは極めて貴重であるため、ホットストレージから削除したくはないのですが、大量にありすぎるので削除するしかありません。ログ分析には、潜在的な価値と実費をてんびんにかけるという本質的な葛藤があります。 過去数日間からのログに価値があることは分かっています。最高のインデックスおよび検索パフォーマンスを提供するホットストレージに料金を支払うことは道理にかないます。6 週間前、または数か月前からのログには価値が出る可能性もありますが、これからどのくらいで価値が出るのでしょうか? その一方で、それらをホットストレージに維持するコストは正当化できるのでしょうか? Amazon Elasticsearch Service の新しいストレージ階層である UltraWarm は、この葛藤を取り除き、ホットストレージと比較してデータ保持期間を劇的に延長し、コストを最大 90% 削減することを可能にします。何よりも素晴らしいのは、インタラクティブな分析経験はそのまま変わらないところです。ウォームインデックスは、他のインデックスと同様にクエリしたり、それらを使用して Kibana ダッシュボードを構築したりします。 仕組み 従来のウォームストレージソリューションには制限がありました。オープンソースの Elasticsearch クラスターは高密度ストレージの D2 インスタンスを使用することができますが、これらのノードを追加しても同じ基本的な Elasticsearch アーキテクチャが維持されます。引き続きオペレーティングシステムオーバーヘッド、ディスクウォーターマーク、およびインデックスレプリカを考慮しなくてはなりません。使用分だけを支払うのではなく、プロビジョニングした分の料金を支払い続けます。 UltraWarm は違います。これは、Amazon S3 と AWS Nitro System 駆動のノードの組み合わせを使用して、集約と可視化にホットストレージのような経験を提供します。S3 は耐久性に優れた低コストのストレージを提供し、レプリカの必要性を排除します。S3 はまた、オーバーヘッドという概念を取り去るので、各 UltraWarm ノードは利用可能なストレージを 100% 使用することができます。これらのノードには、クエリ処理最適化、およびデータをプリフェッチする高度なキャッシングソリューションが含まれています。従来のウォームストレージソリューションと比較して、UltraWarm のパフォーマンスは通常それらと同様、またはそれらより優れています。 具体的な料金例について、3 つのultrawarm1.large ノードを検討しましょう。すべてのノードと同様に、各ノードには時間レートの料金を支払います。今回の場合のレートは 2.680 USD です。これらのノードを合わせると、毎月 GiB あたり 0.024 USD で最大 60 TiB の […]

Read More

Amazon Redshift の新機能 – データレイクエクスポートとフェデレーテッドクエリー

データウェアハウスは、トランザクション系システムや業務アプリケーションから届いたリレーショナルデータの分析に最適化されたデータベースです。Amazon Redshiftは高速でフルマネージドのデータウェアハウスであり、標準SQLや既存のビジネスインテリジェンス(BI)ツールを用いたデータ分析をシンプルかつ効率的に行うことを可能にします。 データウェアハウス内に格納されていないであろう非構造化データから情報を習得するためには、データレイクを構築するという手段があります。データレイクは、全ての構造化データと非構造化データをあらゆるスケールで格納可能な、一元化されたレポジトリです。Amazon Simple Storage Service (S3)上に構築されたデータレイクによって、ビッグデータ分析を行い、機械学習を用いて準構造化データセット(JSON、XMLなど)や非構造化データから知見を得ることが簡単に行えるようになります。

Read More

Amazon Redshift の新機能 – 次世代コンピュートインスタンスと、マネージドで分析に最適化したストレージ

私たちはAmazon Redshiftを2012年にローンチしました(Amazon Redshift – The New AWS Data Warehouse)。数万ものお客様を抱え、今では世界で最も人気のあるデータウェアハウスとなっています。私たちのお客様は、業界を牽引するコストパフォーマンスで享受できる高速なパフォーマンス、複雑なクエリのサポート、トランザクション機能などに満足しています。 オリジナルのRedshiftのモデルは、計算能力とストレージのキャパシティが強固に結びついた形で規定されています。特定数のインスタンスからなるクラスターを作成すると、同時にインスタンスが搭載するローカルストレージの総量が約束されます(ときには総量によって容量が限定されます)。Concurrency Scaling(同時実行スケーリング)によって追加の処理能力を得ることもできますし、数分でクラスターのスケールアウトやスケールダウンが可能なElastic Resize(伸縮自在なサイズ変更)を使うことができるため、変化する処理能力やストレージの要求に適応することが可能です。 私たちはもっとうまくやれると思っています!今日、私たちはRedshiftに、処理能力とストレージをそれぞれ別々に最適化することができる新しいストレージ管理モデルで支えられている、Nitroベースの次世代コンピュートインスタンスをローンチします。このローンチは、ネットワークの広帯域化、Amazon Simple Storage Service (S3)を背後に持つSSDベースのローカルストレージを利用するマネージドストレージ、そしてS3との間で行き来するデータの動きを最適化するための複合的で高度なデータ管理技術といった、アーキテクチャの改良を利用しています。

Read More

Kinesis と DynamoDB をイベントソースにする際の AWS Lambda の新しいスケーリング管理

AWS Lambda は、Amazon Kinesis Data Streams と Amazon DynamoDB ストリームのイベントソースで利用可能な、新しいスケーリングパラメータを導入しました。Parallelization Factor は、各シャードにおける Lambda 関数呼び出しの同時実行数を増やす設定を可能にします。このパラメータは、デフォルトでは 1 です。これによって、処理されるレコードの順序を保証しながら、シャード数を過大にスケールすることなく、より高速なストリーム処理が可能になります。

Read More

[AWS Black Belt Online Seminar] Amazon Managed Streaming for Apache Kafka (Amazon MSK) 資料及び QA 公開

先日 (2019/11/20) 開催しました AWS Black Belt Online Seminar「 Amazon Managed Streaming for Apache Kafka (Amazon MSK) 」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。   20191120 AWS Black Belt Online Seminar Amazon Managed Streaming for Apache Kafka (Amazon MSK) from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. MSK の Kafka クラスタを構成する broker インスタンスにログインしたり、システムログを確認する方法はありますか? A. Broker インスタンスはフルマネージドで提供しており、SSH ログインするといったことはできません。Amazon Managed Streaming for […]

Read More

AWS Data Exchange を使用してデータ製品を動的に公開し、更新する

あらゆるサイズの組織において、データがビジネスの方法を大変革しています。会社はますます、サードパーティのデータを、社内のデータを補完し、顧客に価値を提供できるようにするために使用するようになっています。サードパーティのデータは、様々なユースケースで使用されています。その中には、顧客のためのアプリケーションの構築、事業の運営とマーケティング活動を改善するためのワークロードの分析、機械学習(ML)のテクニックに基づく予測モデルの構築が含まれます。 しかし、データが会社の事業の中心になったにもかかわらず、データプロバイダーがサブスクライバーにデータを提供する方法は何年も変わっていません。データプロバイダーの側からすると、提供物としてのデータと、エンタイトルメントの管理機構を構築するために、代わり映えのしないヘビーリフティングに時間と労力を費やして、顧客にサービスを提供してきたわけです。多くのデータプロバイダーは、従来式の販売方法と配信チャネルに依存しており、多くの場合、自社のデータに関心を持っている多くの見込み客にアクセスすることはできないでいます。そのため、データ製品をニーズに適合させることは遅れています。 AWS Data Exchange の世界に入ってください。 AWS Data Exchange を使用すると、クラウド内のデータを簡単に交換できます。顧客は数分で、金融サービス、ヘルスケア、ライフサイエンス、消費者および小売などの業界の 80 を超える認定データプロバイダーからの数百のデータ製品を見つけて購読できます。購読の後、顧客はデータセットをダウンロードすること、またはAmazon S3 にコピーして、AWS の様々な分析と機械学習サービスを使用しての分析することができます。AWS Data Exchange を使えば、データプロバイダーは、セキュアで透明、そして信頼できるチャネルを通して幾百万の AWS の顧客に接触する機会が得られます。AWS Data Exchange はまた、データの配信、ライセンス、または課金のインフラストラクチャを構築する必要をなくすので、既存の顧客サブスクリプションをより効率的に、そしてより低コストで提供できるようにする点でも助けになります。 多くのデータプロバイダーは、定期的に更新されるデータ製品を公開しています。たとえば、株式価格のデータプロバイダーは毎日の終値を公開したいと思うでしょうし、天気予報のデータプロバイダーは、予報を毎週更新したいと思うでしょう。この記事では、AWS Data Exchange で製品の公開と更新を動的に行う方法について、手順を追って説明します。まず、新しい製品を公開して、サブスクライバーが利用できるようにします。これは AWS Data Exchange コンソールを使用して数分間で行えます。それから、Lambda 関数を使用して、基本となるデータセットに新しいリビジョンを公開することにより、製品を自動的に更新するワークフローも知ることができます。 前提条件 開始する前に、次の前提条件を満たしてください。 AWS Data Exchange の登録プロバイダーとなる必要があります。資格があり、登録プロバイダーだけが、AWS Data Exchange でデータ製品を公開できます。資格があるプロバイダーは、米国または EU の成員国に本拠を置く有効な法人の下で AWS Marketplace の利用条件に合意し、有効な銀行および課税当局の身分証明書を提出し、AWS Data Exchange のビジネスオペレーションチームによって資格を認定される必要があります。詳細については、Providing Data Products on AWS Data Exchange(AWS […]

Read More