Data Mühendisliği: Formula 1 İlhamlı Başlangıç Rehberi

Formula 1 racing. If you would like to

Data Mühendisliği: Formula 1 İlhamlı Başlangıç Rehberi

Başlangıç Seviyesinde Veri Mühendisliği İçin Kılavuz ve İlk Kez Kullanıcılara Yönelik Kullanım Alanları ile Birlikte Bir Sözlük

*Matteo Consoli*
*Towards Data Science*
*Matteo Consoli*
·

Veriyi anlatmanın en iyi yolu, kavramı örneklerle açıklamaktır. Bugün, veri katmanlarını bir örnekle – tahmin ettiğiniz gibi – anlatacağım.

İş Senaryosu ve Veri Mimarisi

Hayal edin: Gelecek yıl, gridde yeni bir ekip olan Red Thunder Racing, bizi (evet, beni ve seni) yeni veri altyapılarını kurmaları için çağıracak.

Günümüz Formula 1’inde veri, 20 veya 30 yıl öncesinden çok daha fazla önem taşıyor. Yarış takımları, milisaniye milisaniye iyileştirmeler yaparak olağanüstü bir veri odaklı yaklaşımla performanslarını artırıyorlar.

Çok Yüksek Seviyeli Tasarım

Bu sadece tur zamanıyla ilgili değil; Formula 1, çok milyar dolarlık bir iş. Taraftar etkileşimini artırmak sadece eğlence için değil; sporu daha çekici hale getirmek sürücülerin eğlencesi için değil. Bu faaliyetler gelir üretiyor.
Rekabet edebilmek için güçlü bir veri altyapısı olmazsa olmaz.

Üç temel katman olan Veri Gölü, Veri Depolama ve Veri Pazarı’na destek olacak bir veri mimarisi kuracağız.

Data Lake

Bir veri gölü, Formula 1 ekosistemi içinde çeşitli kaynaklardan üretilen ham ve yapılandırılmamış verilerin bir deposu olarak hizmet eder: araçlardan gelen telemetri verileri (örneğin, saniyede lastik basıncı, hız, yakıt tüketimi), sürücü konfigürasyonları, tur zamanları, hava koşulları, sosyal medya beslemeleri, bilet satışları, pazarlama etkinliklerine kayıtlı hayranlar, satın alınan ürünler, …

Tüm türde veri, konsolide veri gölümüze depolanabilir: yapılandırılmamış (ses, video, resimler), yarı yapılandırılmış (JSON, XML) ve yapılandırılmış (CSV, Parquet, AVRO).

Data Lake, Veri Entegrasyonu

Her şeyi tek bir yerde entegre etmek ve consolide etmek için ilk zorluğumuzla karşılaşacağız. Pazarlama araçlarından kayıtları çıkaran toplu işler oluşturacağız ve aynı zamanda gerçek zamanlı akış telemetri verileriyle uğraşacağız (ve emin olun, bu konuda çok düşük gecikme gereksinimleri olacak).
Entegreleyeceğimiz uzun bir sistem listemiz olacak ve her biri farklı bir protokol veya arayüzü destekleyecek: Kafka Streaming, SFTP, MQTT, REST API ve daha fazlası.
Bu veri toplama işinde yalnız olmayacağız; neyse ki, bu süreçleri yapılandırmak ve sürdürmek için benimseyebileceğimiz veri entegrasyon araçları mevcut (alfabetik sırayla: Fivetran, Hevo, Informatica, Segment, Stitch, Talend, …).
Krontab’da planlanan yüzlerce Python betiğine güvenmek yerine veya Kafka konularından veri akışını işleyen özel süreçlere sahip olmak yerine, bu araçlar bize tüm bu süreçleri basitleştirmemize, otomatikleştirmemize ve düzenlememize yardımcı olacaktır.

Veri Depolama

Entegre etmemiz gereken tüm veri akışlarını tanımladıktan birkaç hafta sonra, veri gölümüze çeşitli verileri işleyerek, temizleyerek ve depolayarak işlemlerimize devam ediyoruz. Bu, analitik ve raporlama için yapılandırılmış, yüksek performanslı bir ortam sağlayarak veri gölünden işlenmiş verileri temin eder.

Bu aşamada, veriyi içeri almaktan ziyade iş kullanım durumlarına daha fazla odaklanacağız. İş arkadaşlarımız tarafından nasıl kullanılacağını düşünmeliyiz ve düzenli olarak yenilenen, şu konularda yapılandırılmış veri setleri sunan:

– Araç Performansı: Telemetri verileri, birleştirilmiş bir görünüm sağlamak için temizlenir, normalleştirilir ve entegre edilir.
– Strateji ve Trend İncelemesi: Geçmiş yarış verileri, trendleri belirlemek, sürücü performansını anlamak ve belirli stratejilerin etkisini anlamak için kullanılır.
– Takım KPI: Pit stop süreleri, pit stop öncesi lastik sıcaklıkları, araç geliştirmelerinde bütçe kontrolü.

Veri Depolama ve Veri Dönüş