lombak şehidi

Bazi birtakim workflow'lar icin remote bir makineden bir klasoru airflow'un calistigi makineye indirmem gerekiyor. Olaylar gelisiyor.  Abi benim konuyla en ufak bir alakam yok. Ilk hedef SFTPOperator, cunku bu operator ile verilen bir ssh connection ile istenilen dosya remote makineden kopyalanabiliniyor. ANCAK, ben dosalarla tek tek ugrasamam. Cunku cok dosya var ve bana recursive bir operasyon gerekiyor. AMA, arastirdigim kadari ile SFTPOperator'u recursive bir dosya islemini desteklemiyor. Yol ayrimina geliyoruz: 1. Remote makinedeki kopyalancak directory'deki tun dosyalari listeleyip ona gore bir loop icerisinde tek tek indirmek gerekiyor, 2. Remote makineden kopyalayacagim directory'i, host makineye mount etmek. Bu sayede kopyalamaya gerek kalmayacak ve buradaki dosyalari sanki local dosyaymis gibi isleyebilecegiz.  Birinci yol cok killi yunlu, ic ice birsuru dosyalar var, bunlari manuel olarak recursive bir sekilde indirmek cok zor. Ikinci secenek su sekilde c

 O kadar ovdukten sonra Spark'in kurulumna gecelim.  https://spark.apache.org/downloads.html adresinden, spark versiyonu ve handi Hadoop dosya sistemine karisilik calismasi gerektigini belirtiyoruz. Spark, Hadoop'un hdfs (hadoop distributed file system) kullandigi icin, uyumlu bir versiyon secmemiz gerekiyor.  Ben simdi deneme icin windows uzerinde kurulum yapacagim. O yuzde Spark 3.0 ve Hadoop 3.2 ve uzeri destegini secip indiriyorum. Ek olarak sadece JDK gerekli.  Simdi inen tar ball'ini 7zip gibi biseyle extract edip, C drive'a kopyaliyorum. Spark'in executablelari bin klasorunde oldugu icin komut satirindan kolay calisabilmek adina C:\spark\bin yolunu environment variables'tan system path'ina ekliyorum. ve bir terminal acip (power shell), spark-shell komutunu giiyorum. Dakika 1 gol 1,   hata ile karsilasiyorum. Ama bu bir spark bug'i ve cozumu icin bize winutils.exe ve hadoop.dll dosyalari gerekli.  https://github.com/steveloughran/winutils adresinde

"Dununu bilmeyen, gununu gun edemez" -Lombak Sehidi, 2020 2004, Google Paper Simplified data processing on large clusters adiyla bir makale yayinliyor Google, sene 2004. Herkes bi sasiriyor. Zaten google'i google yapan en buyuk araclardan bir tanesi da buyuk datalari kolay isleyebilmesi olmustur. Bu paper'da, MapReduce programlama paradigmasini anlatiyorlar. Kendi implementasyonlarindan bahsetmiyorlar ancak bunun C++ ile yapildigi biliniyor ve hicbir zaman open source yapilmadi.  2006, Yahoo Hadoop Google paper'i yayinlandiktan sonra Yahoo'daki abiler de okuyor tabi. 'way aq cakallari` diyerek ise girisiyorlar. MapReduce paradigmasini kullanan opensource, Java tabanli bir framework'u hayata geciriyorlar ki ismi de Hadoop. 2009 Phd UC Berkley, Spark uc sene falan hadoop ile ugrasan big data camiasi, onun da kisitlarini yavas yavas kesfetmeye basliyor. cesitli burun kivirmalar, homurdanmalar basgosteriyor. ilk baslarda bayila bayila MapReduce joblari ya

Daha da cok ovecegiz Problem Cok buyuk ve cesitli verileri (data volum and variety) belirli bir sure icerisinde islemek gerekiyor.  Cozum Bircok cozum var.  Grep Binlerce text dosyasi uzerinde bir grep komutu ile cok guzel data isleyebilirim. Ama bu islemi sadece tek bir bilgisayar uzerinde yapabilirim degil mi? Eger elimdeki data tek bir bilgisayara sigmayacak kadar buyukse bu secenek duser.  MapReduce Bu problemi goren yetkililer MapReduce adini verdikleri bir programlama paradigmasi ile cikip gelmisler.  Bu sayede birden fazla makine uzerinde data islemek mumkun hale gelmis. Baya bir sure de bu yapiyi kullanmislar mutlu mesut. Spark Ancak, mapreduce uygulamari yazmak cok fazla kodlama gerektirmesi, harddisk islemini cokca barindirmasi gibi  bagzi kotu taraflarini goren bir abimiz, ben hafiza bazli, abstractionlari cok guzel bir framework yazayim demis. Adini da Spark koymus. - Daha az kod yazmayi gerektiriyor. Hatta uygulamaniz dagitik calisacakmis gibi bile gorunmuyor. Cunku abstra

Operations Readiness, bir uygulamanin hangi asamada hangi sartlari saglamasi gerektigini belirler bir belgedir. Buradaki tum asamalar tamamen arbirtary yani musteriden musteriye gore degisebilir ama genel mantik ayni kalacaktir.  Uygulama asamalari su sekilde olabilir: POC Proof of concept, yani bir fikrin test edilmesi ve olup olmadigini yoksa milletin gotunden element mi uydurdugunun, umut tacirligi mi yaptiginin kanitlandigi, ak got karagotun ortaya ciktigi asamadir. MVP Minimum viable product, bu asamada fikir implemente edilebildigi ortaya cikmistir. Ancak bastan sona bir kere cok az ozellik ile implemente edilip, ne kadar fayda sagladigi, bir yarali parmaga iseyip isemediginin anlasimasi gereken asamadir. Yoksa, hassiktir lan ne gerek vardi da denilebilir, ki ben gecmiste orneklerini gordum, siktiri yedim.  PROD bu asamada artik tamam lan guzel oldu denilip musterilere dagitilmaya baslandigi asamadir.  Bu her asamada farkli niteliklerde: - Loglama - Monitor etme - CI/CD otomasyon

 Nasil ki bir program branch'laniyorsa (tabirine sokayim), hayatta da oyle yol ayrimlari var. Ama zannetmeyin ki bu yol ayrimlarinda koskocam tabelalar asili ve sizin durup uzun uzun hangisini sececeginizi dusunecek vaktiniz var. Yok. Tablo oyle degil.  Yol ayrimlari her saniye karsimiza cikiyor. Nasil ki bir CPU aslinda hicbir zaman bos calismiyorsa (system idle), hayat ta aslinda bos durmuyor. Suan bu yaziyi yazmaya devam etmeli miyim yoksa birakmali miyim? Bu bir yol ayrimi ornegin. Ve sadece tek bir kez karisma cikmiyor, her saniye bu ayrim var ve ben yazmaya devam ettigim surece aslinda yazmayi secmis oluyorum.  Varmak istediginiz hedefe giden yol da aynen bu sekilde. Hollywood bize basariyi birkac gece sabahlama seklinde gosterse de oyle degil. Basari sikici bir hikaye, gercek basari hikayesinden filim cikmaz. Her saniye, her yol ayriminda dogru olan yolu secmek gerekiyor.  Enemy Dusman su ki cok fazla kere secim yapmak zorunda kaliyoruz, her yaptigimiz secim bir butceden yiy

Surucusuz araclarin istatistiksel olarak validate ve verify (fark ne ki acaba?) edileblimesi icin, cok fazla simulasyon kosturmak gerekiyor. Ama bu simulasyonlar da surucusuz aracin operational design domain (ODD) 'inin baya bir kapsamasi gerekiyor. Yani ben duz yolda hic etrafta arac yokken istersen 10 milyar km simulasyon calistirayim, ODD'nin cok az bir kismini test etmis olurum.  Ne yapmak lazim? Senaryo bazli calismak suanda endustride standart olma yolunda. Aslinda bu  isler baya yeni oldugu icin oturmus bir yaklasim yok. Iste Pegasus projesi biseyler baslatti, simdi ASAM'in yeni yeni gelistirdigi OpenX standartlari var. Son olarak da birkac start-up bu statistical validation olayi icin urunler gelistirmeye baslamis durumda.  Senaryo? Evet, surucusuz aracin gercek hayatta karsilasabilecegi durumlarin bir on listesi cikartilip, mesela onde giden bir aracin takip edilmesi (follow-vehicle senaryosu), sonra bu senaryolar parametrize ediliyor. Iste takip mesafesinden tutun

Airflow tasklarina database transaction'lari gibi gormek gerekir. Hicbir zaman yarim output ortaya koymayiniz ve her calistiginda ayni input icin ayni outputu verecek sekilde ( idempotent ) tasarlayiniz. Neden? Cunku bu task fail edebilir ve tekrar calisabilir, bu durumda: 1. INSERT kullanmayin bunun yerinde UPSERT kullanin (eger ki database islemi yapiliyor ise task icerisinde) 2. Sadece belirli bir partition'a yazin veya partition'dan okuyun. Sakin ola ki en son guncel datayi okuyayim demeyin. Bir airflow taskinin ne zaman calisacagi garanti edilemez. Yani farzi misal 1 ay sonra bir farkettiniz ki aslinda bir ETL job'unda bug var. Bu sefer tum gecmisi backfill etmeniz gerekecek. Bu durumda task icerisinde enson datayi oku derseniz olay patlar. Bunu yerine executin_data argumani kullanilmalidir ki Airflow backfill ederken verilen bir tarih icin calisan dag gerekli partition'lari okuyabilsin / yazabilsin.  Ozetle bir dag'i verilen argumanlar icin 50 kere de ca

OpenLABEL bir standart. Tam da olmadi daha, standart olma asamasinda, suan proposal paper yayinlandi.  Amac Otonom araclarin kendi etrafini algilamasi gerekiyor. Bunu saglayan da perception stack adi verilen teknolojiler butunu. Bu stack'in gelistirme asamalarinda en temel unsur da, etrafin label edilmesi. Yani bir otonom arac etrafi nasil algiliyor / nasil algilamasi gerek?  Sensor datalari (kamera, lidar, radar, yurek...) bir sekilde annotate edilmesi gerekiyor. Bu isler de label verilerek yapiliyor. Simdi burada her uretici kendi basina bir label formati ve standardi olusturuyor, kullaniyor. Ama bu uzun vadede buyuk sikintilar doguruyor. Iste bu datalar firmalar arasinda paylasilamiyor, gerekli tooling tum formatlari kapsayacak sekilde gelistirilemiyor.  Ama tum firmalarin kabul ettigi / edebilecegi bir standart olsa oyle mi olur? Bu acidan oturdu birkac firma ve bir standart gelistirmeye calisiyor suanda. OpenLABEL standarti su 3 konuya cozum getiriyor: 1. Label ve annotation f

 Oncelikle spotify acilir.  Hayir, long story short , test yazmaya baslayacagiz. Neden? Simdi ideal dunyada yasamadigimiz icin bir kod parcasini yaziyoruz ve calismasini bekliyoruz ama beklenen gibi calismiyor. Hele ki cok fazla Dataframe ile calisiyorsaniz, scala bile olsa type system bize yardim etmiyor demektir. Bu durumda yok efendim o columnun adi oyle degildi, yok bu Dataframe'de bu col yoktu aslinda falan gibi birsuru ufak tefek hata yasaniyor.  Zaten spark uygulamasini calistirmak biraz zaman aliyor. O acidan eger test yazarak baslanmaz ise cok zaman kaybi yasandigini ben bizzat kendi denemelerimde defaatle gordum. Nasil? AnyFlatSpec ve ShraedSparkSession ile. Birincisi zaten test kutuphanesi, standart. Ikincisi de bir yaklasim. Bir trait olusturup icerisinde shared bir spark session olusturuyoruz, sirf local testing icin. Daha sonra bunu istedigimiz kadar test icerisinde kullanabiliriz. Bu sayede her test icerisinde yeni bir sparkSession olusturmak zorunda kalmiyoruz ki bu

Bu hususlara dikkat ememiz gerekiyor: Pod resources Istenecek resource'lari birer Variable seklinde airflow'a kaydedersek ilerde farkli resourcelar istemek icin dag koduna dokunmamiza gerek kalmaz. Ayni zamanda Variable kullanildiginda default deger de verilebiliyor.  resources = {     'request_memory': Variable.get("pod_memory", default_var='128Gi'),     'limit_memory': Variable.get("pod_memory", default_var='128Gi'),     'request_cpu': Variable.get("pod_cpu", default_var='128Gi') } Seklinde belirtebiliriz. Buradaki birimler enteresan, ben cpu'yu 1 olarak verdim ama, micro-cpu olarak da verebiliyorsunuz. (o da neyse gari) Podunuz gec mi kalkiyor? Ortam kosullarina gore bazen pod'a resource allocate edilmesi biraz zaman aliyor. (bkz bir onceki post, 1 gun bekledi gene olmadi ama bu bir edge case). Bu durumda KubernetesPodOperator bir muddet bekliyor (default kac bilmiyorum dokumantasyonda yaza

Resource davasi Efendim paylasimli bir k8s clusterini kullanmaktayiz. Data cok buyuk aman aman bir data degil, her bir islenecek dosya bir pod'un hafizasina sigacak kadar aslinda.  Ama her he hikmetse acayip bir memory kullanimi var. Bas supheli ise pandas. Pandas ile baya bir interpolasyon ve forward/backward fill islemleri yapiyoruz. Tabi memory profiling yapmadan buradan atip tutuyoruz.  Esas sikinti su ki, ilk bastan itibaren 32Gb Ram ve 6 cpu ile ayaga kalkan podlarin genelde basarili oldugu gorulmus olacak ki boyle bir gelenek olusmus. Ama bu resource'lara sahip pod kaldirmak, hele ki airflow icerisinden 20 tanesini ayni anda kaldirmak cok zor gozukuyor. Cunku cluster'da bu kadar resource hemencecik bulunmuyor.  Ama bence zaten 6 tane cpu cok gereksiz, uygulama python uygulamasi zaten, tek core kullanabiliyor. Ama bunun yaninda pandas multi-core islem yapiyor mu bilmiyorum. Bakmak lazim. Aslinda adam gibi memory profiling yapmak lazim ama, who has time ? Pandas tek da

 Not almak isimizin cok onemli bir parcasi. Ben de kac zamandir `not alma` konusunda daha iyi olmaya calisiyorum ancak optimal bir cozume vardigimi hala daha hissetmiyorum. Beklenti - Notlar anlasilir ve belli mantik baglaminda olmali, yani birbirine baglanabilmeli - Kolayca ulasilbilir/aranabilir olmali - Ekstra tatava istemiyorum. Cok kisitli olan beyin gucumu optimal sekilde kullanmak istiyorum.  Neleri denedim? - Notion : Baslangicta cok guzel gozukuyordu. Ancak text ile kiyaslandiginda cok fazla merasimi var. Ben surekli garip garip widgetlar eklemek istemiyorum.  - MS One Note : Bu biraz daha derli optlu Notion'a gore ama buna da tam alisamadim. - VS Code : Evet geldik dolastik gene kurkcu dukkanina. Evet arkadaslar benim oturtabildigim en iyi not alma sekli text dosyalari seklinde. Her seferinde bunu sorguloyurm ama daha iyisini bulamiyorum. Surekli aklimda `text is the king` mottosu var. Notlari dosyalar seklinde notes klasoru altinda tutuyorum. Markdown da kullanilabilir a

 Birinci bolumde isin genelini hallettik ama gene de bu OpenShift ile auth mevzusu killi yunlu, sevmedigim bir mevzu. Gecen sefer bunu gecici token ile cozmustuk, airflow calistiran docker container'e kubeconfig dosyasini mount ederek. Ama ortaya cikti ki uzun vadeli token olmuyor. O yuzden airflow calistiran docker container icerisine OC client download edip, onu username password ile authentica tedip, kubeconfig dosyasini guncelletmemiz gerekiyor.  Service account token Bal gibi de oluyor. Uzun vadeli token alabiliyorsunuz eger ki service account'unuz var ise .  Simdilik bu yontem ile ilerlemeyi uygun buluyorum. Cunku OC client download etmek icin custom docker image olusturmak gerekcek ve bir suru is cikaracak. Ayrica bu cozum zaten gecici olur cunku final hedefte bu airflow'u zaten OpenShift uzerinde calistirmak var ve bunu yaptigimizda token'i direk mount ediyor olacagiz.  Umarim bu hikaye burada biter ve biz onumuze bakariz.  Hoscakalin. 

Baaazi dosyalari isleyerek baaazi output ureten bir pipelinimiz var.  Bu dosyalari hizli isleyebilmek icin, python'da yazdigimiz uygulamayi dockerize edip, k8s uzerinde paralel calistiriyoruz. Ancak elle yapiyoruz bu isi. Ne kadar da amelece.  Simdi bunu alip, Airflow ile otomatize edelim. 1. Gun Mevcut Yontem Halihazirda dosyalari manuel olarak 20 farkli klsore boluyoruz. Daha sonra 20 farkli Pod kaldirip bu klasorleri parametere olarak veriyoruz. Klasorler de ayrica distributed bir file storeage uzerinde bulunuyor, volume mount ile hallediyoruz. Haliyle pod icerisinde calisan python uygulamasi sadece kendine verilen yol'daki dosyalari isliyor. Boylece kimse kimsenin isine karismadan butun dosyalari paralel olarak isliyoruz.   Ama otomatize edebilmek icin cok da iyi bir yontem degil.  1. Elle (veya hatta otomatize olarak) dosyalari klasorlere bolmek istemiyorum 2. Pipeline'i kolay bir sekilde trigger edebilmek istiyorum 3. Parallesim'i kolayca ayarlayabilmek istiyorum