1つめは、データレイクを構築する場所と、利用するサービスや製品の選定です。データレイク構築のスタート地点であり、最も重要な部分でしょう。
2つめは、データレイクに蓄積するデータのフォーマットを決めるタイミングです。データの格納時、または利用時のどちらかを選択します。
3つめは、データの収集と蓄積のタイミングです。生成されたデータが利用できるようになるまで、どれだけのタイムラグを許容できるかで要件が決まります。
4つめは、エージェントプログラムの有無です。新たに構築するデータ基盤に対して、アプリケーションから直接データを書き込む場合は、アプリのソースコードを改修しなければなりません。そこで、アプリの改修を避けて、代わりにエージェントプログラムでデータを収集することが増えています。
5つめは、メッセージブローカーの有無です。これは、データ転送時のバッファーに相当します。大量の処理要求などによって、データストアのマシンリソースが食い潰されるのを防ぎます。現在は、データストアとアプリの間に、メッセージブローカーのような緩衝層を挟む設計パターンが増えてきました。
6つめは、データの欠損や重複の扱い方です。処理速度とデータの精度はトレードオフの関係にあります。そこで、どちらを優先するのかを決めておきます。
以上、6つの設計ポイントを紹介しました。それでは、1つずつ詳しく見ていきましょう。
クラウドサービスの利用が近道
データレイクは、あらゆるデータを蓄積する場所です。そのため、中核になるデータストア（ストレージ）には、（1）対応フォーマットの柔軟性、（2）スケーラビリティー、（3）APIの多様性／利便性、（4）RASIS、という4つの要件が求められます（図3）。
データレイクには、構造化データや半構造化データ、非構造化データなど、あらゆるデータを格納するため、様々なフォーマットに対応しなければなりません。また将来、蓄積するデータ量が増える可能性もあります。容易に保存容量を増やせるデータ基盤が理想的です。
データレイクが備えるAPIに多様性や利便性があることも重要です。APIを経由して、多様なシステムで発生するデータを蓄積できたり、蓄積されたデータを加工したりできれば、データ基盤を構築・運用するハードルが低くなるからです。基盤のRASIS（信頼性、可用性、保守性、保全性、安全性）も大切です。
一般的にオンプレミスでこれらの要件を満たすデータレイクを構築すると、高度な技術と高額な費用が必要です。そこで、これからデータレイク型のデータ基盤を構築する人には、クラウドベンダーが提供するオブジェクトストレージサービスの利用をお勧めします。例えば、Amazon Web Service（以下AWS）の「S3（Simple Storage Service）」や、米グーグル（Google）の「Cloud Storage」、米マイクロソフト（Microsoft）の「Data Lake Storage」、米オラクル（Oracle）の「Object Storage」などです。これらのサービスは、上記に挙げた要件を満たしつつ、安定性やデータ保全性までを担保しています。
オンプレミスあるいはクラウド上の仮想ホストにデータレイクを構築しなければならない場合は、「NoSQL」「分散KVS」「ドキュメントストア」といったデータストアを採用することになるでしょう。例えば、「Apache Hadoop」「Apache Cassandra」「MongoDB」などのOSSを利用したデータストアが有名です。
ただし、これらのOSSを使って大規模なデータ基盤を安定稼働させるには、相応のスキルを持った技術者を確保しなければなりません。技術者の確保が難しい場合は、OSSをそのままの形で提供するサービスや、API互換でマネージドサービスとしてクラウド上で提供するサービスを検討するとよいでしょう。
