Building our Data Platform: Why we have chosen Databricks over Snowflakeの翻訳です。
DeNexusにおいて、我々は重要なインフラストラクチャに悪影響を及ぼすサイバーリスクの課題を解決しており、世界中の保険を引き受けている保険事業者でもあります。
課題：信頼できるデータ
重要なインフラストラクチャは空港、電力ライン、分電センター以上のものとなります。これには、複雑なオペレーショナルテクノロジー(OT)、ITネットワーク、ICS、エンタープライズソフトウェアおよび人材が含まれます。
さらに、重要なインフラストラクチャはこれまで以上のサイバーセキュリティリスクにさらされています。過去5年において、エネルギー、再生可能品、製造、交通、サプライチェーンエコシステムなど全てが、増加するランサムウェア、マルウェアの攻撃の犠牲者となっています。過去2年のみで、ICS、OTをターゲットとしたランサムウェアの攻撃は500%以上に増加しました。サイバーリスクの課題は高くつくものであり、おそらく、この現象を表現する膨大なデータを用いることでしか、必要となる費用を削減することはできないでしょう。
DeNexusでは、プロプライエタリなリスク検知アルゴリズムを開発、トレーニングするのに必要なデータを収集、格納し、高度にスケーラブルなリスク検知SaaSプラットフォームDeRISKからクライアントがセキュア、効率的、柔軟に利用することで本格利用でききるように、プロプライエタリなデータレイクであるDeNexusナレッジセンターを構築しました。
図1:DeNexusナレッジセンター
DeNexusの要件
- 様々なタイプのユーザーにデータアクセスを許可：上級ユーザー(複雑な変換処理を活用)および基本ユーザー(SQLのみを使える)
- 強力なデータバージョン管理：先進的なモデリングにおいて、特定のファイル、テーブルのバージョンが変更されていないことを確実にする機能。以前のバージョンのデータへのアクセス、利用が容易になるように、データレイクにおける過去のすべてのトランザクションは記録される必要がある。
- 様々なデータのサポート：構造化、非構造化、準構造化データおよび、DeRISKでやりとりしているビジネスインテリジェンスのデータソースでサポートされている様々なデータフォーマットのサポート。
- 高いスケーラビリティ：データ量が急激に増加しており、ペタバイト規模のデータに対応できる必要がある。「無限に対するデザイン：十分大きいことは常に十分良いとは限らない」
- インフラストラクチャの権限移譲：内製の人的資産の活用を最適化するために、ソリューションは(可能な限り)SaaSあるいはPaaSである必要がある。
- ML-OPS：データレイクの主な用途の一つはモデルのアプリケーションを通じたデータの活用である。プロダクションのデプロイメントを加速し、開発を円滑にするために、ベストプラクティスの基準としてML-OPSパラダイムに従う必要がある。
- 強力なセキュリティ、コンプライアンス機能：データストレージは柔軟かつ動的である必要がある。
マーケットにある既存のソリューションを評価したのち、よく知られているデータウェアハウスコンセプトに基づくソリューションは除外されました。ParquetやAvroのようなフォーマットやSpark、Presto/Trinoのようなツールによって提供される高速データアクセスが実現されている中、データレイクとデータウェアハウスを区別することにいまだ意味はあるのでしょうか？これはユースケースに依存しますが、我々の場合そうではありませんでした。なぜでしょうか？我々のメインのデータソースはSQL Server、PostgreSQL、MySQLなどのRDBMSシステム由来のものではありませんでした。実際のところ、データプラットフォームを移行せずにスクラッチで開発したので、我々のデータは元々はあちらこちらから集められたものとなっています。
Bill Inmonは最近同じような見解を述べています。
まず初めに、我々は「データレイク」と呼ばれる穴に全てのデータを投げ込みました。しかし、穴にデータを投げ込むことは意味のないことだとすぐに気づきました。データを有効活用、分析されるようにするためには、データはそれぞれ関連づけられ、分析インフラストラクチャが注意深く準備され、エンドユーザーが利用できるようになる必要があります。これら2の条件が満たされない場合、データレイクはスワンプ(沼)となり、しばらくするとスワンプは臭いを放ち始めるでしょう。分析におけるこれらの評価指標を満たさないデータレイクは、時間とお金の無駄となります - Building the Data Lakehouse By Bill Inmon
ソリューション：データレイクハウス
我々はデータウェアハス(ACID互換性、データのバージョン管理、最適化技術)とデータレイク(低コストのストレージ、様々なデータフォーマットのサポート)のキーとなる利点を組み合わせたデータ管理システムを必要としていましたので、データレイクハウスのネイティブの実装と、以下のセクションで説明するような理由から、データレイクハウスプラットフォームとDatabricksを選択しました。
図2:データウェアハウス：データレイク - データレイクハウスの比較
データウェアハウス(DWH)では機械学習(ML)アルゴリズムはうまく動作しません。通常小規模のデータを抽出するBIクエリーとは異なり、これらのMLアルゴリズムはSQLを使うことなしに大規模なデータセットを処理します(XGBoost、Pytorch、TensorFlow...)。定常的なデータ型の変換によってデータの読み込みは非効率的なものであり、データウェアハウスで使用されているプロプライエタリな内部データフォーマットとの直接的な互換性がないケースがないケースが多くあります。これらのユースケースにおいては、データはオープンなデータフォーマットのフォイルとしてエクスポートされますが、これにより追加のETLステップが発生し、複雑性を増加させ、データの鮮度を低下させます。
Snowflakeのようにデータレイクフォーマット(オープンデータフォーマット)の外部テーブルの読み込みをサポートしている「クラウドネイティブ」のデータウェアハウスもデータレイクハウスアプローチを実装しているという議論があるかもしれませんが、
- 彼らのメインのデータソースは彼らの内部データであり、いくつかのケースにおいては依然としてETLパイプラインが必要となります(管理すべきプロセスと、失敗が起こりうるポイントを追加することになります)。
- 彼らが内部データに対して提供しているのと同じ管理機能(例：トランザクション、インデックス...)を、データレイクのデータに対して提供することはできません。
- 彼らのSQLエンジンは、彼らの内部フォーマットに対するクエリーに対してほとんどが最適化されています。
さらに、データレイクストレージのデータに直接クエリーを行うために単一のツールを利用した場合、通常のデータウェアハウスが持っているデータ機能の欠如(例：ACIDトランザクション、インデックス...)から、全体的なデータ問題を解決しません。
図3:DeNexusデータプラットフォーム
なぜ我々の要件に合致したのか？
様々なタイプのユーザーにデータアクセスを許可: データにアクセするためにSQLを用いるには、誰かが生データに対して構造を付与するプロセスを実行する必要があります。シンプルなSQLでこのような変換処理が可能でしょうか？答えはYESですが、色々と大変です...
SQLは特定のことに対しては威力を発揮しますが、汎用プログラミング言語ではないため、それ以外では効果が出せません。我々はDeRISKの製品ロードマップの実装において必要となる変換処理の完全なスコープがわからなかったので、汎用性を優先する決断をしました：DatabricksはSpark、Python、Scala、Java、R、そしてSQL！の実行を可能とします。このため、様々なタイプのユーザーによって活用することができます。やったね！
強力なデータバージョン管理 -> Delta DatabricksはネイティブでDELTAフォーマットを実装しています。これによって、SparkにACIDとの互換性がないという主要な課題の一つを解決します(DeltaはACIDと完全互換です)。さらに、これによってパイプラインでエラーが起きた際のシステムリカバリーを可能とし、モデル開発の際に常に同じデータが使用されていることを保証するシンプルな方法(データのバージョン管理)を提供します。さらに、Deltaは完全にオープンソースです。
(Sparkなど)Databricksによって様々なタイプのデータ(構造化、準構造化、非構造化データ)、データフォーマットを取り扱えるようになります：
さらに、Sparkが特定のフォーマットをサポートしていない場合、マニュアルでコネクターを開発(Sparkは完全にオープンソースです)するか、ネイティブのPython、Scala、R、Javaライブラリを使用することができます(DatabricksはマネージドSpark以上のものです)。
DatabricksのPaaSの特性はスケーラビリティと密接な関係にあり、我々のデータプラットフォームの全てのクラウドリソースを活用できます。増加するストレージの要求にはS3が応え、新規環境が必要なった際(新たなデータサイエンティストがチームにジョインした場合、ローカルマシンで環境を構築する必要はありません)やより多くの処理パワーが必要になった際には、Databricksによって直接対応することができ、非常に価値のあるリソースであるソフトウェアエンジニアの多くの時間を解放することができます。何台のマシンが動作しているのか、どのような機能を使っているのかに関して、常に詳細なコントロールを行うことができます(そして、請求に驚くことがなくなります！)。
さらに、SparkのDBR(SparkのDatabricks実装)は通常のSparkよりはるかに高速であり、これはDatabricksランタイムに追加の料金を支払う価値があるものです。
図4:オープンソースSpark vs Spark DBR(画像をクリックするとYouTubeに移動します)
完全なML-OpsソリューションとしてのDatabricks + マネージドMLflowがモデル開発環境と機械学習ライフサイクル全体のためのプラットフォームを提供します。
もともとDatabricksがMLflowを開発し、Linuxファウンデーションに寄贈しました。
GitHub - mlflow/mlflow: 機械学習ライフサイクルのためのオープンソースプラットフォーム
これにより、データサイエンティストは実験に用いたテーブルのバージョンを容易にトラッキングでき、後ほどそのバージョンのデータを使って再現させることができます。さらに、同僚とモデルやコードを容易に共有できるコラボレーティブな環境を提供します。
Azure-MLやAWS SageMakerのような他のMLプラットフォームと組み合わせて活用することもできます：DatabricksのマネージドMLflowに登録されたモデルを、Azure-MLやAWS SageMakerで簡単に使用することができます。
さらに、DatabricksマネージドMLflowを活用することで、データサイエンティストはSpark MLやKoalas(SparkにおけるPandas実装)を用いることで簡単にアルゴリズムを並列化することができます。
**データストレージと計算レイヤーは完全に分離されます。**データはどのような場所にあっても構わなく、それらを処理するためにDatabricksを活用することができます(計算とストレージの分離)。プロプライエタリなフォーマットやツールを使う必要がないので、データを移行する際に高い柔軟性を保つことができます。
まとめ
本書の最初の図(図3)では、データの3つのステージとそれぞれで用いるツールを示しています。
- Data Processing(データ処理): Databricks、Python+AWS Lambda、EC2
- Data Discoverability(データの検索): Databricks、AWS Athena
- ML-Ops: Databricks、AWS SageMaker
1つだけ共通しているものがあります：Databricksの活用です。
さらに、ここにはベンダーロックインは存在せず、従量課金モデルによって、現時点では明らかになっていなくても将来的には直面するであろう特定のシナリオに対する代替策を持つことが可能となります。
図5:全てを統治するデータプラットフォーム