Amazon Web Services ブログ

Category: Analytics

患者記録を 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

メインとなる AWS Lake Formation アカウントから、複数のアカウントのデータにアクセスおよび管理を行う

 この記事では、中心的な AWS Lake Formation アカウントが、複数のアカウントにあるデータのアクセスや管理を行う方法を解説していきます。このウォークスルーでは、異なるアカウントにあるデータを使い、マスターとなる Lake Formation アカウントにある一元管理されたカタログを示します。 記事の中では、別のアカウントにあるカタログの読み出し、書き込み、更新、およびデータへのアクセスを行う許可を、Lake Formation サービスから付与する方法を説明します。 また、2 つのデータセットを使って、世界中から集めたニュース (gdelt) と、Amazon の製品が受けたレビューの数 (amazonreviews) との間に 相関性 が存在するかを判断していきます。 前提条件 今回の例では、それぞれ S3 バケットとアカウント番号がある、3 つのアカウントを使用する必要があります。 環境の設定 3 つのアカウントは次なようなものです。 Account Products (AP) – これは、Amazon の製品が受けたレビューを保存するためのアカウントです。この記事では、AWS CloudFormation を使って構成したものをデプロイします。 Account External (AE) – このアカウントは、100 を超える言語による放送、印刷物、ウェブニュースを世界中から集めモニタリングします。これは、毎日毎秒のように国際社会を動かし続けている、人々、場所、組織、数、テーマ、情報ソース、感情、引用、画像、出来事などを抽出します。この記事では、AWS CloudFormation を使って構成したものをデプロイします。 Main Account (MA) – メインとなるアカウントです。他の 2 つのアカウントからのデータを集約します。今回は、このアカウントに Lake Formation を定義します。このアカウントには、製品データと国際ニュース用のアカウントへのアクセス権限があります。 次の図は、全体的なアーキテクチャを示しています。 […]

Read More

ironSource が多目的データレイクを Upsolver、Amazon S3、および Amazon Athena で構築する方法

ironSourceは、独自の言葉で言えば、アプリ内の収益化と動画広告の主要なプラットフォームで、世界中の 15 億人を超える人々が無料でプレイおよび使用できるようにしています。 ironSource は、業界最大のアプリ内動画ネットワークなどを含めて、アプリ開発者がアプリを次のレベルに引き上げることを支援します。80,000 を超えるアプリが ironSource テクノロジーを使用して、ビジネスを成長させています。 ironSource がさまざまな収益化プラットフォーム(アプリ、ビデオ、メディエーションを含む)にわたって動作する巨大な規模は、膨大な量のストリーミングデータを生成する数百万のエンドデバイスにつながります。インフラストラクチャとエンジニアリングのオーバーヘッドを最小限に抑える一方で、複数のユースケースをサポートするために、データを収集、保存、準備する必要があります。 この記事では以下について説明します。 ironSource が Amazon S3 に基づくデータレイクアーキテクチャを選択した理由。 ironSource が Upsolver を使用してデータレイクを構築する方法 Amazon Athena、Amazon ES、および Tableau などのアナリティックサービスに対して出力を作成する方法。 このソリューションの利点 データレイクアーキテクチャの利点 データベースに焦点をあてたアプローチで数年間仕事をした後で、ironSource のデータは以前のシステムをコストとメンテナンスの観点で、実行不可能にしました。代わりに、生イベントデータをオブジェクトストレージに保管し、複数のアプリケーションとアナリティックフローに対応してカスタマイズされた出力ストリームを作成するデータレイクアーキテクチャを採用しました。 ironSource が AWS データレイクを選択した理由 データレイクは以下の理由で ironSource の正しいソリューションでした。 規模 – ironSource は、1 秒あたり 50 万件のイベントと毎日 200 億件を超えるイベントを処理しています。S3 でほぼ無限の量のデータを、データの事前処理なしで保管する能力は重要です。 柔軟性 – ironSource は複数のビジネスプロセスをサポートするデータを使用します。同じデータを複数のサービスにフィードして、異なるユースケースを提供することが必要なため、会社はデータベースアプローチによりもたらされる堅牢姓とスキーマ―の制限をバイパスすることが必要でした。代わりに、元のデータを S3 に保管して、臨時の出力と変換を必要に応じて作成します。 弾力性 – すべての履歴データが […]

Read More

【開催報告】Amazon Analytics 事例祭り – データウェアハウスマイグレーション

こんにちは。アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクトの平間です。 9月24日に、「Amazon Analytics 事例祭り – データウェアハウスマイグレーション」を開催いたしました。今回は既存のデータウェアハウス(DWH)環境から、AWSの高速かつ完全マネージド型のDWHであるAmazon Redshiftへ移行されたお客様に、移行の決め手や移行後の効果について「本音」でお話ししていただきました。セミナーは前半がAWSソリューションアーキテクトからAWSのデータレイク及びアナリティクスサービスの概要と、DWHの移行をどのように検討すればよいかの方法をお話させていただき、後半はお客様より移行時の体験談をお話しいただいております。

Read More