Modern Data Stack
Veri bilimi ve analitik dünyasındaki araç ve platformların ekosistemi son on yılda çok değişti. Bu da sıfırdan yeni bir mimari oluşturmayı ve birleştirmeyi çok eğlenceli ama aynı zamanda biraz korkutucu hale getiriyor. Bu nedenle Tapu.com’daki veri yığınımız için seçtiğimiz araçları, bu araçlarla uyguladığımız metodları ve yol boyunca öğrendiklerimizden bazılarını paylaşmak istedim.
Bu yolculuğa, Kasım 2021'de başladık.
Mimarimizdeki araçlardan herhangi birini seçmeden önce, bize rehberlik edecek bazı net hedefler belirledik. Çünkü seçtiğimiz temel teknolojilerin uzun vadede yeteneklerimizin çoğunu belirleyeceğini biliyorduk.
Kullanacağımız teknolojileri seçerken 2 temel ilke göz önünde bulundurduk.
Veri Mimarimiz :
1. Business açısından kritik olan raporlamaları desteklemelidir.
Veriler şirket kültürümüz için çok önemlidir. Veri odaklı bir iş yapıldığından dolayı teknik olsun ya da olmasın her ekip her yönetici karar verirken analiz ve KPI referansı ile işlerine başlar.
Kaliteli, iyi ve erişilebilir veriler bu sürecin can damarıdır. Güvenilir ölçümler olmadan başarılı olup olmadığımızı anlamanın bir yolu yoktur. Veri mimarimiz, bu raporlamanın büyük çoğunluğunu destekler.
2. Veri bilimini desteklemesi gerekir.
Kullanıcılarımız için geniş ölçekte mükemmel bir ürün oluşturmak için şirketin her yapı taşının veri bilimi felsefesi ile yoğrulması gerektiğini başından beri biliyorduk.
Veri Bilimi ve Makine Öğrenmesi işleri Tapu.com için kritik önem taşımaktadır. Analiz projelerimizin çıktılarının her birinin, anlam ve değer üretmesi karşılığında “Makine Öğrenmesi” sürecine girmesi hedefimizdir.
İlk olarak, dahili raporlama için sağlam bir temel oluşturarak başlıyoruz. İkinci olarak, bu temeli, uygulamamızın kendisinde analitik yetenekler oluşturmak için kullanıyoruz. Bu “veri bilimi yolculuğu”, aşağıda gösterilen Veri Bilimi İhtiyaçlar Hiyerarşisinde güzel bir şekilde özetlenmiştir:
Veri mimarimizi oluşturmanın amacı, bu piramidin en alttaki dört bölümünü (ve beşinci bölümün bazılarını) oluşturmaktı. Peki… bunu nasıl yaptık?
Kullandığımız araçlar :
Yukarıdaki mimari diyagram, veri mimarimizin ve son derece hızlı hareket etmemize yardımcı olan iş ortaklarının ekosisteminin üst düzey, bütünsel bir görünümünü göstermektedir. Bu mimarinin bileşenlerini kısaca özetlemek gerekirse:
- Veriler birkaç temel hizmetten gelir (örn. Segment, Bigquery, DynamoDB)
- Ham veriler batch yada stream processing için EL (Extract & Load) süreçlerine gönderilir. (Airbyte)
- Bu ham verileri bir zamanlayıcı (Crontab) kullanarak staging katmanına (Postgresql) yüklüyoruz.
- Analiz ve özet tablolar için staging verileri TL (Transform & Load) sürecine gönderilir. (Talend)
- Veri analizi , veri bilimi ve ML süreçleri için Python dilini kullanılır.
- Veri görselleştirme için Google Data Studio ve Metabase , DWH sistemini kullanır.
- Uçtan uca izliyoruz. (DataHub ve Slack)
Veri mimarimizi planlarken, ölçeklendikçe hayatımızı daha kolaylaştıracak kararlar verdik. Birkaçı şunlardır :
- Dimensional veri modeli kurmamak
İşimizin günlük akışı çok hızlı ilerlediği için veri modelimizin ve ham verilerimizin sık sık değişeceğini biliyorduk. Bu nedenle, veri modelinin bu tür sık değişikliklerde başarılı olması gerektiğini biliyorduk ve günden güne daha az değişiklik olana kadar veri ambarımız için geleneksel dimensional bir veri modeli yapmamaya karar verdik.
- View yapıları
Veri kaynaklarının çeşitliliği birçok asenkron çalışan job kurma ihtiyacı doğurdu. Bu verilerin değişim sıklıkları farklı olduğundan basit veri setlerini viewler ile özetliyoruz. Ham verilerin kolay kullanımını sağlamaktadır. Büyük ve maliyetli veri setleri için bu mümkün değildir.
- CDC ve geçmiş veriler
Yukarıda bahsedildiği gibi, şirket büyüdükçe verilerimizin çok değişeceğini önceden biliyorduk. Bu nedenle, verilerimizin çoğu için tam geçmişleri tutmaya karar verdik. Bu karar bize zaman kazandırdı, yeni veri kaynaklarına ve şemalara uyum sağlamayı kolaylaştırdı ve yalnızca tam bir geçmişle kullanılabilen kilit verileri açığa çıkardı.
Okuduğunuz için teşekkürler …