פיתוח מערכת שכפול נתוני שוק על Kafka

בוט המסחר שלך רץ על שרתים קרובים לבורסה. ניהול הסיכונים זקוק לאותם נתונים במרכז נתונים מעבר לאוקיינוס. העברת קבצים פשוטה לא עובדת: זמן ההשהיה גדל לשניות, ואובדן הנתונים מגיע ל-8% מהטיקים בערוץ לא יציב. נתקלנו במקרה שבו לקוח איבד עד 5% מהטיקים עקב קישור לא יציב בין ניו יורק לטוקיו. אתה זקוק לשכפול מבוזר בזמן אמת שיכול להתמודד עם מאות אלפי הודעות בשנייה מבלי לאבד טיק אחד. שכפול מבוסס Apache Kafka מפחית את ההפסדים לאפס ומבטיח עקביות בכל הצמתים. הזמן שכפול שלא ייכשל.

אנו מתכננים ומפעילים מערכות שכפול נתוני שוק במפתח פתוח. המחסנית שלנו היא Apache Kafka כבסיס אמין, MirrorMaker 2 לשכפול בין-אזורי, ו-Confluent Schema Registry לאבולוציית פורמט. במהלך 10+ השנים האחרונות, סיפקנו מעל 30 פרויקטים לקרנות קריפטו, יצרני שוק וחברות מסחר פרטיות. תוצאה: הפחתת עלויות תשתית בעד 40% וקיצור זמן השבתה ב-80%. לקוחות חוסכים בממוצע 15,000 דולר בחודש על תשתית על ידי איחוד זרמים.

במאמר זה, נפרק כיצד לבנות מערכת שכפול, אילו טופולוגיות לבחור, כיצד להבטיח עקביות, וכיצד להימנע ממלכודות טיפוסיות.

למה יש צורך בשכפול

מערכת מסחר מורכבת ממספר רכיבים הפועלים בסביבות שונות:

• מסחר ייצור — קולוקציה ליד הבורסה, זמן השהיה מינימלי.
• מחקר/בדיקות חוזרות — מרכז נתונים עם נפחי אחסון גדולים.
• ניהול סיכונים — רשת מבודדת עם גישה מוגבלת.
• לוחות מחוונים אנליטיים — נגישים לקהל רחב.

כל סביבה חייבת לקבל זרם נתונים זהה מבלי להעמיס על המקור. שכפול פותר זאת על ידי הבטחת עקביות, סובלנות לתקלות ומדרגיות.

טופולוגיות שכפול

לייצור, אנו ממליצים על Pub-Sub דרך Kafka — זו אפשרות גמישה שמתרחבת בקלות. Apache Kafka מספק החלפת הודעות עמידה, מדרגית וסובלנית לתקלות.

כיצד להבטיח עקביות במהלך שכפול

עקביות היא האתגר המרכזי בשכפול מבוזר. אנו פותרים זאת עם שילוב של צרכנים אידמפוטנטיים ועסקאות אטומיות. צרכנים מסירים כפילויות לפי מפתחות כמו trade_id או update_id. עבור זרמים קריטיים (ניהול סיכונים), אנו משתמשים במשלוח בדיוק-פעם אחת דרך Kafka Transactions.

from confluent_kafka import Producer
producer = Producer({
    'bootstrap.servers': 'kafka:9092',
    'enable.idempotence': True,
    'transactional.id': 'market-data-producer-1',
    'acks': 'all'
})
producer.init_transactions()

def publish_trade_batch(trades: list[Trade]):
    producer.begin_transaction()
    try:
        for trade in trades:
            producer.produce(
                topic=f'market.trades.{trade.exchange}.{trade.symbol}',
                key=trade.symbol.encode(),
                value=serialize(trade)
            )
        producer.commit_transaction()
    except Exception as e:
        producer.abort_transaction()
        raise

למה Kafka הוא התקן לשכפול נתוני שוק

Apache Kafka מספק את כל התכונות הנדרשות: עמידות (נתונים מאוחסנים בדיסק), מדרגיות (חלוקה אופקית), ועצמאות של קבוצות צרכנים. אנו מגדירים נושאים עם שמות כמו from confluent_kafka import Producer producer = Producer({ 'bootstrap.servers': 'kafka:9092', 'enable.idempotence': True, 'transactional.id': 'market-data-producer-1', 'acks': 'all' }) producer.init_transactions() def publish_trade_batch(trades: list[Trade]): producer.begin_transaction() try: for trade in trades: producer.produce( topic=f'market.trades.{trade.exchange}.{trade.symbol}', key=trade.symbol.encode(), value=serialize(trade) ) producer.commit_transaction() except Exception as e: producer.abort_transaction() raise , מה שמקל על סינון נתונים.

Topic: market.trades.binance.BTCUSDT Partition 0: trades (all, ordered by time)
Topic: market.orderbook.binance.BTCUSDT Partition 0: snapshots + diffs (ordered by update_id)
Topic: market.candles.binance.BTCUSDT.1m Partition 0: 1-minute OHLCV (ordered by candle time)

הבטחות משלוח ושכפול בין מרכזי נתונים

במערכות נתוני שוק, משלוח לפחות-פעם אחת הוא הנפוץ ביותר: עדיף לקבל כפילות מאשר לאבד נתונים. צרכנים הם אידמפוטנטיים — הסרת כפילויות לפי {data_type}.{exchange}.{symbol}.{interval} או Topic: market.trades.binance.BTCUSDT Partition 0: trades (all, ordered by time) Topic: market.orderbook.binance.BTCUSDT Partition 0: snapshots + diffs (ordered by update_id) Topic: market.candles.binance.BTCUSDT.1m Partition 0: 1-minute OHLCV (ordered by candle time) . עבור ניהול סיכונים וחשבונאות פוזיציות, אנו מאפשרים בדיוק-פעם אחת דרך Kafka Transactions.

Kafka MirrorMaker 2 משכפל נושאים בין אשכולות. דוגמה לתצורת MirrorMaker 2:

---
# mirrormaker2.properties
clusters = us-east, eu-west
us-east.bootstrap.servers = kafka-us:9092
eu-west.bootstrap.servers = kafka-eu:9092
us-east->eu-west.enabled = true
us-east->eu-west.topics = market\.*
us-east->eu-west.replication.factor = 2

אשכול האיחוד האירופי מקבל רפליקה של כל הנושאים market.* עם השהיה של 50–200 אלפיות השנייה לשכפול טרנס-אטלנטי. זה מספיק לרוב מערכות האנליטיקה והסיכון.

ניהול שמירה וניטור

נתוני שוק מצטברים במהירות. מדיניות שמירה:

• לנתוני טיקים: 7 ימים, ואז מחיקה.
• ל-OHLCV יומי: אינסופי, עם מגבלת גודל של 10 GB לכל מחיצה.
• לספר הזמנות: דחיסת לוג — שמירת המצב העדכני ביותר בלבד לכל רמת מחיר.

דחיסת zstd מפחיתה נתונים ב-40–70% ללא עומס CPU ניכר. מדדי ניטור מרכזיים:

פיגור צרכן > 5 דקות עבור בוט מסחר הוא התראה קריטית. עבור מערכת אנליטית, זו אזהרה.

Schema Registry ותאימות פורמט

כדי להימנע משבירת צרכנים כאשר הסכמה מתפתחת, אנו משתמשים ב-Confluent Schema Registry ו-Avro. שדות אופציונליים חדשים עם ערך null ברירת מחדל הם שינויים תואמים לאחור.

{ "type": "record", "name": "Trade", "namespace": "com.exchange.market", "fields": [
    {"name": "exchange", "type": "string"},
    {"name": "symbol", "type": "string"},
    {"name": "timestamp", "type": "long"},
    {"name": "price", "type": {"type": "bytes", "logicalType": "decimal", "precision": 24, "scale": 8}},
    {"name": "quantity", "type": {"type": "bytes", "logicalType": "decimal", "precision": 24, "scale": 8}},
    {"name": "side", "type": {"type": "enum", "name": "Side", "symbols": ["BUY", "SELL"]}},
    {"name": "is_maker", "type": ["null", "boolean"], "default": null}
  ]
}

מה כלול בעבודה

• תיעוד ארכיטקטוני: תיאור טופולוגיה, דיאגרמת זרימת נתונים, מפרט נושאים.
• גישה לתשתית: הגדרת אשכולות Kafka, MirrorMaker, Schema Registry.
• הכשרת צוות: סדנה על תפעול וניטור.
• תמיכה לאחר השקה: סיוע במהלך השבועיים הראשונים של פעילות ייצור.

כיצד אנו מפעילים שכפול: תוכנית שלב אחר שלב

1. ניתוח דרישות: נפח נתונים (עד 100,000 הודעות/שנייה), זמן השהיה, הבטחות משלוח, מספר מרכזי נתונים.
2. עיצוב טופולוגיה: בחירה בין Hub-and-Spoke, שרשרת, או Pub-Sub.
3. הפעלת אשכול Kafka (3 עד 7 ברוקרים) עם MirrorMaker 2 ו-Schema Registry.
4. הגדרת נושאים ומדיניות שמירה.
5. שילוב צרכנים עם אידמפוטנטיות והסרת כפילויות.
6. הגדרת ניטור (פיגור צרכן, זמן השהיה) והתראות.
7. בדיקה עם נתונים סינתטיים ועומסים אמיתיים.
8. תיעוד ומסירה לצוות הלקוח.

במהלך התהליך, אנו מוודאים: אידמפוטנטיות יצרן, הגדרות עסקאות, עקביות שמירה בין אשכולות, פונקציונליות הסרת כפילויות, והיעדר כפילויות.

לוחות זמנים ועלות

יישום בסיסי לוקח 7 עד 14 ימים: אנליטיקה, הפעלת אשכול, הגדרת MirrorMaker 2 ו-Schema Registry, ניטור. פתרון מלא המשולב בתשתית שלך לוקח עד 4 שבועות. העלות מחושבת באופן אישי: תלויה בנפח נתונים, מספר מרכזי נתונים, והבטחות המשלוח הנדרשות. צור קשר כדי להעריך את הפרויקט שלך ולקבל ייעוץ. הזמן פיתוח מערכת שכפול למשימות שלך — ואנו נבטיח משלוח נתונים אמין.