Category: AWS Big Data

AWS Lake Formation FindMatches は新しい機械学習 (ML、machine learning) 変換で、人間がほとんど、あるいはまったく介入することなく、さまざまなデータセットにわたってレコードを一致させたり、重複レコードを特定および削除したりできます。FindMatches は Lake Formation に含まれている、いくつかの簡単な手順を踏むだけでセキュアなデータレイクを構築できる新しい AWS のサービスです。 FindMatches を使用するのに、コードを書く必要も ML の仕組みを知っている必要もありません。また、データに一意の識別子が含まれている必要はなく、フィールドが完全に一致している必要もありません。 以下に、FindMatches で実現できることを挙げます。 顧客の一致: フィールドが完全に一致していない (名前のスペルが異なる、住所が異なる、データが欠損している、データが正確でないなどの理由による) 場合でも、さまざまなデータセットにわたって顧客レコードをリンクおよび統合できます。 製品の一致: さまざまなベンダーカタログおよび SKU にわたって製品を一致させることができます。レコードが共通の構造を共有していない場合でも可能です。 不正防止: 既知の不正アカウントと比較することで、不正のおそれがあるアカウントを特定できます。 その他データの一致: 住所、動画、部品リストなどを一致させることができます。通常、人間がデータベースの行を確認してそれらが一致すると判断できる場合、FindMatches が役に立ちます。 この記事では、FindMatches ML 変換を使用して、DBLP と Scholar という各学術刊行物サービスからの 2 つのリストで構成された学術データセットの一致レコードを特定する方法を紹介します。 このデータセットは、“Evaluation of entity resolution approaches on real-world match problems” (Köpcke, H., Thor, A., Rahm, E.) […]

AWS Lake Formation を使用すると、安全なデータレイクをセットアップすることができます。データレイクとは、すべての構造化データと非構造化データを任意の規模で保存する、一元化され、キュレーションされた安全なリポジトリです。データは現状のままで保存でき、事前に構造化しておく必要はありません。また、ダッシュボードや視覚化から、ビッグデータ処理、リアルタイム分析、機械学習にいたるまで、さまざまな種類の分析を実行できるので、意思決定の向上につながります。 データレイクの課題 データレイク管理における主要な課題は、内容を監視せずに raw データを保存することに起因しています。レイクのデータを使用可能にするには、そのデータのカタログ化とセキュア化を行う、定義済みのメカニズムが必要です。 Lake Formation は、ガバナンス、意味的一貫性、アクセスコントロールをデータレイクに実装するためのメカニズムを提供します。Lake Formation を使うことで、データを分析や機械学習に使用しやすくなり、ビジネスにより優れた価値をもたらすことができます。 また、Lake Formation を使えば、データレイクのアクセスを制御したり、データにアクセスする人を監査したりすることができます。AWS Glue データカタログは、データアクセスのポリシーを統合して、データの送信元にかかわらずコンプライアンスを確保します。 チュートリアル このチュートリアルでは、データレイクの構築方法と使用方法について説明します。 データレイクの管理者を作成します。 Amazon S3 のパスを登録します。 データベースを作成します。 アクセス許可を付与します。 AWS Glue を使ってデータをクロールし、メタデータとテーブルを作成します。 テーブルデータへのアクセス権限を付与します。 Amazon Athena を使ってデータをクエリします。 アクセスが制限されている新規ユーザーを追加し、結果を検証します。 前提条件 このチュートリアルを行うには以下のリソースが必要です。 AWS アカウント。 AWSLakeFormationDataAdmin を持つ IAM ユーザー。詳細は IAM アクセスポリシーについてのドキュメントを参照してください。 米国東部 (バージニア北部) の datalake-yourname-region という名前の S3 バケット。 新しい S3 バケット内にある zipcode […]

Amazon は、常にお客様のニーズに基づいて働いています。お客様は、レガシーのオンプレミスデータウェアハウスから既存のワークロードを簡単に移行できるように、Amazon Redshift でストアドプロシージャを使用できることを強く要望しています。 この大切な目標を念頭に置いて、AWS は PL/pqSQL ストアドプロシージャを実装して、既存のプロシージャとの互換性を最大限に高め、移行を簡素化することを選択しました。この記事では、運用の効率性とセキュリティを向上させるためにストアドプロシージャを使用する方法と場合について説明します。AWS Schema Conversion Tool でストアドプロシージャを使用する方法も説明します。 ストアドプロシージャとは ストアドプロシージャとは、一連の SQL クエリと論理操作を実行するためにユーザーが作成するオブジェクトです。プロシージャはデータベースに保存され、実行するのに十分な権限を持つユーザーが利用できます。 ユーザー定義関数 (UDF) とは異なり、ストアードプロシージャーは SELECT 照会に加えてデータ定義言語 (DDL) およびデータ操作言語 (DML) を組み込むことができます。ストアドプロシージャは値を返す必要はありません。ループや条件式を含む PL/pgSQL 手続き型言語を使用して論理フローを制御できます。

 Amazon EMR の速さと柔軟性を、Apache Hive の有用性とユビキタス性と組み合わせることで、両方の長所が得られます。ただし、ビッグデータプロジェクトを始めるのは容易なことではありません。EMR に新しいデータをデプロイする場合でも、既存のプロジェクトを移行する場合でも、この記事では開始するための基本を説明します。 Apache Hive は、Apache Hadoop クラスターで動作するオープンソースのデータウェアハウスおよび分析パッケージです。Hive メタストアには、パーティション名やデータ型など、テーブルとその基礎となるデータの説明が含まれています。Hive は、EMR で実行できるアプリケーションの 1 つです。 この記事が提示するソリューションの大半は、メタストアを管理するために、Hiveにスケーラビリティを提供する Apache Hadoop を使用していることを前提としています。Hadoop を使用しない場合は、Amazon EMR のドキュメントを参照してください。 Hive メタストアのデプロイメント Hive メタストアでは、埋め込み、ローカル、またはリモートの 3 つの構成パターンのいずれかを選択できます。 オンプレミスの Hadoop クラスターを EMR に移行する場合、移行戦略は既存の Hive メタストアの構成によって異なります。 設定を検討する際は、いくつかの重要な事実を考慮してください。Apache Hive には、埋め込みメタストアに使用できる Derby データベースが付属しています。ただし、Derby は本番稼働レベルのワークロードには対応できません。 EMR を実行している場合、Hive はマスターノードのファイルシステム上の MySQL データベースにメタストア情報を一時ストレージとして記録し、ローカルメタストアを作成します。 クラスターが終了すると、そのマスターノードを含めてすべてのクラスターノードがシャットダウンし、データが消去されます。 これらの問題を回避するには、外部 Hive メタストアを作成します。これにより、Hive メタデータストアを実装に合わせて拡張できるようになり、クラスターが終了してもメタストアが維持されるようになります。 EMR 用の外部 Hive メタストアを作成する方法は […]

Amazon Athena は、Amazon S3 のデータに対するサーバーレスのクエリエンジンです。多くのお客様が、Athena を使用してアプリケーションおよびサービスのログを照会し、自動化されたレポートをスケジュールし、それらのアプリケーションと統合し、新しい分析ベースの機能を可能にしています。 ビジネスアナリスト、データサイエンティスト、セキュリティ、オペレーションエンジニアなど、さまざまな種類のユーザーが Athena を活用しています。しかし、コストを最小限に抑えながらユーザーが最高の体験を得られるには、こうしたワークロードをどのように分離および管理すればよいでしょうか? この記事では、ワークグループを使用して以下を行う方法を説明します。 ワークロードを分離する。 ユーザーのアクセスをコントロールする。 クエリの使用状況およびコストを管理する。

長期にわたって稼働する Amazon EMR クラスターを使用している開発者またはデータサイエンティストであれば、急激に変化するワークロードに直面します。これらの変化では、クラスターで最適に実行するために、異なるアプリケーションの構成をしばしば必要とします。 再構成機能を使用して、EMR クラスターを実行するときに、構成を変更することができるようになりました。EMR リリース emr-5.21.0 から、この機能を使用すると、新しいクラスターを作成せずに、または各ノードに SSH で手動で接続せずに、構成を変更できるようになりました。 この記事では、次のトピックについて取り上げます。 再構成の使用 インスタンスグループの状態、構成バージョン、イベント 再構成例の使用事例 再構成の利点 再構成の使用 以下のタスクは、EMR release emr-5.21.0 で更新されます。 再構成の提出 構成の変更 構成レベルの定義 再構成の提出 EMR コンソール、SDK、または AWS CLI を通じて認識を送信できます。詳細については、認識の送信と追加情報を参照してください。. 構成の変更 再構成を送信するときに、クラスターに適用する構成のすべてを含まなければなりません。更新のみがこれらの項目に適用され、ほかのすべてを削除します。構成を変更すると、EMR コンソールはまた前のクラスター構成も追跡します。 構成レベルの定義 アプリケーションのクラスターレベルとインスタンスグループレベルの構成を定義します。クラスターを作成するため、クラスターレベルの構成を提供します。これらの構成は、クラスターが開始し実行中となった後で追加された場合でも、その後自動的にすべてのインスタンスグループに適用されます。構成が開始した後で、クラスターレベルの構成を変更できません。しかし、再構成リクエストを通じて、インスタンスグループレベルでこれらの構成を補足またはオーバーライドできます。インスタンスグループの再構成要求を送信するたびに、これらの新しいインスタンスグループレベルの構成は継承されたクラスターレベルの構成よりも優先されます。 インスタンスグループでクラスタレベルとインスタンスグループレベルの設定がどのように連携して機能するかをよりよく理解するために、EMRコンソールで簡単なデモを見てください。 [構成] タブで、[フィルター] ドロップダウンリストのインスタンスグループを選択します。該当するインスタンスグループの構成表に移動します。構成表の [ソース] 列は、構成のレベルを示します。 このクラスターは、次のクラスターレベルの構成セットで始まります。 [ { “Classification”: “core-site”, “Properties”: { “Key-A”: “Value-1”, “Key-B”: “Value-2” } } ] […]

Amazon EMR のリリース 5.24.0 には Spark の最適化がいくつか含まれており、クエリのパフォーマンスが向上しました。パフォーマンスの向上を評価するため、Amazon S3 のデータを使用して、6 ノードの c4.8xlarge EMR クラスターで 3 TB 規模の TPC-DS ベンチマーククエリを実行しました。同様の設定で操作した EMR 5.16 と比較して、EMR 5.24 のクエリパフォーマンスが最大で 13 倍向上したことを確認しました。 大規模な変換からストリーミング、データサイエンス、そして機械学習に至るまでの幅広い分析ユースケースで、Sparkを使用できます。Spark を EMR で実行すると、EMR は安定した最新のオープンソースコミュニティといった革新をもたらし、さらに Amazon S3 での高性能ストレージ、スポットインスタンスと Auto Scaling の独自のコスト削減機能も提供します。 毎月配信される EMR のリリースには、最新のオープンソースパッケージとともに、複数のマスターノードやクラスターの再構成などの新機能も含まれています。各リリースで、パフォーマンスの改善も行っています。

世界中の企業が、Apache Hadoop や Apache Spark などの新しいビッグデータ処理および分析のフレームワークの力を発見していますが、同時にオンプレミスのデータレイク環境でこうしたテクノロジを運用する際のいくつかの課題にも気付いています。また、現在の配信ベンダーの将来についても懸念があるかもしれません。 こうした課題に対処するために、Amazon EMR 移行ガイド (2019 年 6 月に最初に公開) を発表しました。 これは、オンプレミスのビッグデータのデプロイから EMR への移行方法を計画する際に役立つ、適切な技術的アドバイスを提供する包括的なガイドです。 IT 組織はリソースのプロビジョニング、不均一なワークロードの大規模な処理、そして急速に変化するコミュニティ主導のオープンソースソフトウェアのイノベーションのスピードに追いつくための努力に取り組んでいるため、オンプレミスのビッグデータ環境における一般的な問題としては、俊敏性の欠如、過剰なコスト、管理に関する課題などがあります。多くのビッグデータに関する取り組みでは、基盤となるハードウェアおよびソフトウェアインフラストラクチャの評価、選択、購入、納入、デプロイ、統合、プロビジョニング、パッチ適用、保守、アップグレード、サポートの遅れや負担が課題となっています。 同様に重要ではあるものの、微妙な問題は、企業のデータセンターでの Apache Hadoop と Apache Spark のデプロイが同じサーバー内のコンピューティングリソースとストレージリソースを直接結びつける方法であり、足並みを揃えて拡張しなければならない柔軟性に欠けるモデルとなることです。つまり、ほとんどのオンプレミス環境では、各ワークロードのコンポーネントに対する要件が異なるため、未使用のディスク容量、処理能力、システムメモリが多くなってしまいます。 一般的なワークロードは、さまざまな種類のクラスターで、さまざまな頻度と時間帯で実行されます。こうしたビッグデータのワークロードは、共有している同じ基盤となるストレージまたはデータレイクにアクセスしながら、いつでも最も効率的に実行できるように解放する必要があります。説明については、下の図 1 を参照してください。 スマートな企業は、どのようにしてビッグデータへの取り組みで成功を収めることができるでしょうか? ビッグデータ (および機械学習) をクラウドに移行することには多くの利点があります。AWS などのクラウドインフラストラクチャサービスプロバイダーは、オンデマンドで伸縮自在なコンピューティングリソース、回復力があり安価な永続的ストレージ、およびビッグデータアプリケーションを開発および運用するための最新の使い慣れた環境を提供するマネージド型サービスの幅広い選択肢を提供します。データエンジニア、開発者、データサイエンティスト、IT 担当者は、データの準備と貴重な洞察の抽出に集中することができます。 Amazon EMR、AWS Glue、Amazon S3 などのサービスを使用すると、コンピューティングとストレージを個別に分離および拡張しながら、統合され、高度に管理された、回復力の高い環境を提供し、オンプレミスアプローチの問題を即座に軽減できます。このアプローチは、より速く、より俊敏で、使いやすく、よりコスト効率の良いビッグデータとデータレイクのイニシアチブにつながります。 ただし、従来のオンプレミスの Apache Hadoop および Apache Spark に関する既存の知恵は、クラウドベースのデプロイでは必ずしも最善の戦略とはなりません。クラウド内でクラスターノードを実行するための単純なリフトアンドシフトアプローチは、概念的には簡単ですが、実際には次善の策です。ビッグデータをクラウドアーキテクチャに移行する際に、さまざまな設計上の決定が利益を最大化するために大きく役立ちます。 このガイドでは、以下のベストプラクティスを紹介します。 データ、アプリケーション、およびカタログの移行 永続的リソースと一時的リソースの使用 セキュリティポリシー、アクセスコントロール、および監査ログの設定 価値を最大化しながら、コストを見積もりそして最小化する AWS クラウドを活用して高可用性 (HA) と災害復旧 […]

3M Health Care の事業である 3M Health Information Systems (HIS) は、医療従事者、患者、および政府機関と協力して変化するヘルスケアの展望を予測してナビゲートしています。3M は、顧客が量から価値ベースの医療に移行するのを支援する医療業績測定および管理ソリューション、分析、および戦略的サービスを提供することで、数百万ドルを節約し、プロバイダーの業績を向上させ、質の高い医療を提供できるようにしています。3M の革新的なソフトウェアは、コンピュータ支援コーディング、臨床文書の改善、パフォーマンスの監視、品質結果報告、および用語集管理の基準を引き上げるように設計されています。 3M HIS では、オンプレミスまたは他のクラウドホスティングプロバイダーにインストールされているアプリケーションをアマゾン ウェブ サービス (AWS) に移行するための継続的なイニシアチブがありました。3M HIS は、コンピューティング、ストレージ、およびネットワークの弾力性を活かすために AWS への移行を開始しました。当社は今後数年間に予想される事業の成長をサポートするために拡張する一方で、顧客価値の提供に注力するのに役立つ確固たる基盤を構築したいと考えていました。3M HIS はすでに本質的に複雑な多くの顧客の医療データを処理していたため、分析や機械学習に役立つ形式にデータを変換する多大な作業が必要でした。 多くのソリューションを検討した結果、3M HIS は適切なデータウェアハウスソリューションとして Amazon Redshift を選択しました。当社は、カラムストレージを使用して I/O を最小限に抑え、高いデータ圧縮率を提供し、高速パフォーマンスを提供する、高速で完全マネージド型のペタバイト規模のデータウェアハウスソリューションである Amazon Redshift が当社のニーズに合致すると結論付けました。開発環境ですぐにクラスターを作り、ディメンションモデルを作成し、データをロードして、ユーザーデータのベンチマークとテストを実行できるようにしました。さまざまなソースから Amazon Redshift にデータを処理してロードするために、抽出、変換、ロード (ETL) ツールを使用しました。 多くのソリューションを検討した結果、3M HIS は適切なデータウェアハウスソリューションとして Amazon Redshift を選択しました。当社は、カラムストレージを使用して I/O を最小限に抑え、高いデータ圧縮率を提供し、高速パフォーマンスを提供する、高速で完全マネージド型のペタバイト規模のデータウェアハウスソリューションである Amazon Redshift が当社のニーズに合致すると結論付けました。開発環境ですぐにクラスターを作り、ディメンションモデルを作成し、データをロードして、ユーザーデータのベンチマークとテストを実行できるようにしました。さまざまなソースから Amazon Redshift にデータを処理してロードするために、抽出、変換、ロード […]

本日、Amazon QuickSight に一連のアップデートを発表できることを、嬉しく感じております。 通常と組み込み用、両方のダッシュボードがマルチシートでより豊かに。 複数の軸ラベル方向オプションで、ダッシュボードの可読性が改善。 SPICE に、標準偏差、分散、および文字条件関数などの計算機能が追加。 広範囲のインタラクティブシナリオをサポートする、強化されたURLアクション。 画像をワンクリックで複製し、素早いオーサリング。 ダッシュボードのマルチシート対応 まず最初に、新しいタブコントロールからアクセスするマルチシートが使えるようになった、ダッシュボードのアップデートを見てみましょう。これにより、ダッシュボード内の情報が整理しやすくなりました。特定の対象エリアもしくはトピックに関連した画像を分離したシートで整理でき、タブ名によって明確に区別できます。閲覧側では、1 つのトピックに関連するインサイト全体の包括的な表示を、ダッシュボード上でナビゲーションできるようになります。