データレイクの概念と重要性

データレイク（データの湖）とは、大量の生データをネイティブのフォーマットのままで迅速に取り込める保管庫です。その結果、ビジネスユーザーは必要に応じていつでもデータに素早くアクセスできるようになり、また、データサイエンティストは洞察を得るためのアナリティクスを適用しやすくなります。年上の “いとこ” のデータウェアハウスとは異なり、データレイクはツイート、画像、音声、ストリーミング・データなどの非構造化ビッグデータを保管する目的に理想的です。ただし、データレイクは、データのソース／サイズ／速度／構造を問わず、あらゆるタイプのデータを保管する目的に利用できます。

データレイクに保管される情報の主なフォーマットは以下の通りです。

• 構造化データ： リレーショナル・データベースのテーブルの行と列のような構造で格納されているデータを指します。
• 半構造化データ： 区切り形式のテキストファイルやスキーマ埋め込み型のファイルに格納されているデータを指します。
• 非構造化データ： 文書、画像、音声、動画のほか、ソーシャルメディアのコンテンツや、IoT（Internet of Things、モノのインターネット）のデータも含まれます。

データレイクの歴史： そもそもの始まり

私たちが今現在データレイクと呼んでいるものの初期バージョンは、“黄色いゾウの水飲み場” すなわちHadoopコミュニティによって生み出されました。最初にリリースされた当時のHadoopは、ビッグデータの分散型の保管／処理／アナリティクスのために使われるオープンソース・ソフトウェアの集合体でした。Hadoopは特に、その当時に広く普及しつつあった新出の半構造化データや非構造化データのソースに対して有用でした。データレイクも、データ量が急増していた構造化データに対応するためのスケールアップ目的で利用されました。

残念なことに、Hadoopをめぐる初期のハイプ（宣伝文句）は、「どのような量のデータでもどんどんレイクに放り込み、後はユーザーの自助努力に任せればよい」という利用法を示唆していました。しかし、複数の公表された失敗事例により、このアプローチが間違いであることが実証されました。一部のアーリーアダプターは、あっという間にデータレイクが “データの泥沼” とでも呼ぶべき「管理が行き届かず、ガバナンスが存在しない投棄場」となってしまう様子を目の当たりにしました。この状況は以下のような結果を生みました。

• 冗長性： これは分析の結果を歪めます。
• 監査適合性のないデータ： 誰も信頼しません。
• 不十分なクエリ・パフォーマンス： これはデータレイクの当初の主要目的（ハイパフォーマンスな探索／発見）に反します。

これらの「文書化や組織化を伴わない初期のデータレイク」は操作不能に近い状態だったのです。その後、メタデータ・タギングが発展し、それによってデータレイク内のデータが見つけやすくなったことから、メタデータ・タギングは最も不可欠なデータレイク管理プラクティスの１つとなりました。また、データレイクのガバナンスという考え方の普及により、データレイクの監査適合性と信頼性が改善され、より多くのエンタープライズ・アプリケーションでデータレイクを利用できる可能性が裏付けられました。

データレイクを実装するために使われるテクノロジーと方法論は時を経て成熟してきており、今ではHadoopだけでなく、他の従来型テクノロジーやビッグデータ・テクノロジーも使われるようになっています。

初期のハイプからの脱却

初期のハイプが消え去ると、データ・プラットフォームに関してデータレイクが誤解されることはなくなりました。代わりに、データレイクは「多様なデータを１つの便利な場所に共存させることのできる、複数のデータ・コレクションのための格納庫」として認識されるようになりました。

今日、データレイクは全社的なデータ／アナリティクス戦略に正式に含まれるようになっています。企業や組織は「データレイク」という用語が、以下のような構成要素からなるエンタープライズ・エコシステムの１つの構成要素を指していることを認識しています。

• ソースシステム
• 取り込みパイプライン
• 統合／データ処理テクノロジー
• データベース
• メタデータ
• アナリティクス・エンジン
• データアクセス・レイヤー

データレイクが「高いビジネス価値を生み出す包括的なビジネス・インテリジェンス・プラットフォーム」の構成要素となるためには、統合、クレンジング、メタデータ管理、ガバナンスなどの機能が必要不可欠です。先進的な企業や組織は今、データレイクの管理にこのような総合的アプローチを採用しつつあり、その結果、アナリティクスを活用して、多様な構造の多様なソースに由来する多様なデータを相関付けることが可能になっています。これは「意思決定を行う際に、より包括的なビジネス・インサイトを活用できる」ということを意味します。

データレイクが重要な理由

データレイクはあらゆるタイプの新しいデータを迅速に取り込めるため ── また、セルフサービス型のアクセス／探索／ビジュアライゼーションの提供を可能にするため ──、企業や組織は新しい情報の把握と対応措置をより迅速に実行できるようになります。さらに、過去には不可能だったデータにもアクセスできるようになります。

こうした新たなデータタイプやデータソースは、データ発見、概念実証（PoC）、ビジュアライゼーション、高度なアナリティクスのために利用できます。例えば、データレイクは機械学習のためのデータソースとして最も一般的です。機械学習はログファイル、Webサイトのクリックストリーム・データ、ソーシャルメディア・コンテンツ、センサーのストリーミング・データ、その他のインターネット関連デバイス由来のデータに適用されることの多い技法です。

多くの企業は長らく、発見志向の探索、高度なアナリティクス、高度なレポーティングを実行できる能力を切望してきました。データレイクは、その実現に必要となる大規模かつ多様なデータを素早く提供します。また、データレイクはビッグデータと従来型データ、両方のための整理統合ポイントとなり、全データを対象にした相関分析の実現をサポートすることもできます。

データレイクは典型的には生データを保管するために使われますが、データウェアハウスやその下流側プロセスで生成される中間データ、変換済みデータ、再構成済みデータ、集計済みデータなどをデータレイクに保管することもできます。これは多くの場合、データサイエンティストが一般的なデータ準備タスクに費やす時間を削減する目的で行います。

同じアプローチが、個人識別可能情報（personally identifiable information: PII）や、アナリティクスに不要なその他の機密データを秘匿化または匿名化する際に利用されることもあります。これは、企業や組織がデータのセキュリティ・ポリシーやプライバシー・ポリシーを遵守するために役立ちます。なお、企業がセキュリティを維持管理するために利用できるもう１つの手法として、アクセス制御があります。

データレイクとデータウェアハウスの比較

データレイクとデータウェアハウスを比較するときは、何を考慮する必要があるのでしょう？最も重要な考慮事項の１つはデータストアの設計またはスキーマに関連しています。

リレーショナル・データベースやその他の構造化データストアは、スキーマ重視型の設計を使います。これは、そこに追加されるデータは「そのスキーマによって事前定義済みの構造」に準拠していなければならず、それ以外のデータは適切に変換されなければならない、ということを意味します。スキーマは、具体的な用途のビジネス要件に沿って作成されます。そして、このタイプの設計の最も簡単な実例がデータウェアハウスです。

一方、データレイクはデータ重視型の設計を使います。これにより、用途に合わせてデータ構造やビジネス要件を定義する前の時点でも迅速に新しいデータを取り込めるようになります。場合によっては、データウェアハウスとデータレイクを順に「スキーマ・オン・ライト（Schema on Write）」［直訳：書き込み時スキーマ］と「スキーマ・オン・リード（Schema on Read）」［直訳：読み出し時スキーマ］という用語で区別することもあります。

• スキーマ・オン・ライト（＝データウェアハウス）は、新しいデータの取り込みを制限または低速化します。このスキーマは「データに関する特定の目的」や「関連する特定のメタデータ」を念頭に置いて設計されます。ただし、ほとんどのデータは複数の目的のために利用可能です。
• スキーマ・オン・リード（＝データレイク）は、生データをそのまま保持します。そのため、データを容易に再目的化することができます。また、同じデータに複数のメタデータ・タグを割り当てることができます。

データレイクは、単一の構造に制約されないことから、同じ主題領域に関する多重構造データに対応することができます。例えば、データレイクには「販売取引の構造化データ」と「顧客センチメントの非構造化データ」を混在させることができます。また、データレイクの重点はストレージであるため、データウェアハウスよりも少ない処理パワーしか必要としません。さらに、データレイクは時の経過に沿った規模拡大も、より容易かつ迅速に、より低コストで行うことができます。

データレイクの欠点の１つは、「そこに保管されているデータには標準化、重複除去、品質チェック、変換が施されていない」ということです。その対策として、一部の人々は「データレイクを別の方法で利用するトレンド」を取り入れています。その場合、データレイクは「データウェアハウスにロードするための準備／統合／変換を実行する前にデータをランティングおよびステージングするための、新しい改善されたゾーン」を提供する目的で利用されます。

以上の例は、データレイクがデータウェアハウスに取って代わる存在ではなく、データウェアハウスを補完する存在であることの理由を説明しています。ステージング領域としての利用以外では、データレイクをアーカイブとして利用することもできます。このシナリオでは、例えば日付が古いデータをアーカイブしますが、監査や履歴分析のために当該データにすぐにアクセスできる状態も維持します。

初期のデータレイク： より踏み込んだ解説

初期のデータレイクは「多種多様なストレージ・デバイスにまたがり、あたかも単一ファイルであるかのようにデータを保管するためのフレームワーク」として、オープンソースのHDFS（Hadoop分散ファイルシステム）を使っていました。HDFSはデータ処理およびリソース管理フレームワークとしてのMapReduceと連携して機能しました。このフレームワークは集計分析のような大きな計算タスクを小さなタスクへと分割する役割を担い、小さく分割されたタスクは汎用ハードウェアのコンピューティング・クラスター上で並列実行されました。

2番目のリリースで、Hadoopには「MapReduceからリソース管理フレームワークを分離し、それをYARN（Yet Another Resource Negotiator）に置き換える」という改善が施されました。そしてこれが実質的に、Hadoopのオペレーティング・システムとなりました。最も重要なのは、YARNが「処理フレームワークとしてのMapReduce」に対する代替物の利用をサポートしたことです。これにより、Hadoop内でネイティブに実行可能なアプリケーション（およびデータ管理機能やガバナンス機能）の選択肢が大きく広がることになりました。

今日のデータレイクの仕組み

大量のデータを迅速に取り込める点と、生データをネイティブ・フォーマットで保管できる点は、これまで常にデータレイクの重要なメリットであり続けてきました。しかし、それは正確にはどのような意味でしょうか？ また、その仕組みはどうなっているのでしょう？

• 生データとは、そのデータが特定の用途のために処理または準備されていないことを意味します。しかしながら、データソースによっては、何らかの処理や準備を適用した後のデータを格納しているものもあります。そのため、データレイクが生データを保管するというのは、「保管前にデータレイク自身が処理や準備を施さない」という意味です。特筆すべき１つの例外はフォーマットに関連しています。
• ネイティブ・フォーマットとは、データが、それを作成したソースシステムまたはアプリケーションのフォーマットのままであることを意味します。しかしながら、これがデータレイクのストレージにとって常に最良のオプションとは限りません。実際、「迅速な取り込み」が「データレイクのファイルシステムのディレクトリにデータをそのままコピーすること」を意味するケースはほとんどありません。

例えば、Microsoft Excelのスプレッドシートは、デフォルトではExcelネイティブのXLSまたはXLSX形式のファイルです。しかし、ほとんどのデータレイクでは、それを「カンマ区切り（CSV）形式のテキストファイル」として保管する方が好まれます。リレーショナル・データベースのトランザクション・データも、多くの場合は、CSVファイルに変換された上でデータレイクに格納されます。

スキーマ埋め込み型ファイルと高粒度データ

もう１つの一般的な代替手法は、JSON（JavaScript Object Notation）のような、スキーマ情報を埋め込むタイプのファイル形式を使うことです。例えば、クリックストリーム・データ、ソーシャルメディア・コンテンツ、IoTのセンサーデータは通常、JSONファイルに変換された上でデータレイクに保管されます。データレイクのデータ取り込み処理は多くの場合、データを「ネイティブ・フォーマット」から「より高粒度のフォーマット」に変換する処理を伴いますが、JSONファイルはその方法の好例でもあります。

高粒度データ、特にKVP（Key-Value Pairs）形式のようにスキーマ情報が埋め込まれている高粒度データは、読み書き操作の高速化を実現します。これは以下のことを意味します。高粒度データは・・・

• 最適な／デフォルトの／欠損した “キーまたは値” のためのプレースホルダでストレージを浪費することがありません。
• さまざまな状況のニーズに合わせて集計または脱集計化することができます。
• より容易な操作で、特定の用途に適したデータのみを取得することができます。
  
  

追加的な、より最適化されたデータレイク・ストレージ・フォーマットも利用可能です。その中には、スケーラビリティや並列処理の向上を実現すると同時に、スキーマ情報を埋め込むこともできるストレージ・フォーマットもあります。以下のフォーマットにデータを変換することができます。

• 列ストア（例：Redshift、Vertica、Snowflake）
• 圧縮列指向フォーマット（例：Parquet for Spark、ORC for Hive）
• 従来の行指向フォーマット（例：PostgreSQL、MySQL、その他のリレーショナル・データベース）
• 圧縮行指向フォーマット（例：Avro for Kafka）
• インメモリ・ストア（例：SingleStore、Redis、VoltDB）
• NoSQLストア（例：MongoDB、Elasticsearch、Cassandra）

データ・ストレージのさまざまな選択肢の使い分け

ほとんどのデータレイクは、データソースやビジネスケースに応じて多様なストレージを使い分けています。これは、アクセスとアナリティクスに関連するビジネスケースの場合は特に顕著です。いくつか例を挙げましょう。

• 列指向ストレージは、取得の迅速化や集計の加速化が最重視される場合に最適です。
• 行指向ストレージは、スキーマの変動性（ばらつき度合）が高い場合に最適です（ストリーミング・アプリケーションの多くはこれに該当します）。また、データレイクが「データウェアハウスのステージング領域」として利用される場合にも理想的です。
• インメモリ・ストレージは、リアルタイム分析のユースケースに最適です。
• NoSQLストレージは、大規模なデータセット群から迅速に指標値を生成する必要のあるアナリティクス・シナリオに最適です。

データレイクとそのアーキテクチャの重要性

結局のところ、データレイクは単なる大規模ストレージではありません。そのため、周到に設計されたデータ・アーキテクチャが必要不可欠です。幸い、生データを迅速に取り込む機能をデータレイクに実装するための幅広いツールを利用できます。こうしたツールには、企業が既に保有している可能性の高いデータ統合ツールやETL（抽出、変換、ロード）ツールも含まれます。一部の新しいビッグデータ・テクノロジー（上記の実例のいくつかを含みます）も、この機能を提供しています。

どのような取り込み機能やストレージを選択するかを問わず、データレイクを実装する際は、何らかのバックエンド・テクノロジーの導入が必要となる可能性があります。それが非リレーショナル・データベース管理システム（non-RDBMSs）の場合は特に、あなたには馴染みの薄いテクノロジーかもしれません。幸い、これらのテクノロジーの多くは、使いやすいフロントエンド・インターフェイスを搭載しています。例えば、多くのユーザーが期待し、既に使い方を知っていると思われる “SQL風のクエリ機能” を提供するテクノロジーもあります。

データレイクとクラウド

データレイクは、すべての企業データがそこを通過する「一元管理型のリポジトリ」として利用することが可能です。その場合、データレイクは容易にアクセスできるステージング領域として機能し、それをすべての企業データの供給源として利用できるようになります。これには、オンサイト・アプリケーションや、ビッグデータのサイズ／速度／複雑性に対応できるクラウドベース・アプリケーションによって利用されるデータも含まれます。以上のすべてを踏まえると、データレイクとクラウドの比較に関する疑問が生じます。データレイクはどこに置かれるべきなのでしょう？

クラウド・データレイク

一部の企業にとっては、データレイク・ストレージの最適な選択肢はクラウドである可能性があります。なぜならクラウドは、伸縮自在のスケーラビリティ、より迅速なサービス提供、IT環境の効率向上といった補完的なメリットを、サブスクリプション方式の料金モデルで提供するからです。

オンサイト・データレイク

企業によっては、プライベート・クラウドをオンサイトで管理する際の議論と同じような理由から、データレイクを構内に設置することを選択する可能性があります。このアプローチは、最大限のセキュリティと統制を提供すると同時に、知的財産と重要なビジネス・アプリケーションの保護も実現します。また、行政当局の規制を遵守しながら機密データを守ることも可能になります。

ただし、プライベート・クラウドをオンサイトで管理する場合の短所がデータレイクにも当てはまるため、データレイクのアーキテクチャ、ハードウェア・インフラ、関連のソフトウェア／サービスを内製保守する負荷の増大につながる可能性があります。

ハイブリッド・データレイク

企業によっては、データレイクをオンサイトとクラウドに分割するハイブリッド・データレイクを選択することもあります。このアーキテクチャの場合、典型的には、クラウドのデータレイクには重要なビジネスデータを保管しません。また、データに個人識別可能情報（PII）やその他の機密データが含まれている場合は、秘匿化または匿名化を適用します。これは、企業がデータセキュリティ・ポリシーやプライバシー・ポリシーを遵守するために役立ちます。クラウド・ストレージのコストを最小限に抑えたい場合は、クラウドに保管されているデータを定期的に、あるいはパイロット・プロジェクトの完了後などのタイミングで消去することができます。