エンジニアの理想の世界では、建築は常に美しい。大規模なシステムの現実世界では、妥協しなければならない。 trade-off between Write Speed and Read Speed. 通常、あなたは互いに犠牲にしますが、私たちのケースでは、AWS でのペタバイトのデータで作業すると、この妥協は私たちのスピードに影響を与えませんでした。 . wallet データを完璧に書き込むシステムを構築しましたが、アーカイブから読み込むたびに予算が最も苦痛な方法で燃え上がりました。AWSからペタバイトを読み込むと、データ転送、リクエスト数、ストレージクラスリハーサルにはお金がかかります。 これは、より効率的でコスト効率的にするためにどのように最適化したかというストーリーです! Part 0: How We Ended Up Spending $100,000 in AWS Fees! 実際の話:数ヶ月前に、当社のソリューションアーキテクターの1人は、稀有でトラフィックが低いウェブサイトからサンプルを輸出して、製品を潜在的なクライアントにデモンストレーションしようとしました。 この「珍しい」サイトのデータが数百万のアーカイブに散らばっていたため、トラフィックの高いサイトとともに、システムは私たちの歴史的ストレージ全体のほぼ半分を復元して、それらのわずかなページを見つけるために試みました。 この正直なミスは私たちにコストをかかるようになった $100,000 in AWS fees! すぐにAPIのバグを修正しました(そして厳格な制限を追加しました)、しかし、建築の脆弱性は残っていました。 Bright Dataの物語をお伝えします。 アーキテクチャ:私はどのようにしてシステムを「安価な」ストレージのに追い込んだか、そしてどのようにしてシステムを使用して脱出したか . WEB ファイル Rearrange Pipeline WEB ファイル WEB ファイル 第1部「最初に書く」遺産 私がWebアーカイブで仕事を始めたとき、システムはすでに膨大なデータストリームを吸収していました:毎分数百万のリクエスト、毎日数十テラバイトです。 それは、高流量システムのための最も持続可能な戦略に依存しました。 Append-only Log. 
 
 
 
 
 データ(HTML、JSON)がバッファされます。 バッファが ~300 MB に達すると、それは TAR アーカイブに「密封」されます。 ファイルはS3に移行します。 3日後、ファイルは S3 Glacier Deep Archive に移動します。 Deep Archive でデータを格納するにはペニーがかかりますが、書き込みのスループットはほぼ無制限です。 タイトル: That Pricing Nuance アーキテクチャは書くのに完璧に機能していました...クライアントが歴史的なデータを求めて来るまででした。 
 
 
 The System Writes by Time: An archive from 12:00 PM contains a mix of cnn.com, google.com, and shop.xyz. システムは時間によって書かれています。 システムはドメインで読みます:クライアントは「過去1年間のcnn.comのすべてのページを私に与えてください」と尋ねます。 この記事にインスピレーションを与えたミスがここにあります。多くのエンジニアと同様に、私は考えることに慣れています。 しかし、私はそのことを無視した。 . latency, IOPS, and throughput AWS Glacier billing model 「何千ものアーカイブをダウンロードすることは遅い(48時間)、しかしそれほど高価ではない」と私は思った。 AWS は API 呼び出しだけでなく、 (GBあたり1ドル) The Reality: volume of data restored 「ゴールデンバイト」効果 クライアントが単一のドメインから1000ページのリクエストを提出することを想像してください. Because the writing logic was chronological, these pages can be spread across 1,000 different TAR archives. クライアントにこの50MBの有用なデータを提供するには、災害が起こります。 
 
 
 
 
 システムは1000ファイルの復元を起動する必要があります。 300GBのデータを「冷凍庫」から取り出します(1000アーカイブ×300MB)。 AWSは300GBの復元を請求します。 必要な 50 MB を抽出し、残りの 299.95 GB を投げ捨てます。 我々はゴミのテラバイトを回復するために金の穀物を抽出するために支払っていた。 金融のブラックホールとなった。 Data Locality Part 2: Fixing the Error: The Rearrange Pipeline (エラーを修正する:パイプラインの再編) 入力方法を迅速に変更することはできませんでした - 入力ストリームは「飛び回り」に分類するにはあまりにも並列的で巨大です(私はそれに取り組んでいますが)、既にアーカイブされたデータにも機能するソリューションが必要でした。 したがって、I designed the , 背景プロセスは、アーカイブを「分解」します。 Rearrange Pipeline これは、いくつかの重要なコアコンポーネントを含む、非同期のETL(Extract, Transform, Load)プロセスです。 
 
 
 
 
 
 
  It makes no sense to sort data that clients aren’t asking for. Thus, I direct all new data into the pipeline, as well as data that clients have specifically asked to restore. We overpay for the retrieval the first time, but it never happens a second time. Selection: 
 
  Multiple workers download unsorted files in parallel and organize buffers by domain. Since the system is asynchronous, I don’t worry about the incoming stream overloading memory. The workers handle the load at their own pace. Shuffling (Grouping): 
 
 
  I write the sorted files back to S3 under a new prefix (to distinguish sorted files from raw ones). Rewriting: 
 
 
 Before:   →  2024/05/05/random_id_ts.tar [cnn, google, zara, cnn] After:   →  2024/05/05/cnn/random_id_ts.tar [cnn, cnn, cnn...]  
 
 
  In Snowflake, the metadata table is append-only. Doing   or   is prohibitively expensive. Metadata Swap: MERGE INTO UPDATE 
 
 The Solution: I found it was far more efficient to take all records for a specific day, write them to a separate table using a JOIN, delete the original day’s records, and insert the entire day back with the modified records. I managed to process   in just a few hours on a 4X-Large Snowflake warehouse. 300+ days and 160+ billion UPDATE operations 結果 この変更は、製品の経済学を根本的に変えた: 
 
 
 
 Pinpoint Accuracy: クライアントが cnn.com を要求すると、システムは cnn.com が住んでいるデータのみを復元します。 効率性:リクエストの細部性(regex 経由でドメイン入力と特定の URL を入力)に応じて、「ゴミデータ」の回収率を10%～80%減らすことができました(これはコストに直接比例しています)。 新たな能力:ゴミの節約だけを超えて、これは完全に新しいビジネス使用ケースを解除しました。歴史的データの回収はもはや苦しむほど高価ではありませんので、私たちは今、AIモデルの訓練、長期的な市場調査を実施するための大規模なデータセットを抽出し、代理人AIシステムのための知識ベースを構築することができます(専門的な検索エンジンを考えてください)。 われわれは雇う Bright Data は Web Archive をさらに拡張しています. If you like: 
 
 
 
 
 
 高い分散型システム、 大規模なデータエンジニアリング、 現実世界の負荷下で信頼できるパイプラインを構築し、 Node.js を絶対的な限界まで押し上げ、 教科書に載っていない問題を解決するには、 その後、話すのが好きです。 私たちは、次世代のWebアーカイブを構築するのに役立つ強力なNode.jsエンジニアを雇っています。データエンジニアリングとETLの経験は非常に有利です。 . ブリッジデータ@brightdata.com ブリッジデータ@brightdata.com ブリッジデータ@brightdata.com 私がアーカイブを拡張し続けるにつれてより多くのアップデートが来る――そしてそれを破るための新しい創造的な方法を見つけるにつれて!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

2022 - HackerNoon Contributor of the Year - Amazon

Request Your Own Data

Nominated for 2022 - HackerNoon Contributor of the Year - Amazon

このオーディオは、ストーリーの元の言語で制作されています。

Petabyte Scale Web Archiveの作成

About Author

コメント

ラベル

この記事は

Related Stories

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps