復元力のある大規模データ システムを設計する方法

データ システムを構築するときは常に、考慮すべきことが無数にあります。 すべてを MongoDB に押し込み、それを「Web スケール」と呼ぶ時代は終わりました。

このニュースレターでは、大規模なデータ システムを構築する際に考慮すべき考慮事項について説明します。

データ システムは、Uber アプリのように、ミリ秒のデータ遅延でリアルタイムに稼動することができます。 あるいは、データの遅延が 10 年になる米国の国勢調査のように、更新が信じられないほど遅い場合もあります。

なぜ Uber は米国国勢調査のようにシステムを設計しないのでしょうか? これは、10 年前に Uber を注文することが「通常の人間の行動」として分類されていないという事実と関係があると思います。

わかりましたが、その逆はどうでしょうか? なぜ米国国勢調査は Uber のようにデータ システムを設計しないのでしょうか? 人口に関する極めて最新の情報があれば有益ではないでしょうか?

米国国勢調査の場合、リアルタイム データのメリットは複雑さを管理するには十分ではありません。 すべての霊安室、病院、助産師が、「ああ、この人は亡くなった」または「ああ、この人は生まれた」と伝えるアプリが必要になると想像してみてください。 たとえプライバシーへの懸念を脇に置いたとしても、それを国全体で採用するのは、それほど大きなメリットがなければ非常に面倒でしょう。

これで、両方のデータ システムがそのように動作する理由について十分な理由があることがわかりました。

データ システムを構築する場合、どのテクノロジーを選択するかを決定する上で最も重要なニーズが 3 つあります。

• レイテンシ

  • データ システムのレイテンシを極めて低くする必要がある場合 (カットオフとして 10 秒未満)、システムを「プル」システムではなく「プッシュ」システムとして設計する必要があります。

    • プッシュ システムは、データが生成されるとデータ ストアにデータを送信することで機能します。 これの別名は、パブリッシュ アンド サブスクライブです。 プッシュ システムの一般的なテクノロジは Apache カフカ、アパッチ かなり、 Spark 構造化ストリーミング、 アパッチ ピノ、 そして クリックハウス。

    • プル システムは、ソース システムに定期的にクエリを実行し、データのバッチをデータ ストアに取り込むことで機能します。 一般に、データを取得する間隔は 10 秒より長くなります。 このため、プル システムは低遅延システムには適していません。 プル システムの一般的なテクノロジーは次のとおりです。 アパッチ・アイスバーグ、アパッチスパーク、 スノーフレーク、 BigQuery、 Apache エアフロー (または他のオーケストレーターのような 知事、 メイジ そして 日々)

• 正しさ

  • 多くの場合、データ品質もデータ システムの重要な部分です。 正確性の制約は、ACID 準拠と非常に密接に関係しています。

  • ACID準拠 は、データの正確性を維持するための強力なツールです。 これにより、「部分的な」または「不完全な」トランザクションがないこと、およびそれらのトランザクションに依存するすべての読み取りが待機する必要があることが保証されます。 ACID に完全に準拠したデータベースは、データの正確性の頂点です。 ACID への準拠は、「プッシュ」アーキテクチャよりも「プル」アーキテクチャでより一般的ですが、両方に実装できます。

  • ACID に反対するイデオロギーは次のとおりです。 ベース これは、データは利用可能ですが、正確性は「最終的に」しか保証されないことを意味します。 一般に、正確性が非常に優先される場合は、BASE システムではなく ACID システムを選択することになります。

• スケーラビリティ

  • スケーラブルなデータ システムは、データ セットの分割を可能にするシステムです。 NoSQL ファミリの良い例としては、Cassandra、MongoDB、DynamoDB があります。 MySQL のようにシャーディング可能な SQL データベースは、NoSQL クラスのデータベースと似てはいるものの、異なる方法で機能することもできます。

  • バッチ データ パイプラインの世界における低遅延クエリは実際には重要ではないため、多くのデータ エンジニアリング クエリはこれらの制約を気にしないことに留意してください。

  • スケーラビリティと正確性は、多くの場合トレードオフの関係にあります。 このトレードオフは、CAP 定理で非常にわかりやすく説明されています。 Cassandra のような「最終的に一貫性のある」システムは、十分な時間があれば正しい結果を返します。

  • CAP 定理によると、通常 3 種類のデータ ストアがあります。

    • 一貫性と可用性 (つまり CA) システム (Postgres など)

    • 可用性とパーティション トレラント (AP) システム (Cassandra など)

    • 一貫性のあるパーティション トレラント (つまり CP) システム (MongoDB など)

プッシュとプルは、データ アーキテクチャの世界におけるペプシとコーラのようなものです。 ビッグテクノロジーでの私の経験では、最も重要なシステムのいくつかがプル アーキテクチャからプッシュ アーキテクチャに移行するのを見てきました。 私はまた、これらの移行のいくつかが見事に失敗するのを見てきました。

プッシュ アーキテクチャはソフトウェア エンジニアの親友です。 データが到着したときに処理するだけであり、データの奇妙な再処理は必要ありません。

プル アーキテクチャはデータ エンジニアの親友です。 定義されたバッチでデータを処理し、バッチ全体のデータ品質チェックで「正常」または「異常」として定量化できます。

これにより、次のことがわかります。 Lambda アーキテクチャと Kappa アーキテクチャ 議論。

データ エンジニアは、品質保証がかなり悪いため、プッシュをあまり好みません。 ソフトウェア エンジニアは、遅延がひどいため、プルを好みません。

これを調整するには 3 つの方法があります。

• ラムダアーキテクチャ

  • Kafka と Flink/Spark Streaming を活用してレイテンシーを最適化するプッシュベースのパイプラインを用意する

  • 正確性を最適化する Iceberg と Spark を活用する別のプルベースのパイプラインを用意する

  • このアーキテクチャを使用すると、複雑さの中に痛みを感じます。 のような派手なフレームワークを使用しない限り、 アパッチビーム これにより、パイプラインをバッチ モードとストリーミング モードの間で切り替えることができます。

    • 私が Netflix で働いていたとき、Beam がサイバーセキュリティの問題に対する特効薬になるだろうと考えていました。 私たちが発見した問題は、より高いレベルの抽象化によりパフォーマンスのチューニングがはるかに困難になったことでした。そのため、コードははるかに多いものの、日常のメンテナンスが容易な Spark と Flink を選択しました。

• カッパ建築

  • Kafka と Flink/Spark Streaming を活用してレイテンシーを最適化するプッシュベースのパイプラインを用意する

  • ストリーミング ジョブに対してイベントを「再生」できるため、Kafka のような高価なストレージにすべてを保持する必要がなく、バックフィル機能を利用できます。 この再生機能は、新しい「コールド」データ ストア Iceberg に追加されました。 デルタ湖 そしてヒューディ。

  • Kappa アーキテクチャは、正確さにおいて失われたものをシンプルさによって補います。 ただし、新しいイベント リプレイ機能により、バックフィル機能により不正なデータが再記述される可能性があるため、正確性のトレードオフに耐えるのがはるかに容易になります。

• プル専用アーキテクチャ

  • Iceberg と Spark を活用したプルベースのパイプラインを備え、優れたデータ品質チェックで正確性を最適化します。

  • 大手テクノロジー企業のデータ エンジニアとしては、これが最も一般的なアーキテクチャです。なぜなら、低レイテンシの制約は実際にはかなり珍しいからです。

大規模なデータ システムには、次のコンポーネントが含まれることがよくあります。

• 多くの場所に大量のデータが存在する大規模なシャード化されたソース システム

• データレイク (通常は Iceberg、Delta Lake、Hudi、または Hive)

• 低レイテンシの分析ストア (通常は Druid)

非常に高品質の分析データを取得する手順は次のとおりです。

1. シャード化された場所からすべてのデータを取得するには、すべてのシャードにクエリを実行してデータ セット全体をデータ レイクに再度まとめる「毎日のスナップショット」タスクが必要です。

2. 高品質のマスター データを作成するために必要な、レイク内の他の入力データとともに毎日のスナップショット データを取得します。 必ず実装してください 書き込み-監査-公開パターン マスター データを書き出すとき、多くの人がマスター データに依存するため、悪いデータを公開すると会社が悲しくなります。

3. マスター データを取得したら、その上で集計を行う分析パイプラインを作成し、そのデータを Druid などの低レイテンシー ストアにアップロードします。

4. アナリストに Druid データをダッシュボードに読み取らせたり、顧客が表示できるようにアプリに再統合したりできます。

目の前のタスクに適切なテクノロジーを決定することは、恐ろしいと感じるかもしれません。 レイテンシー、正確性、スケーラビリティのバランスをとる方法を学ぶことで、より自信のあるエンジニアになったように感じられるでしょう。

今年の 5 月 6 日に開始される次回のブートキャンプでは、データ アーキテクチャと機械学習システムについて説明する予定です。 現在、先着 50 名様が 20% オフになる早期割引を実施中です。 コードを使用する アーリーバードDV4 チェックアウト時 データエンジニア.io 2 月 9 日までにブート キャンプ全体を他のブート キャンプよりも低価格で手に入れましょう!

これらのニュースレターで他にどのようなトピックについて話してほしいですか? この議論に何か追加したいことはありますか? 建築の話をするのが大好きです！