Transkript
Size de Rubik küp geldi mi? Ne?
Rubik küp. Evet geldi.
Ben onu bozdum ve bir daha yapamıyorum.
Aynen abi. Sırf o yüzden bozmuyorum.
Büyük ihtimalle yapamayacağım. Bunun algoritmaları varmış galiba ya.
Evet ben bir ara baktım da.
Çok zor ya. Yazılcı olsak yapardık da.
Evet. Yani kodunu yaz deseler belki.
Bilgisayar yapardık. Ben o algoritmayı aklımda tutamıyorum.
Evet ya. Nasılsınız?
İyi, sağ ol. Sen nasılsın?
Böyle Barış'la aramızda konuştuğumuz bir program.
O zaman kim açıyor bugün programı?
Hoş geldiniz. Biz bugün Barış'la 17.
programda muhabbet edeceğiz.
Bugün tabii ki Barış yanında Fırat da var.
Yine üçümüzüz. Gerçekten bu sefer hangi program sayısında olduğumuz bildiğimiz bir program olacak bu.
Hoş geldiniz tekrar arkadaşlar. Merhabalar.
O zaman programın sayısını da söyleseydik aslında.
Söyleyemedim mi? Biliyorsak dedik mi?
Duymadım ben, pardon. 17.
bölüm. 17. bölüme hoş geldiniz.
Hoş geldiniz. Hoş bulduk.
Hoş bulduk. Bugün bizlerle DVR şeklinden Onur ve Eda birlikte.
Kısaca böyle kendinizi tanıtmanız için topu size bırakalım.
Nerelerde, ne işler yaptınız, ne kadardır trend yolda çalışıyorsunuz diye birazcık sizi tanıyalım.
Selamlar. Önce ben başlayayım o zaman.
Eda ben. Yaklaşık iki yıldır, hatta iki yılda biraz geçti, Trendholz DVH yani Data Warehouse ve Rambar'ı ve raporlama ekibindeyim.
Neler yaptığınızdan birazdan bahsedeyim.
Önce Onur'a kendini tanıtması için söz verelim o zaman.
Merhabalar, ben de Onur Taşan.
Tam bugün ikinci yılım.
İki yıldır Trendholz DVH ekibindeyim.
Developer olarak çalışıyorum.
Umarım uzun senelerde böyle devam eder.
Hoş geldiniz arkadaşlar. Neler yaptığınız konusunu...
Tam şu anda konuşabiliriz.
Sizin ekip neler yapar? Bizim ekip neler yapar?
Çok güzel. Şimdi farklı kaynaklarda bulunan aslında operasyonel verileri toplayıp, temizleyip, dönüştürüp son kullanıcıya raporlama ortamı olarak sunduğumuz bir data merkezi sunuyoruz biz burada.
Neler yapıyoruzdan kasıt aslında çok fazla işlem yapıyoruz.
Teknik manada da, servis raporlama manasında da.
Biraz onlardan bahsedebiliriz isterseniz.
Tabii. Şimdi şöyle anlatalım.
Aslında Trendyolus çok fazla farklı platform var ve biz bu farklı platformlardaki dataları toplayıp birleştiriyoruz.
Nasıl bir şey yapıyoruz ondan bahsedeyim.
İşte OMS ekibinden satış datasını alıyoruz örneğin.
Pim'den product datasını alıp bu datayı aslında konuşturuyoruz.
Daha bunu çok fazla büyütebilirim tabii ki de.
Sayı olarak hani bu podcastlerdeki bütün ekiplerin aslında...
her biriyle çalıştığımız bir şeyiz.
Ortak bir platformuz biz.
Belki Onur da ekstra şeyler eklemek ister.
Aynen. Aslında biz temel olarak Trendyol'daki tüm dataları Alıp bir araya getirip anlamlı hale getiriyoruz diyebiliriz.
Çünkü tahmin ederseniz ki her product ekibinin kendini özelleştirmiş dataları bulunuyor.
Ancak bunun gün sonunda raporlanması istediğinde biz bunları bir araya getirip belli bir model üzerinde konuşabilir hale getiriyoruz.
Yani bir kişiye sipariş verdiğinden sonra her ekibin kendisinde bu verileri aslında oluşuyor.
Bu ürünün kargo bilgisi, nereye gideceği, kaç tane alındığı, fiyatı, neyle ödendiği gibi bir bilgiler aslında farklı farklı yerlerde tutuluyor.
Biz bunları bir araya getirerek, modellenerek aslında iç müşterimizin bundan anlamlı sonuçlar çıkartılması için veriler oluşturuyoruz.
Yani iç müşteri dediğimiz aslında mesela bizim ekip de bu iç müşterilerden bir tanesi.
Mesela günlük verilen sipariş sayısı, işte yola çıkan sipariş sayısı gibi mailler bizim ekipten çıktığı için bizim ekibimiz de çalışma şansı bulmuştu.
Ve gerçekten de çok fazla verinizin olduğunu orada görmüştüm.
Tüm sipariş datası da sizde, tüm ürün datası da sizde.
Bunları nasıl saklıyorsunuz?
Az sonra ufak ufak konuşuruz.
Aynen. Yani sizinle çalıştığımız için direkt sizinle bizim datamız arasında hani o arada da konuşabiliriz.
Ama gerçekten bir sipariş oluşmadan önce de aslında sipariş oluştuktan sonra da böyle uçtan önce bütün süreci yönettiğimiz bir platform.
Yani bir ürünün rent yola girişinden işte ne bileyim stone'un bitişine kadar bütün aşamalarını böyle anlatabildiğimiz bir...
yapımız var diyebiliriz aslında.
Biraz değindiğiniz zaman şeyi de merak ediyorum aslında.
Bildiğim kadarıyla Trendyol'daki neredeyse tüm ekiplerle çalışıyorsunuz ama Daha yakın çalıştığınız ekipler kimler özellikle?
Burada aslında bütün ekiplerle yakın çalışıyoruz.
Şimdi ekibimizden bir minik bahsedeyim.
Aslında biz tam 55 kişiyiz şu anda ama böyle çok hızlı büyüyoruz.
İki yıl önce ben ekibe katıldığımda 16 kişi kadardık bu arada.
Şu anda 28 analist, 20 developer, liderlerimizle beraber artı operasyonel raporlama ekibimiz de var içeride.
Toplam 55 kişiyiz.
Bu 28 analist ama şey değil.
Yani böyle herkes mesela OMS ekibiyle çalışıyor gibi değil.
Aslında biz de kendi içimizde domain domain bölünüyoruz.
Yani nasıl product, kupon, promotion ayrılıyorsa aslında biz de kendi içimizde ayrılıyoruz.
Örneğin ben analiz tarafta olduğum için kategori planlama domainine bakıyorum.
Kategori ve planlamadan gelen rapor taleplerine, data ihtiyaçlarına karşılık veriyorum.
Ekibimizde bunun gibi tam şu anda 7 domain var.
Daha da bölünüp artacak bu arada hani şeyden dolayı.
Büyüme hızımıza bağlı olarak farklı domainler geliyor.
Tabii ki de bizim de sayımız da bununla orantılı olarak artıyor.
Böyle söyleyebilirim aslında.
Benim reklamam gerekirse aslında sadece hani product teknoloji ekiplerinin yanında biz böyle growth dediğimiz analitik data science ekiplerle de çalışıyoruz.
Aslında sizden aldığımız yani Trenton'un internal aldığımız dataları bazen external olarak da aldığımız dataları analitik ve growth ekiplerine paylaşıyoruz.
Onlarla bunlar üzerinden aslında hem reklam bölümlerine hem onun üzerinden müşteri kampanyalarının oluşturulması belki de machine learning modellerine kadar verinin beslenmesini de sağlıyoruz.
Bir analistten bahsettiniz.
Burada analist dediğimiz arkadaşlar ne tarz bir görev üstleniyorlar?
Tabii ondan da bahsedeyim.
Şöyle mesela yeni bir model geldi diyelim, yeni bir channel açıldı trend yola diyelim.
Bunun tabii ki de hani raporlama ihtiyacı ilk olarak bize geliyor.
platformumuz açılıyor ya da böyle bir channelımız açıyor.
Bunun raporlarını görebilir miyiz deniyor.
Orada aslında iki haftalık sprintler koşuyoruz biz de.
Tabii ki de bu backlog'a girdiğimiz domainler yani business ekipler.
Business ekip dediğim aslında biz de işte kategori planlama ekibi, marketplace ekibi ya da finans ekibi de böyle isimlendirebiliriz.
Bu arkadaşlarla İki haftalık backlog toplantılarına giriyoruz ve onların rapor taleplerini alıyoruz.
Ardından işte size geldiğimiz noktalar buralar oluyor.
Kaynak ekiplere gidip arkadaşlar işte hani böyle bir data varmış artık oluşacak ya da bunu öğrenebilir miyiz?
İşte tabii ki de business mantığını, datanın ne olduğunu böyle öğrendikten sonra burada aslında bir sonraki aşamamızda şey oluyor.
Yani datayı bizim DVH tarafına almamız gerekiyor.
Orada aslında... Developer ekibimizle beraber paslaşarak çalışmaya başlıyoruz.
Data'yı developer ekibimiz DVH ortamlarını aldıktan sonra biz aslında modelleme yapıyoruz.
Dimensional modeling dediğimiz yani DVH ortamının kurulması için gerekli bazı yapılar var.
Bazılarında tabii ki de birebir kaynak tarafla birebir aynı data'yı kullanıp raporlama yaptığımız ortamlar da var.
Ama genelde T-1 anlayakın raporlama yapıp modelleme yapıyoruz.
Ardından da bunu son kullanıcıya sunabilmek için Tabii ki de raporlama tool'larımız var.
Bu raporlama tool'larımızda şirket içindeki ekiplere rapor gösteriyoruz.
Örnek veriyorum işte bugün şu ürün çok sattı, bugün şu ürün çok görüntülenmiş ama satışı bu kadar olmuş.
İşte biz bu üründe nasıl bir aksiyon almalıyız gibi işlere kadar biznes ekiplerine cevap verecek analizler çıkartıyoruz.
Peki çıktığının doğru olup olmadığını, gerçekten işlevini yapıp yapmaması gerektiğini nasıl valide ediyorsunuz?
Bir QA takımınız mı var?
Yoksa bir stage ortamında, aslında Trendal'daki o test ve stage ortamlarında zaten production'a çıkacağınız çalışmaları yapıyor musunuz?
Oradaki süreç nasıl? Şöyle zaten datayı bizim tarafa alıp direkt hadi bunu hemen modelleyelim, rapor çıkalım gibi bir şey yok.
Bizim tarafa aldıktan sonra aslında biz kaynak ekiplerle çok fazla konuşup çok fazla data testi yapıyoruz.
Yani işte nal gelmemesi gereken bir kolonda nal gelmiştir.
Bunu kesinlikle hemen gidip soruyoruz ki hani bu zaten bizim raporlama ortamamızı bozacak.
Data quality maillerini bize yağdıracak.
Konuşlara şey sebep oluyor.
Bu tip şeylere sebebiyet vermemek için tabii ki bizim kendi tarafımızda analiz tarafta da, developer tarafta da data testlerimiz var.
Belki de biraz Onur developer taraftaki testlerden bahsetmek ister.
Kesinlikle. Şöyle bir...
yöntemi izliyoruz. İki şekilde biz aslında Data Warehouse ortamlarımıza veriyi alıyoruz.
Biri klasik JDMC extraction'la diğerini de daha çok tercih ettiğimiz aslında streaming olarak almak.
Yani veriyi önce Kafka'ya yazılması daha sonra Kafka'dan bizim sistemleri streaming olarak tekrar DH ortamına yazılması kısmında.
Burada çeşitli kontrol mekanizmalarımız var.
Örneğin Biz Couchbase'den aldığımız verilerde Couchbase'deki döküman sayısıyla bizdeki döküman sayısının aynı olması, kaynaklı bir Postgres, MSSQL gibi relational database'lerden veri aldığımızda oradaki kaynaktaki kayıt
sayısıyla bizdekinin aynı olması gibi kontrolleri yapıyoruz.
Ayrıca farklı sistemlerden data aldığımız için bunların aslında birbiriyle ilişkisel olarak maplenebilmesi de önemli.
Yani bir şeyin siparişi oluştuysa onun işte bir ödemesi finans tarafında payment oluşmuştur.
Pargo tarafında bir... verisi oluşmuştur.
Stokta bir verisi olmuştur.
Aslında bunların da eşlerini biliyor olması işte Dimension'la modelik dediğimiz kısımda da zaten ortaya çıkmış oluyor.
Veriyi Kafka'dan tercih ettiğinizi bilmek güzel oldu.
Şimdiye kadar hiç bunu bilmiyordum.
O yüzden Postgre'den alsanız olur mu diyordum.
Kusura bakmayın. Bu dönemde çok yeni kişi başlamış olmalı.
Sizde sanırım analist diye farklı bir rol de var.
Hani bizim ekitlerimizde aslında PO olarak bildiğimiz rolden sizde çok fazla var.
Böyle farkları da anlatarak yeni gelen biri nasıl onboard oluyor sizde?
Evet bizde yani aslında PO da denilebiliyor ama kendi içimizde aslında birbirimizi analist olarak isimlendiriyoruz.
O yüzden analist değil.
Hani o fark etmez aslında.
Bizde yeni başlayan biri tabii ki de onboarding süreçlerinden bütün trend yolla başlayan arkadaşlar gibi onlar da geçiyor.
İlk iki hafta diyoruz aslında hani bu body ile beraber çalışma süresinde ama hiç öyle olmuyor.
Yani biz 9. sıra hep beraber çalışıyoruz, payır çalışıyoruz.
Yeni biri başladıktan sonra onun işte işe adaptasyonu, ekibi adaptasyonu, ekibin içinden biri gibi kendini hissetmesi için.
Zaten böyle çok şey bir ekibiz bu arada, cana yakın bir ekibiz yani böyle birbirimize...
İşte samimiyiz. Sabah toplantılarında böyle kamerayı açan kişi sayısı çoktur ya da akşamları da öyledir.
Sabah akşam beraber bir araya geliriz falan.
Hani bu şeyler tabii ki de ekibi yeni başlayan arkadaşlara da samimi geldiği için onların da daha hızlı adapte olduğunu düşünüyorum.
Bir tane arkadaşımız var böyle yakın zamanlarda başlayan bir arkadaşımız.
Şey demiş yani korkuyordum hani bu dönemde COVID döneminde işe başlamaktan işte uzaktan.
Alışmak kolay olur mu falan gibisi.
Ama ilk hafta mesela şey dedi bana.
Badi Sibel Hanım hani çok kolay alıştım dedi şirkete.
Yani ekip çok cana yakın.
Bir soru sorduğunda böyle gerçekten herkes yardım etmeye çalışıyor.
O yüzden onboarding sürecinde aslında Badi çok yardımcı oluyor ama bütün ekip de aynı şekilde yardımcı oluyor.
Orada herhangi bir eksiklik ya da böyle bir geride kalmış bir şey hissetmiyoruz.
Development tarafta da bizde aslında peer development süreci başlıyor.
Biri başladıktan sonra. Önce mentoru...
bir body'si oluyor bu kişinin başladığı günden itibaren.
İlk günler klasik bir DevOps'un takımında bildiğiniz gibi işte kurulumlar, yetkilerin alınması, gerekli ortamların, envayrımların hazırlanması gibi bir süreç oluyor.
Onu genelde yarım günde hallediyoruz.
Öğleden sonra işte bizim repolarımızın, pipeline'larımızın, süreçlerimizin tanıtılması, hazırladığımız arkitekçinin planlar var, onların gösterilmesi, işte verileri buradan alıyoruz, şu makineleri kullanıyoruz, şöyle bir pipeline çalışıyor gibi.
Daha sonra aslında genellikle ikinci gününde veya üçüncü gününde ilk deployment'ını yapacak işte.
Bir geliştirmesini yapacak, onun merge küresini açacak ve viewer'ının yapılması, daha sonra devreye alınması gibi sürecinin yapılmasını sağlıyoruz.
Hızlı bir şekilde bizim ekibin içine dahil olmuş oluyor.
Zaten ilk devreye alımını yaptıktan sonra böyle işte klasik trend yolda hepimizin bildiği gibi baklava emojileriyle artık baklava talebimizde bulunuyoruz gibi bir süreç oluyor.
Biz de aslında bu şekilde. Peki şunu merak ettim.
50 kişilik bir DVH ekibinden bahsettik ve domenlere ayrılmış ekipler dedik bunlar.
Bu onboarding sürecinde her katılan kişi ilgili bir domenide mi çalışıyor birincisi?
İkincisi de bu domen ekipleri kaçar kişiden oluşuyor?
Diğer domen ekipleriyle sık sık çalışması gerekiyor mu DVH altındaki?
İlk ona cevap vereyim. Evet, o kişi genelde hangi domenide çalışacaksa analist olarak o domenide body'si oluyor ve öyle başlayıp devam ediyor.
Yani artıları da var, eksileri var mı?
Eksisi yok bence hatta.
Bu kişi başladıktan sonra diğer ekiplerle tabii ki şimdi şu an en kalabalık domenimiz 7 kişi ama bölünecek orası.
Önceden mesela sadece Delivery'e bakıyordu.
Hatta Tex'de onun içindeydi.
Tex'le beraber şu an 11 kişi olacaklardı beraber olsalardı ama Tex ayrıldığı yapıldı vakitte içimizde.
Şu an en kalabalık 7 ama mesela ben kendi...
Domain'im için söyleyeyim biz kategori planlamamız backlogunda şu anda dört kişiyiz.
Tabii ki de diğer domainlerle beraber çalışmamız gereken çokça şey oluyor.
Örneğin satış koymaz tarafı bizim domainimizde öyle söyleyeyim.
Ama işte text'teki birinin de satışla ilgili kesinlikle bir rapor talebi olabiliyor.
Ya da müşteri deneyimine bakan...
backlogdaki arkadaşların da kesinlikle satış datasıyla ilgili bir ihtiyacı olabiliyor.
Orada kesinlikle hep ekip içinde beraber ilerliyoruz.
Yeni bir büyük bir iş.
devreye alınacak. İşte şöyle bir değişiklik olacak satış modelinde mesela.
Burada kesinlikle o 28 kişi dediğimiz analist ekibi bilgilendirip devam ediyoruz.
Hani aslında ayrı bir süreç yok.
Yine beraberiz ama backlog toplantılarına ayrı giriyoruz.
Talepleri ayrı ayrı alıyoruz diyebiliriz.
Development ekibi için soruna cevap vermem gerekirse abi orada da şöyle bizim 20 developer olarak aslında herhangi bir ekip ayrılmış durumda değiliz.
Biz bu ekiplere ayrılmış PO'larımızın backlogları aslında bizim DVH backlogunda en son bildiği yani D-Wash Development Backlog'un da birleşerek ortak bir havuza düşüyor.
Biz de aslında yoğunluğumuza veya iş planımıza göre o havuzdan işleri çekiyoruz.
Bu yüzden aslında development taraf domainlere ayrılmış durumda değil.
Ama dediğimiz gibi 20 kişilik bir ekip olduğumuz için de ileride nasıl bir süreç işler aslında yaşayarak göreceğiz.
Ben de şeyi merak ediyorum. Kullandığınız teknolojiler neler?
Az önce mesela Kafka'dan bahsettin, bir parktan yapınız olduğundan bahsettin.
Bizim böyle çok aşina olduğumuz teknolojiler değil büyük ihtimalle.
diğer kullandığınız teknolojiler.
Biraz onlardan bahsedebilir misiniz?
Neler kullanıyorsunuz? Ne tür pratikler uyguluyorsunuz?
Tabii ben o zaman en başından başlayayım.
Sonra da Eda'ya en sonunda raporlarımı katmanı Eda'ya bahsedeyim süreci.
Biz aslında kaynak sistemleri olarak bilebildiğiniz gibi Trendyol'da Postgres, MSSQL, Couchbase, direkt Kafka olarak source kullanabiliyoruz.
Elasticsearch olabiliyor. Presto var, Data Engineering ekibimizden de beslendiğimiz durumlar olabiliyor.
Ve şu aralar Cassandra.
Herhalde söylemedim artık saymaktan fazla olduğu için Cassandra'dan bile kaynak sistem olduğumuz oluyor.
Biz burada ne yapıyoruz aslında?
Kafka'ya yani streaming olarak besleyemediğimiz bir ortam varsa genellikle buralarda JDBC Extraction kullanıyoruz.
Kendimizin Python'la yani ekip içinde yazdığımız Python'lı bir tool'umuz var adı Toaster.
Buraya belli bir YAML bir dosya veriyoruz.
O YAML'da ilgili parametreler oluyor.
Alıp Google'da BigQuery ortamlarını tabloya ekstrak ediyor istediğimiz parametrelerle.
Ama biz çok tercih ettiğimiz bir yöntem değil.
Çünkü hani o anki tablonu snapshot'ın almış olabiliyoruz.
İşte change'leri takip edememiş oluyoruz.
Veya çok hızlı bir şekilde aslında bu süreci yönetmiş olamıyoruz.
Özellikle büyük tablolarda.
Bu yüzden çoğunlukla biz streaming yöntemi tercih ediyoruz.
Orada da şunu kullanıyoruz. Aslında Kafka Connect'i kullanıyoruz.
Kafka Connect bizim streaming akışımızda temel bir yerde duruyor.
İşte kaynak Kafka ise direkt sim konektörler kullanarak Google Cloud Storage'e yazıyoruz.
Kaynak Flashbase ise yine Kafka Connect'in Flashbase.
source konektörüyle kendi Kafka klaslarımıza yazıyoruz.
Oradan yine Google Cloud'un sync konektörüyle Google Cloud'a yazıp oradan BigQuery ortamlarımıza load ediyoruz tabloyu.
Bu şekilde olduğu zaman aslında değişen için çok hızlı bir şekilde BigQuery'e de yansımış oluyor.
O yüzden neredeyse near real time olarak kaynaktaki bir veri bizde de durmuş oluyor.
Aslında bizim pipeline'ımız bu şekilde.
Biz bu verileri aslında BigQuery ortamına aldıktan sonra ETL dediğimiz bir süreçten koşuyorlar.
Bizde ETL ikiye ayrılmış oluyor ve SQL'ler üzerinden yapılıyor.
Yine bu SQL'leri tetikleyen bir ETL projemiz var Python'da yazılan.
O Python projesi bizim schedule'larımızda ilgili SQL'lerimizi tetikliyor.
İki çeşit ETL koşuyoruz.
Biri anlık ETL dediğimiz ODS ETL'imiz.
Yani belli schedule periyotlarla gün içinde çok sık Refresh yaptığımız yerler.
Bir de TX1 ETL dediğimiz aslında modellemenin olduğu ETL'in olduğu yer.
Orada da gece saat 12.30'da kaynakın o anki tabloların frizlerini alıyoruz.
Onun üzerinden modellemeden geçerek en son kullanıcıya oluşacak rapor tabloları oluşuyor.
Orada da kullandığımız raporlama tool'undan Eda bahsetmek ister.
Evet. Tabii ki bu kadar büyük bir detayı sunduğumuz hep query yazarak rapor vermiyoruz.
Aslında şu anda mevcutta kullandığımız raporlama tool'umuz tablo.
Ama Cloud'a geçiş sürecimizle beraber biz de performans arttırımı vs.
sebeplerden ötürü aslında yine Google'ın bir ürünü olan Looker'a geçeceğiz.
Şu an hatta orada da mesela domain-domain bölünüp yavaş yavaş geçme aşamasındayız.
Ama aktif olarak Tableau'yu kullanıyoruz.
Ondan bahsedebilirim. Aslında Tableau'da da bu ETL sonuçlarında oluşturduğumuz ODS veya T-1 raporlardan data modelleri oluşturuyoruz.
Bu data modelleri de örnek veriyorum satış bir data modeli bizim için.
İşte hex akışı bizim için bir data modeli.
yansı tarafı aynı şekilde. Bu data modellerine aslında...
Tek bir kaynak sistemden gelen datayı diğer kaynak sistemlerle birleştirip kullanıcıya tek bir ortamdan hızlı rapor vermeye amaçlıyoruz.
İşte bir rapor için farklı kaynakları gitmesini engellemek için birleştiriyoruz aslında bu datayı zaman tasarruf sağlamak için onu söyleyebilirim.
Anlığa yakın raporlamamız var.
Bu da hani günlük satış metriklerini takip eden kategori ekiplerine örnek verebilirim en azından.
Kategori ekiplerinin bu gibi taleplerine cevap veriyoruz.
Onur söylemedi, onları da ben söyleyeyim.
CRM ekiplerinin Data Science'dan push atılmasına örneğin.
Bu gibi ekiplerin aslında uygulamaları push atması için de data birikimini sağlıyoruz.
Aslında yazdığımız bu T-1 veya online yakın datayı sadece biz kullanmıyoruz.
Aynı şekilde Google Big Query ortamımıza siz bile yani kaynak ekiplerdeki arkadaşlar dahil olmak üzere herkes sorgu yazıp çıktı alabiliyor.
Bunları söyleyebilirim.
Bizim bir ihtiyacımız olmuştu.
Kredi kartının ilk 6 ve son 4 tanesiyle verilen siparişleri görmekle alakalı.
Orada sanırım sizin datanızı kullanıp Data Engineering ekibi bizim için bir api açtı.
Buradaki sorumluluklar nasıl dağılıyor?
Yani data ile alakalı aslında 3 ekip var gördüğüm kadarıyla.
Data Engineering var, DVH var ve Data Science var.
Bunların sorumluluk alanları neler?
Şundan bahsedebilirim aslında.
Biz data ve arazı olarak amaç...
Aslında son kullanıcıya özellikle işte Trendyol içindeki kullanıcıya anlamlı veriyi sunabilmek.
Yani farklı sistemlerde olan veriyi bir yere gidip bir veri bütünü sağlayarak onun üzerinden Trendyol'un işte data ile yaşarız mottosunu da benimseyerek bir karar alırken, bir analiz yaparken, belki bir kampanya çıkarken, reklam
çıkarken bunun datasını kullanabilecek bir ortam sağlayabilmek aslında ilk amacımız data ve arazi olarak.
O yüzden... Bizim Data Warehouse'a olarak amacımız Trendwell'daki tüm datayı bir araya getirip gerçekten kelimenin tam anlamıyla bir veri ambarı oluşturmak.
Bu veri ambarından da anlamlı kişilerin sorgulayabileceği, kullanabileceği bir ortam sağlamak.
Bunu da şu an Eda'nın az önceki soruda da bahsettiği için tablo yönde sağlıyorduk.
Bundan sonraki süreçte de POC'nin tamamlanmasıyla da Looker'da devam ediyor olacağız.
Data Engineering ekibi aslında product ekiplerine biraz daha yakın çalışan bir ekip.
API'ler sağlayıp Trendhole ürününe direkt kaynak verisi sağlayabilecek bir ekip.
Yani onlar biraz daha ürünün içinde olan ekip diyebiliriz.
Data Science ekibi de aslında hem bizim verilerimizi kullanıp hem de işte kendi anlaşmalı oldukları sistemlerin verilerini bir araya getirerek Trendhole için işte bu verinin daha iyi nasıl kullanabiliriz, daha iyi analizler
nasıl yapabiliriz. Örnek kezler üretme işte mesela en basitinde Data Science ekibiyle beraber çalıştığımız Dashboard trend yol domayını var.
Mesela biz o dashboardta data science ekipleri işte bizim tahmini GMV'miz ne olacak?
Gün içinde satışımız nerelere ulaşacak?
Böyle giderse ürünün stokları şu zaman bitecek gibi tahmini, veri analizleri yapıyorlar.
Bunları da ilgili ekiplerle paylaşarak anlık aksiyonların alınmasını sağlıyorlar aslında.
Umarım açıklayacağı anlatım yapabilmişimdir bu konuda size.
Gayet net oldu. Sağol.
Beni merak ediyorum. Bir az önce yazdığınız, içeride geliştirdiğiniz bir Tool'dan bahsetmiştin, partimle yazdınız.
Sadece o tool üzerinde demiyorum ama genel olarak deploy süreciniz nasıl oluyor?
Hem o tool üzerinde anlatabilirsin hem de diğer geliştirdiğiniz uygulamalarda deployment'ı nasıl yapıyorsunuz ve o süreci biraz anlatabilir misiniz?
Tabii burada ben bahsedeyim.
Genel olarak aslında ETL dediğimiz süreçte yani Extract Transform Load sürecimizde ETL'in genelinde bir repodan ilerliyoruz.
Biz bir GitLab kullanıyoruz.
Bütün geliştirmelerimiz orada bir Merge Case üzerinden oluyor.
Yani branchlar açılıyor ilgili backlogdaki talep numarasına göre.
Koddaki işler o branch üzerinde yapılıp daha sonra master amaçlanarak production ile çalışarak kod base'imiz oluşmuş oluyor.
Biz bu kod base'i scheduler'ımızın içinde yazdığımız özel bir script ile tetikliyoruz.
Ve işte repo'daki data bizim intel'in scheduler dediğimiz, datanın sürekli scheduler bir tool'da çalışmasını sağlayan bir tool ile upload ediliyor bütün kodlar.
Onun haricinde yazılmış işte Tolstoy gibi.
4 partilerden veri aldığımız ya da içimizdeki bir teknik sorunu çözdüğümüz uygulamalarda da CI-CD süreçlerini kullanıyoruz.
CI-CD süreçlerinde de aslında şöyle ilerliyor süreç.
İşte yine geliştirmemizi yapıyoruz.
En az 2 kişi bu geliştirmeyi review ediyor.
Bu review süreci gerçekleştirdikten sonra da master'a merge olurken bir CI pipeline çalışıyor.
Bu pipeline ilgili kontrolleri yaptıktan sonra makineye kodun kuşlanmasını sağlıyor.
Hit boyma sürecimiz de aslında bu şekilde oluyor.
Codebase'imizde şu an açıkçası net bir CICD süreci oluşturmuyoruz ama bir proje başlattık.
Bu projeyle beraber aslında her bir değişikliğimiz belirli validationlardan ve kontrollerden geçtikten sonra otonom olarak kendini güncelleyecek şekilde bir süreç hazırlamaya çalışıyoruz.
Açıkçası 2021 hedefimizden biri de bu.
Peki zaten CodeGV yaptığınızdan bahsettiniz.
Bunun dışında... testlerim gidiyor musunuz?
İntegration test yazıyor musunuz?
Ya da ne tür kod standartlarınız var?
Bunları biraz merak ettim.
Ve orada da şundan bahsedebilirim.
Öncelikle kodu yazdığımızda kodun formatı ilk başta en dikkat ettiğimiz yöntem oluyor.
Çünkü bir Python kodu, Java kodu gibi uzun bir SQL dilimiz de olabiliyor.
O yüzden bunun okunulabilir formatta olması en büyük kriterlerimizden biri.
O yüzden ilk review'larda kontrol ettiğimizden biri aslında kod formatlarımız.
Daha sonra bu kodu yazarken özellikle kompleks sistemlerde payı çalıştırmaya dikkat ediyoruz.
Yani beraber yazıyoruz, farklı gözlerden bakış açısı alıyoruz.
Ya da bir proje geliştirdiğimizde aslında taslarını çıkartıp haftalık sync dediğimiz toplantılarda bunun üzerine tartışmalarda bulunuyoruz.
Örneğin işte en yakın zamanda Cassandra'dan bahsedebilirim.
Cassandra olarak sor sistem aramıza dahil olmaya başladı.
Bu olduğu için de Biz kendi aramızda şey konuştuk işte biz bunu klasik Python'la bir kütüphaneyle extraction mı almalıyız?
Yoksa işte gidip SQLSH diye bir kütüphanesi var bunu işte deploy edip orada mı kullanmalıyız?
Ya da işte Kafka Connect'in bununla ilgili birkaç tane konnektörü varmış bunları mı kullanmalıyız gibi.
Kendi içimizde tartışmalar yapıp aslında ana bir süreci yönetiyoruz.
Daha sonra özellikle yazdığımız harici uygulamalar işte Python'la Java'yla olsun.
Genellikle unit testlerimizi...
veya işte fonksiyonlarımızın işte integration testlerini yazmaya dikkat ediyoruz.
Ama bu SQL'de daha sık uğraştığımız için var olan pratiklerimizde olan bir yöntem değil.
Aslında son bir senedir diyebilirim dikkat etmeye çalıştığımız yöntemlerden biri.
Daha çok işte software development kasımız geliştikçe bunu da yapmalıyız, şunu da yapmalıyız diyerek çalışıyoruz.
Ama genel şeyimiz, pratiğimiz pair çalışmak, ekip olarak karar almak yaptığımız şeylerde ve bu süreçlerin hepsinde CodeReview'un bulunması.
Sizin incidentlarınız da farklıdır.
Yani bir incident olduğunda önceden nasıl anlıyorsunuz?
Bunu monitör ettiğiniz bir yerler var mı ya da alert mekanizmalarınız var mı?
Burada şöyle bir şey söyleyeceğim.
Tabii ki biz anlayan yakın raporlama ortamı sunduğumuz için aslında çok hızlı bir şekilde kategori etikleri en ufak değişimleri bile fark ediyor.
Tabii ki de yapılarımız var, alert mekanizmalarımız var.
Onlar da onu bahsediyor ama şeylerden çok dönüş alıyoruz mesela.
Böyle bir hata olduğu zaman kategori ekiplerinden veya diğer ekiplerden işte şuradaki şu karlılıkta ya da şu bir onda şöyle bir hata var.
İşte burada bir şeyler yanlış olmuş olabilir mi gibi Slack kanallarımızdan epeyce böyle tanelen bir ortam oluyor öyle hatalarımız olduğunda.
Onları biraz daha teknik taraflara anlatabilir tabii.
İnsanlıklarımız oluyor tabii.
Özellikle şöyle bir şey oluyor işte şu tablo.
Geride kalmış, buradaki tablonun tarihi 2 saat önce de kalmış, 5 saat önce de kalmış gibi durumlar olabiliyor.
Genelde konuşmaların başında da bahsettiğim gibi aldığımız her bir tablonun kontrol mekanizmasını yazmaya çalışıyoruz.
Bunu nasıl alıyoruz? Kaynakla birebir mi kayıt sayımız?
Kaynaktaki tarihle bizim tarihimiz uyuyor mu?
Aldığımız pipeline'ların belli bir job'lar schedule edilmiş durumda bu pipeline'ları çalıştıran.
Onların hata meyilliği çok sık olarak düşüyor.
Bu hata maillerinde aslında bizim içeride bir nöbet sistemimiz var gündüz ve gece olmak üzere.
Gündüz nöbetçimiz aktif olarak takip ediyor.
Gündüz nöbetçisi olduğumuz haftalarda aslında backlogdan iş almaktan çok ETL pipeline'ımız düzgün işliyor mu, streaming pipeline'ımız düzgün işliyor mu, herhangi bir data quality veya bir tablonun geride kalması gibi bir durum var mı diye alan
mekanizmalarımız var.
gündüz nöbetçisinin görevi aslında bunları takip etmek oluyor.
20 kişilik ekip olduğumuz için bir hafta gündüz nöbetçisi oluyoruz, bir hafta gece nöbetçisi oluyoruz.
Ve yıl içinde böyle 2-3 görev nöbet tutarak yılı tamamlamış oluyoruz.
Oluşan insıdantlar Eda'nın da bahsettiği gibi aslında büyük bir resmi etkiliyor olabilir.
Çünkü ufacık bir tablonun bile geride kalması bütün satış raporlamasını etkiliyor olabiliyor.
O yüzden oradaki hızlı aksiyonlarımızla hızlıca tablonun hemen kaynaklı birebir hale gelmesi ve ilgili Akış eğer delta bir akış veya incremental bir akış ise hızlı bir şekilde migration'ın tamamlanıp düzgün
veriyi doğru bir şekilde gösterebilmeyi sağlıyoruz.
Biz de aslında bizim tarafta bu müşterilerin anket sonuçlarını mesela çok hafif getirdik.
Yine sizin üzerinizden sorgulayıp oradan alert üretiyoruz mesela.
Bu da bizim için biraz şey oluyor.
Müşteri deneyimi domenindeyken değil mi?
Evet, evet. Şöyle sorayım ben de, takım olarak sizin peki en büyük challenge'ınız nedir?
Şöyle söyleyebiliriz.
Şimdi tren yolunun büyüme hızı ve artan data hacmiyle beraber aslında biznes ekiplerine çok fazla raporlama ihtiyacı oluyor.
Tabii ki de bu kadar büyük data'nın devlet ortamına beslenmesi gerekiyor.
Bunların modellerini oluşturması gerekiyor.
Raporların oluşturması gerekiyor.
Bizim şu anda tablo için örnek vereceğim.
800 aktif kullanıcımız var.
Bu 800 aktif kullanıcının kullandığı bizim oluşturduğumuz artı diğer tabii ki ekiplerini oluşturduk.
Toplam 800 data sorsumuz var.
Yani 800 data modelimiz var.
Bunlarla beraber de toplam 13K gibi 13 bin civarında raporumuz var.
Bunların haricinde tabii ki de...
Sadece yani tablo raporu değil, işte Slack kanallarına beslediğimiz veya mail olarak attırdığımız da çok fazla raporumuz var.
Bence bizim en büyük challenge'ımız bu.
Hani bu şeye, tempoya ve hıza ayak uydurmak.
Çünkü sayımızın da artması gerekiyor çok fazla.
Ve yani tabii ki de bu ihtiyaçlara karşılık da vermemiz gerekiyor.
Bence bu belki onur farklı bir şey de ekler üzerine.
Ben biraz sayılarla belki örnek verebilirim.
2019 Haziran'da ben girdiğimde cloud sistemde çalışmıyorduk.
On-prem Vertica bir database kullanıyorduk.
Yaklaşık 40 TB'ye yakın bir veri bulunuyordu burada.
Bu 2020 içinde Google ortamlarına geçtik artık.
Google Cloud'a geçtik. İhtiyaç sürecimizi çoğunlukla oraya taşıdık.
Hala da taşımaya devam ediyoruz.
Tam bitirebilmiş değilim. Sayılarla şöyle söyleyeyim.
Vertica'da 40 TB veri varken şu an Google'da hatta bu toplantıya girmeden önce bir saat önce baktım.
3 PB'ye yakın veri var.
Yani aslında 2 seneden nereye geldiğimizin de net bir resmidir bu.
Hem daha fazla veri içeriği alabildik hem de...
Trend yoldaki veri hacmi o kadar büyüdü ki biz 2 ay önceydi yanlış hatırlamıyorsam Meetup yaptığımızda bu sayı 2 petabyte'lara bulmuştu.
Şu anda 3 petabyte'e yaklaşmış durumda.
2.9 petabyte durumdaydı.
Saatlik 30K'ya yakın sorgu geliyor şu anda Cloud ortamlarımızda BigQuery'e.
Ve yine yılbaşından beri aktif 644 yani distinct users gelip sorgu atmış durumda.
yoğun bir şekilde, aktif şekilde de kullanıyoruz.
O yüzden bu kadar kullanım varken hızlı şekilde scale edebilen, trend yolu kadar hızlı büyüyen bir data warehouse ortamı sunmaya çalışıyoruz en büyük challenge olarak.
Storage dayanmaz gerçekten.
Peki önce küçük bir soru.
Fram uyguluyorsunuz ya da işte kanbanı, herhangi bir ecel yöntemi uyguluyor musunuz?
Kanban uyguluyoruz şu anda.
Bu arada önceden aslında birer hastalık.
Sprintler diyelim aynen buna.
Öyle ilerliyorduk ama tabii de bizim sayımız artmasıyla, ihtiyaçların da değişmesiyle beraber böyle bir modele geçtik.
Çok da iyi oldu. Umarım devam ettirebiliriz.
Tabii bu sadece analist ekip için söyleyeceğim bir şeydir bu arada.
Peki o zaman ikinizden de ayrı ayrı retroda konuştuğunuz, retroda konuşulan, sonra retroda konuşulan, çıkan ve akşam aldığınız bir konuya örnek verebilir misiniz?
Ben ekibin sosyal böceği olarak şunu söyleyeceğim.
Şey maddesi çıkmıştı.
Birbirimizi çok özledik. Görüşelim artık diye.
Bir aksilik olmazsa bu hafta sonu görüşeceğiz.
Geçen haftada bir gün işte az bir sayıyla şirkete gidip görüştük, çalıştık.
Akşamına da böyle biraz birbirimizi gördük dışarıda oturduk falan diyeyim.
Diğerini de Onur söyler herhalde.
Ben de iki şey var aslında.
İlki development takımı için söyleyeyim.
Biz de nöbetler pazartesiden pazartesiye gece gündüz karışık yani aynı haftada hem gece hem gündüz sorunlarına bakıyorduk.
Yaptığımız retro sonunda bunun çok yorucu olduğunu, çok fazla yorulduğumuza karar verdik ve ekip olarak şöyle bir karar aldık yani.
Biz bir hafta gündüz sadece nöbet tutalım, bir haftada sadece gece nöbet tutalım ve bu cycle olarak dönsün diye bir karar aldık.
Ondan sonra nöbet sürelerimiz hem daha verimli geçmeye başladı.
Hem gündüz nöbet tutan arkadaşımız gece dinlenebildiği için antesibine daha sakin başlayabildi.
Gece nöbet tutan arkadaşımız da gündüz dinlenebildiği için, çünkü gündüz soruna bakacak bir insan olduğu için daha rahat bir süreç götürmüş oldu.
DVH ekip olarak bir retroda aldığımız karardan bahsetmek gerekirse de genellikle development ekibi olarak aktif olarak biz ecel çalışmıyoruz.
Çünkü dediğim gibi bizim backlog'umuza iş düşüyor.
Biz geliştiriyoruz ve teslim ediyoruz tekrar rest ekibi işi.
raporlama kısmının tamamlanması için.
Ama orada da şöyle bir sorunlar oluyordu.
İşte iş planlaması yapıldığında analiz tarafından developer o grooming sizing toplantılarında olmadığı için bazen işler belirlenen sürede gitmiyordu.
O yüzden yine bu bir madde konusuydu Retro'da ve ilgili toplantıları developer da artık dahil olarak ilgili domainin toplantılarına burada daha doğru, iş bölümüne daha kesin bir sürede teslim
edilebilecek bir grooming sizing süreci oluşturduk.
Bu süreçten sonra aslında daha hızlı bir şekilde işlerimiz ve daha doğru bir zamanda teslim edilebilir hale geldi.
Ya ben hala 3 petabyte'da kaldım.
Wow! Yani inanılmaz bir veri gerçekten.
Yani sizin tabii takip ettiğiniz metrikler, zaten işiniz metrik takip etmek ama böyle şeyi takip ediyor musunuz mesela?
Tamam 4 petabyte olmuş işte şöyle bir şey yapmamız lazım.
İşte şu uygulama 15 saniyede bir çalışıyordu bunu 10 saniyede çekmemiz lazım.
İşte bunun verisi bir yerde dursun gibi böyle takip ettiğiniz metrikler var mıdır?
Ben başlayayım o zaman. En azından şunu yapıyoruz.
Yani şimdi cloud ortamına geçtiğimiz için ne kadar veri, evet çok hızlı işledim, çok iyi yaparım ama bir maliyeti alıyor günün sonucunda.
Şöyle bahsedebilirim.
Google Cloud ortamında evet 3 petabyte veriyi çok iyi işleyebiliyoruz ama günün sonucunda bunun bir maliyeti de oluşmuş oluyor.
Bu maliyeti de biz dediğimiz gibi 3 petabyte burada veriyi dump ediyoruz, kalsın şeklinde yönetmiyoruz.
bazı verileri sistematik olarak temizlememiz gerekiyor.
İşte çok fazla mesela örnek olarak Couchbase'den vermek gerekirse Couchbase'den bir streaming olarak veriyi dinlerken aslında bucket ile olan her değişiklik bize veri olarak geliyor.
Yani ilgili bir key'in 10 kere update gördüyse bize 10 kayıt olarak geliyor.
Doğal olarak bunu 10 GB bir doküman olarak düşünürsek 10 kere de bir update gördüyse belki de 100 GB'ye çıkıyor bu bucket değeri.
Biz de o yüzden bazı tablolarımıza bir köyün özelliği olan retention'ı ekliyoruz.
Yani bu tabloya 15 gün sonra ki veriler silinsin otomatik gibi bir işler eklemiş oluyoruz.
Bu yüzden tabloların aslında hem hacmini hem de projedeki bulunan veri hacmini anlık olarak takip ediyoruz.
Diğer bir metnimiz de aslında DQ'lar.
Yani tablolarda geriye kalmış mıyız?
Bir tablonun son günde ne kadar change gelmiş gelmemiş gibi takip mekanizmalarını da yapıyoruz.
Çünkü bazen... İşte change gelmemiş oluyor.
Bu kaynak sistemde bir IP'nin değişmesi ya da tablonun değişmesi ve bize farkında olmamamız da olabiliyor.
Bu tarz kontroller yapıyoruz.
Performans açısından da belki Eda bir şeyler söylemek ister.
Tabii ki de bizde de özellikle bu tabloda kullandığımız data source'lar için konuşmam gerekir.
Aslında bizde orada kullandığımız bazı standartlar var.
Ekip içinde hiçbir zaman bu standartları bozmayacak şeylerde tablonun çalışma mantığına uygun olacak şekilde modellemeler yapıyoruz aslında.
Star şema mantığını kullanıyoruz.
Ama bu tamamen şeyle alakalı.
Hem data yapımızla alakalı hem tablonun çalışma mantığıyla alakalı.
Çok yavaş veya işte bugün bir problem mi var gibi aslında diye sorunlar aldığımızda genelde işte o raporda kullanıcı, şimdi self-BI bir ortam olduğu için aslında...
Her kullanıcı kendi raporunu oluşturabiliyor.
Ama bazen performans göz ardı edilebiliyor veya istediği data çok büyük bir data oluyor.
Hani mesela pazartesi günleri raporlama ortamımızın en yoğun kullanıldığı zaman.
O zaman da o kadar büyük bir datayı alırken belki filtrelerinde bir hata yapıyor.
Hani orada aslında yönlendirmede bulunuyoruz biz de tabii ki de onları.
İşte Query yazan arkadaşlarımıza sorgularını ilettiklerinde aslında işte...
Oradan değil de farklı bir yerden bu data'ya erişebilirsin.
Daha kolay bir yolu var. Böyle şeylerde aslında yol gösteriyoruz biz de.
Az önce Onur söylerken fark ettim.
Aslında database'lere depend olduğu için sistem CDC üzerine ya da işte datayı transform etmek üzerinden aslında oradaki kolonlara çok bağlısınız.
Doğal olarak bir ekipte, yanlış anlamadıysam tabii, bir ekipte bir database'de bir değişiklik olması, alanın adının değişmesi, tipinin değişmesi sizi direkt etkiliyor.
Bununla ilgili nasıl bir önlem alıyorsunuz, nasıl bir çalışma yapıyorsunuz, nasıl fark ediyorsunuz bu tarz şeyleri?
Aslında burada biz kaynak ekiplerle çok yakın çalışmaya çalışıyoruz bu sebepten dolayı.
Çünkü bunu yaşadığımız zamanlar oluyor tabii ki de.
Bazı ekipler mesela gerçekten önce geliyor danışıyorlar bunu böyle yaparız ama sizi nasıl etkiler?
Yani daha hiç iş başlamadan konuşma aşamasında hani pro aşamasındayken bile konuşup birebir haberleşip gittiğimiz zamanlar çok oluyor.
Haberimizin olmadığı atlanan zamanlar da oluyor ama büyük çerçevede genelde artık çok yakın çalıştığımız için kaynak ekiplerle genel haberimiz oluyor diyebilirim.
Development tarafında da şöyle bir durum oluyor.
Bu bütün haber sistemi olmadıysa bizim pipeline'ımız aslında CDC'leri yani change'leri dinleyip bir tabloya yazdıktan sonra asıl tabloya merge eden pipeline patlıyor bildiğiniz hata oluyor.
Biz de ilgili durumu inceledikten sonra Önce P.O.
arkadaşımızla daha sonra da ilgili ekipteki developer arkadaşlar ve Avazal tarafın P.O.
arkadaşıyla bunu bir değerlendiriyoruz.
İşte burası önceden böyleydi, şöyle oldu.
Bundan sonra böyle mi gelecek diye.
Ama hani Trendyol'da bu şey kültürü çok iyi olduğu için çok hızlı iletişim kurup bazı şeyleri çözdüğümüz için açıkçası çok fazla da sorun yaşamıyoruz.
Hatta şöyle olduğu bile oldu.
Yani Couchways'de modellenen bir doküman tipi sırf bizim tarafta raporlarına bile formata uymadığı için tekrar baştan development yapması gerekti arkadaşların.
Ve gayet olumlu karşıladılar.
Bunun bir raporlama talebinde olacağı düşünüldüğü için hızlıca aksiyon alıp tekrar o veri raporlanabilir hale geldik.
Biz tekrar ekosistemimizi alabildik.
Peki son olarak ben de şey sormak istiyorum.
Canlı sistemde yaşadığınız bir problem ve o problemleri öğrendiğiniz bir deneyim var mı bizimle paylaşabileceğiniz?
Şimdi aslında... Canlı sistem dediğimiz kaynak ekiplerle bizim iklim biraz farklı oluyor.
Biz de canlı sistem dediğimizde aslında canlıya anlayan yakın raporlama ortamımızı anlıyoruz.
Aslında ben buradan örnek verebilirim.
Yaşadığımız bir aksiyon şöyle bir şey vardı.
Bir gece bir arkadaşımız migration yaparken bir gündeki bütün satışları hikmet satışına çekmişti.
Yani o mesela böyle bayağı aklımızda kalan anılardan bir tanesi.
Kaynak sistemlerde herhangi bir aksaklık olduğunda biz direkt etkilenen bir ekibiz bu arada.
Çünkü bütünlerde ise kaynakları hep anlığa yakın kendi ortamımızı alıyoruz zaten.
Yani çoğuyla da anlığa yakın raporlama ortamımız var.
Hani bunu da tasısında sunuyoruz.
O yüzden aslında işte sizin ekipte olur, OMS'de olur, ne bileyim, PECS'de olur, Payment'de olur.
herhangi bir şey olduğu şekilde etkilenen bir ekibiz.
O yüzden böyle canlı sistem deyince aslında şey olmuyor yani.
Hani bizim içimize değil de bence o da herhangi bir ekibin canlı sisteminde bir şey bozulduğu anda bizde de bozuluyor diyebiliriz.
Development taraftan da biraz komik ve şey bir hani krizlik demeyeyim ama hızlıca çözdüğümüz bir durum olmuştu.
Yeni başlayan bir arkadaşımıza bizim Google Cloud'a login olmamızı sağlayan bir credential dosyasını paylaşmıştık.
Bu da bir aynı zamanda makinede de duruyordu.
Paralelinde makinede de şüphettedir demiştik.
Arkadaşımız yanlışlıkla dosyayı lokaline indirmeye çalışırken dosyanın içini boşaltmıştı.
Ve Google'a bütün dataları load eden akışlarımız teker teker patlamaya başladı.
Yaklaşık böyle 200-250 tane işimiz patladı.
Hızlıca sorunu mapleyip bulup yerine koyana kadar böyle bir 10 dakika aslında Google'a veri akımı durmuş olmuş oldu.
Ama hızlıca işte bu dosyaların yedi elimizde olduğu için hızlıca dosyayı yerine koyarak bunu sallamış olduk.
Sonra da makinede artık bu tarz değişiklikleri yapmamak için yazılı etkilerimiz üzerinde çalışmalara başladık.
Yani bir öğrenim de gelmiş bunun üzerine.
Arkadaşlar çok teşekkürler.
Bu programda Data Warehouse yani Türkçesi veri ambarı ekibiyle birlikteydik.
Eda ve Onur gerçekten çok tekrar teşekkür ediyoruz.
Yani gerçekten hayatımda ilk defa cümle içinde 3 petabyte denildi.
Bakın söyleyemiyorum bile. Benim için imkansız bir veri boyutuydu şimdiye kadar.
Ama o zaman programın en güzel kısmına geldik.
Programdan önce de konuştuğumuz gibi bir şarkı rica ediyoruz sizden.
programın öncesinde konuştuğumuz gibi biz şarkı söyleyemeyeceğiz.
Maalesef böyle bir yeteneğimiz yok.
Biz ekipten bir şarkı alırız değil mi Eda?
Evet. Bizim ekipte çok böyle yetenekli arkadaşlarımız var.
İşte gitar çalan, şarkı söyleyen var.
Pek hatırlayamadım Onur ama.
Şarkı çalan arkadaşlarımız var epeyce.
Belki onlardan bir kubbe koltuk kesin sonuna eklemez miyiz?
Tabii ki. Kapanış müziği yapabiliriz.
Ama sizden de alsaydık çok güzel olacaktı.
Gönüllük derdi tabii ama arkadaşlar ben üzgünüm.
Boşver Fırat. Üzülme.
Neyse Fırat şey yaparız.
Söylemiyorlar. Hiç söylemiyorlar.
Biliyorlar söyleyeceğiz diyorlar.
Sonra programın sonunda.
Kimse şarkı söylemiyor artık ya.
Yani biz yanlış bir şey mi yapıyoruz diye sorguluyorum kendimi bazen.
Bu kadar büyüklenerek.
Yanlış bir şey mi yapıyoruz acaba?
Konuşacağız diye geldik yahu.
Petabyte'dan sormazsın diye düşünüyorduk.
O zaman ufaktan kapatalım.
Tekrar teşekkürler programa katıldığınız için.
Biz teşekkür ederiz. Çok sağ olun.
Teşekkürler. Görüşmek üzere herkese.
Hoşçakalın.
Bu transkript otomatik olarak çıkarıldı; kayıtla küçük farklar olabilir.