lombak şehidi

 Airflow ile bir dag icerisinde paralelde tasklar calistirabiliriz evet bu dogru. Ancak kac taski anyni anda paralel calistirabilirz bu birkac seye bagli.  1- Executor Hangi executor'u kullaniyorsunuz? Airflow'u lokal olarak kurdugunuzda default olarak SequentialExecutor kullaniyor. Ki bu da zaten paralel calistirma imkani vermiyor. Yine lokalde tek makinede ama birden fazla task calistirmak istersek bu sefer LocalExecutor kullanabiliriz. Zaten gerisi ( CeleryExecutor, DaskExecutor, KubernetesExecutor, CeleryKubernetesExecutor ) paralel calistirma uzerine kurulu. Ozet olarak en az LocalExecutor ile calisiyor olmamiz lazim ki paralelizasyon ayarlamasi yapabilelim.  2- Airflow paralelizm Tum daglarda (ayni anda birden fazla dag da calisabilir sonucta) ayni anda toplamda kac paralel task calisabilecegini oncelikle ayarlamamiz gerekiyor. Cunku bir ust limit. Bunu ayarlamanin 2 yolu var. Birincisi airflow.cfg dosyasindan bu ayari degistirebiliriz ya da airflow scheduler ...

Daha once dosya ve klasor izinleri ne gozatmistik. Bu gorece kisa postta ise, genel olarak linuxun kullanici ve gruplari nasil yonettigi hakkinda konusacagiz. Kullanicilar Sistemde tanimli kullanicilarla ilgili bilgi almak icin passwd dosyasi incelenebilir.  $ cat /etc/passswd root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin ... Adinda password gecse de parola icermeyen bu dosya bize sistemdeki kullanicilarin bir listesini verir. Kullanici adindan sonra gelen x, o kullanicinin sisteme bir parola ile login oldugunu gosterir. Ornegin root kullanicisindan parola olmadigini goruyoruz. Daha sonra userID ve groupID numaralari geliyor. Takiben kullanicinin home directory'si ve son olarak da default shell path'ini goruyoruz.  Peki neden bu kadar fazla kullanici tanimli ve garip isimleri var? Bu kullanicilar sistem kullanicilari olup bazi tasklar bu kullanicilar uzerinden yerine getirilir.  Gruplar Benzer sekilde ...

Bu postta linux sistem kaynaklarini ve bu kaynaklari kullanan processleri monitor etme konularina deginecegiz.  Sistem Bilgisi Monitor edemedigimiz birseyi iyilestiremeyiz. Bu yuzden /proc klasoru ile basliyoruz. Bu klasor, sistem ile ilgili bilgilerin tutuldugu virtual files barindirir. Ornek olarak RAM ile alakali bilgileri su sekilde gorebiliriz: $ ls /proc -r--r--r-- 1 root  root    0 Jan 20 06:42 cgroups -r--r--r-- 1 root  root    0 Jan 20 06:42 cmdline -r--r--r-- 1 root  root    0 Jan 20 06:42 cpuinfo -r--r--r-- 1 root  root    0 Jan 20 06:42 filesystems -r--r--r-- 1 root  root    0 Jan 20 06:42 interrupts -r--r--r-- 1 root  root    0 Jan 20 06:42 loadavg -r--r--r-- 1 root  root    0 Jan 20 06:42 meminfo ... $ cat meminfo  MemTotal:       66929712 kB MemFree:        40141688 kB Buffers:           3...

The File Mode Dosya modu, uc farkli izin barindiri. User, group ve others. Her biri icin de uc farkli moda sahiptir: Read, Write ve Execute. Ornek olarak sistemdeki hosts dosyasinin izinlerini inceleyelim: :~/lnx$ ls -l /etc/hosts -rw-r--r-- 1 root root 539 Jan 16 05:39 /etc/hosts Ilk karakter listelenen ogenin tipini belirtir. Bunlar: - : dosya d : directory p : named pipe l : symlink b : block device c : character device s : socket Bu karakterden sonra 3 karakterden olusan 3 obek bulunur. Her bir obek aslinda read, write ve execute yetkilerini temsil eder. Eger yetki var ise karakteri gosterilir, yetki yok ise (-) yani dash gosterilir. Okuma yazma yetkisi olan ama execute yetkisi olmayan bir obek su sekilde gorunecektir: rw- Bu sekilde 3 karakterle gostermek yerine bir sayi ile de gosterilebilir. Her bir yertkiyi bir bit olarak dusunursek, yukaridaki obek su sekle donusur: 110 Bu da sayi olarak 0 + 1*2 + 1*2^2 = 6 olur.  Bu sekilde 3 farkli obek var demistirk. Birincisi, bu dosya...

Baya bir suredir devlog yazmiyorum. Yine bir solukta okuyacaginiz bir devops / dataops macerasi ile karsinizdayiz.   Day 1 Is yerinde tamamen iki farkli ortamda calismak durumundayiz. Birtanesi is yaptigimiz sirketin super secure data-centeri otekisi de kendi sirketimizin on-premises makinesi. Bu iki farkli ortam uzerinde dagilmis bir airflow pipeline'a ihtiyac var. Bakalim nelerle karsilacagiz.  Diyelim ki is yaptigimiz sirket X, kendi sirket makinemiz ise Y.  X'ten Y'ye rest api , ssh veya baska hicbir sekilde ulasilamiyor. Ama Y'den X'e ssh yapilabiliyor.  Ama airflow dag X'te basladigi icin, X'ten Y'ye bir trigger gerekiyor. Tersi olsa kolaydi cunku ssh imkani var Y'den X'e. Durum asagi yukari soyle: Tek iletisimimiz sshfs uzerinden mount edilebilen MapRFS olarak gozukuyor. Simdi plan su: 1. X'teki DAG, isi bittigi ve Y'dekini trigger etmek istedigi zaman MaprFS uzerinde belirlenmis bir lokasyona bir dosya olusturacak 2. Y'deki ma...

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 is...