Modern veri mimarilerinin kalbinde yer alan Apache Kafka, y\u00fcksek hacimli olay verilerini g\u00fcvenilir bir \u015fekilde toplama ve da\u011f\u0131tma yetene\u011fiyle \u00f6ne \u00e7\u0131kmaktad\u0131r. Genellikle Kafka ile birlikte an\u0131lan Apache Flink, Apache Spark Streaming veya ksqlDB gibi streaming motorlar\u0131, ger\u00e7ek zamanl\u0131 analiz ve s\u00fcrekli i\u015fleme i\u00e7in vazge\u00e7ilmez ara\u00e7lard\u0131r. Ancak, bu makale, Kafka verilerini SQL ile sorgulamak i\u00e7in her zaman \u00f6zel bir streaming motoruna ihtiya\u00e7 duyulmad\u0131\u011f\u0131 tezini savunmaktad\u0131r. Belirli senaryolarda, geleneksel SQL motorlar\u0131 veya hibrit yakla\u015f\u0131mlar, Kafka verisini do\u011frudan, verimli ve daha az karma\u015f\u0131kl\u0131kla sorgulayabilir; bu da mimari esneklik ve maliyet avantajlar\u0131 sunar.<\/p>\n
Kafka’n\u0131n evrimi ve veri i\u015fleme d\u00fcnyas\u0131ndaki rol\u00fc, geleneksel yakla\u015f\u0131mlarla olan etkile\u015fimini anlamak i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n
Apache Kafka, ba\u015flang\u0131\u00e7ta bir mesaj kuyru\u011fu ve da\u011f\u0131t\u0131k g\u00fcnl\u00fck (distributed log) olarak tasarlanm\u0131\u015f olsa da, zamanla modern veri mimarilerinin temel bir bile\u015feni haline gelmi\u015ftir. Olay odakl\u0131 mimarilerin y\u00fckseli\u015fiyle birlikte, Kafka sadece mesaj iletmekle kalmay\u0131p, ayn\u0131 zamanda kal\u0131c\u0131, \u00f6l\u00e7eklenebilir ve hata toleransl\u0131 bir veri depolama katman\u0131 olarak da i\u015flev g\u00f6rmeye ba\u015flam\u0131\u015ft\u0131r. Art\u0131k bir\u00e7ok kurulu\u015f i\u00e7in birincil veri al\u0131m katman\u0131, hatta bir nevi “veri g\u00f6l\u00fc” (data lake) olarak kabul edilmektedir; bu da ham olay verilerinin uzun s\u00fcre saklanmas\u0131na olanak tan\u0131r.<\/p>\n
Ger\u00e7ek zamanl\u0131 veri analizi, anomali tespiti, s\u00fcrekli ETL (Extract, Transform, Load) ve anl\u0131k raporlama gibi ihtiya\u00e7lar, Apache Flink, Apache Spark Streaming ve ksqlDB gibi \u00f6zel streaming motorlar\u0131n\u0131n do\u011fu\u015funa yol a\u00e7m\u0131\u015ft\u0131r. Bu motorlar, Kafka gibi kaynaklardan gelen s\u00fcrekli veri ak\u0131\u015flar\u0131n\u0131 milisaniye veya saniye gecikmeyle i\u015fleyerek, olay baz\u0131nda karma\u015f\u0131k analizler yapma ve an\u0131nda tepki verme yetene\u011fi sunar. Ama\u00e7lar\u0131, verinin dura\u011fan halini de\u011fil, ak\u0131\u015f halini i\u015fleyerek dinamik i\u00e7g\u00f6r\u00fcler sa\u011flamakt\u0131r.<\/p>\n
Geleneksel ili\u015fkisel veritabanlar\u0131 (RDBMS) ve veri ambarlar\u0131, yap\u0131land\u0131r\u0131lm\u0131\u015f veriyi depolama ve sorgulama konusunda son derece yetenekli olsa da, ak\u0131\u015f halindeki veriyi do\u011frudan i\u015fleme konusunda do\u011fal s\u0131n\u0131rlamalara sahipti. Kafka’n\u0131n dosya sistemi gibi davranmamas\u0131 ve veriyi mesajlar halinde sunmas\u0131 nedeniyle, bu motorlar\u0131n Kafka topic’lerini do\u011frudan bir tablo gibi sorgulamas\u0131 teknik olarak zordu veya m\u00fcmk\u00fcn de\u011fildi. Bu durum, Kafka verisine SQL ile eri\u015fmek isteyenlerin genellikle \u00f6nce veriyi bir veri ambar\u0131na veya ba\u015fka bir kal\u0131c\u0131 depolama birimine aktarmas\u0131n\u0131 gerektiriyordu.<\/p>\n
T\u00fcm analitik ihtiya\u00e7lar ger\u00e7ek zamanl\u0131 ve s\u00fcrekli i\u015fleme gerektirmez. \u0130\u015fte bu noktada, streaming motorlar\u0131na alternatif yakla\u015f\u0131mlar devreye girer.<\/p>\n
Bir\u00e7ok i\u015f birimi, g\u00fcnl\u00fck, haftal\u0131k veya ayl\u0131k raporlar, geriye d\u00f6n\u00fck analizler veya belirli bir zaman aral\u0131\u011f\u0131ndaki \u00f6zet istatistikler gibi batch tabanl\u0131 sorgulamalara ihtiya\u00e7 duyar. Kafka’n\u0131n veriyi kal\u0131c\u0131 olarak saklama \u00f6zelli\u011fi, onu bu t\u00fcr batch sorgulamalar i\u00e7in m\u00fckemmel bir kaynak haline getirir. Veri, belirli bir zaman dilimi i\u00e7inde bir kez i\u015flenir ve sonu\u00e7lar al\u0131n\u0131r; s\u00fcrekli bir ak\u0131\u015fa gerek yoktur. Bu senaryolarda, s\u00fcrekli \u00e7al\u0131\u015fan bir streaming motoru yerine, sorgu an\u0131nda devreye giren bir SQL motoru daha verimli olabilir.<\/p>\n
Kafka’n\u0131n yap\u0131land\u0131r\u0131labilir saklama s\u00fcresi (retention policy) sayesinde, topic’lerdeki veriler haftalarca, aylarca hatta y\u0131llarca saklanabilir. Bu, ge\u00e7mi\u015f olaylar\u0131n herhangi bir zamanda sorgulanabilmesine olanak tan\u0131r. Bir veri ambar\u0131ndaki tabloya benzer \u015fekilde, Kafka topic’leri de belirli bir d\u00f6neme ait t\u00fcm olaylar\u0131 bar\u0131nd\u0131ran bir “olay g\u00fcnl\u00fc\u011f\u00fc” olarak i\u015flev g\u00f6rebilir. Bu ge\u00e7mi\u015f verilere SQL ile do\u011frudan eri\u015fmek, trend analizi, hata ay\u0131klama veya uyumluluk denetimleri i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n
Baz\u0131 analitik i\u015f y\u00fckleri i\u00e7in saniyeler veya dakikalar d\u00fczeyinde gecikme kabul edilebilir bir durumdur. \u00d6rne\u011fin, bir i\u015f zekas\u0131 panosunun 5 dakikada bir g\u00fcncellenmesi veya bir veri bilimcinin ad-hoc bir sorgu \u00e7al\u0131\u015ft\u0131rmas\u0131. Bu t\u00fcr senaryolarda, s\u00fcrekli olarak kaynak t\u00fcketen ve karma\u015f\u0131k bir operasyonel y\u00fck getiren bir streaming motorunun kullan\u0131lmas\u0131 gereksiz olabilir. Do\u011frudan SQL sorgulama, bu t\u00fcr “d\u00fc\u015f\u00fck gecikmeli olmayan” analitik ihtiya\u00e7lar\u0131 daha basit ve maliyet etkin bir \u015fekilde kar\u015f\u0131layabilir.<\/p>\n
G\u00fcn\u00fcm\u00fczde, \u00e7e\u015fitli ara\u00e7lar Kafka topic’lerini do\u011frudan SQL ile sorgulama yetene\u011fi sunmaktad\u0131r.<\/p>\n
Trino (eski ad\u0131yla PrestoSQL), da\u011f\u0131t\u0131k bir SQL sorgu motorudur ve farkl\u0131 veri kaynaklar\u0131n\u0131 (Kafka dahil) tek bir sorguda birle\u015ftirme yetene\u011fiyle bilinir. Trino’nun Kafka connector’\u00fc, Kafka topic’lerini sanal tablolara d\u00f6n\u00fc\u015ft\u00fcrerek standart SQL sorgular\u0131n\u0131n \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131na olanak tan\u0131r. Bu sayede, Kafka’daki mesajlar, s\u00fctunlar ve sat\u0131rlar halinde temsil edilerek kolayca sorgulanabilir. Trino, \u00f6zellikle b\u00fcy\u00fck \u00f6l\u00e7ekli ad-hoc ve batch analitik sorgular\u0131 i\u00e7in g\u00fc\u00e7l\u00fc bir \u00e7\u00f6z\u00fcmd\u00fcr.<\/p>\n
Apache Flink, hem ak\u0131\u015f (streaming) hem de toplu (batch) i\u015fleme yeteneklerine sahip birle\u015fik bir platformdur. Flink SQL, Kafka topic’lerini * Apache Spark SQL:<\/strong> Spark’\u0131n Kafka veri kayna\u011f\u0131 entegrasyonu sayesinde, Kafka topic’leri Spark DataFrames olarak okunabilir ve Spark SQL ile sorgulanabilir. Bu, \u00f6zellikle Spark ekosistemini kullananlar i\u00e7in do\u011fal bir entegrasyon sunar. Do\u011frudan SQL sorgulama yakla\u015f\u0131m\u0131, mimariyi basitle\u015ftirme ve kaynak kullan\u0131m\u0131n\u0131 optimize etme potansiyeli sunar.<\/p>\n S\u00fcrekli \u00e7al\u0131\u015fan streaming motorlar\u0131, ayr\u0131 bir k\u00fcme y\u00f6netimi, izleme, hata tolerans\u0131 stratejileri ve versiyon y\u00fckseltmeleri gerektirir. Bu, operasyonel y\u00fck\u00fc art\u0131r\u0131r ve altyap\u0131 karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 y\u00fckseltir. Kafka verilerini do\u011frudan SQL ile sorgulama, bu ek katman\u0131 ortadan kald\u0131rarak veya en aza indirerek mimariyi \u00f6nemli \u00f6l\u00e7\u00fcde basitle\u015ftirebilir. Mevcut bir veri g\u00f6l\u00fc sorgu motorunu (\u00f6rn. Trino) Kafka’ya ba\u011flamak, yeni bir k\u00fcme kurmaktan daha kolayd\u0131r.<\/p>\n Streaming motorlar\u0131 genellikle 7\/24 \u00e7al\u0131\u015f\u0131r ve s\u00fcrekli olarak CPU, bellek ve a\u011f kaynaklar\u0131 t\u00fcketir. Bu, \u00f6zellikle d\u00fc\u015f\u00fck frekansl\u0131 veya ad-hoc sorgular i\u00e7in maliyetli olabilir. Do\u011frudan SQL sorgulama motorlar\u0131 ise yaln\u0131zca sorgu \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda kaynak t\u00fcketir ve sorgu tamamland\u0131\u011f\u0131nda kaynaklar\u0131 serbest b\u0131rak\u0131r. Bu “kulland\u0131\u011f\u0131n kadar \u00f6de” (pay-as-you-go) modeli, maliyet a\u00e7\u0131s\u0131ndan daha verimli bir yakla\u015f\u0131m sunar, \u00f6zellikle yo\u011fun olmayan i\u015f y\u00fckleri i\u00e7in.<\/p>\n Bu yakla\u015f\u0131m, bir kurulu\u015fun hem ger\u00e7ek zamanl\u0131ya yak\u0131n hem de toplu analitik ihtiya\u00e7lar\u0131n\u0131 tek bir birincil veri kayna\u011f\u0131 (Kafka) \u00fczerinden kar\u015f\u0131layarak daha esnek bir analitik platform olu\u015fturulmas\u0131na yard\u0131mc\u0131 olur. Ayn\u0131 Kafka topic’indeki veri, bir yandan streaming motorlar\u0131 taraf\u0131ndan anl\u0131k i\u015flenirken, di\u011fer yandan do\u011frudan SQL motorlar\u0131 taraf\u0131ndan ge\u00e7mi\u015fe d\u00f6n\u00fck analizler i\u00e7in sorgulanabilir. Bu hibrit yakla\u015f\u0131m, veri platformunun \u00e7ok y\u00f6nl\u00fcl\u00fc\u011f\u00fcn\u00fc art\u0131r\u0131r.<\/p>\n Kafka \u00fczerinde do\u011frudan SQL sorgulaman\u0131n pratik kullan\u0131m alanlar\u0131 olduk\u00e7a geni\u015ftir.<\/p>\n \u015eirketler, ge\u00e7mi\u015fe d\u00f6n\u00fck sat\u0131\u015f verileri, kullan\u0131c\u0131 etkile\u015fimleri veya sistem loglar\u0131 gibi bilgileri Kafka topic’lerinde tutabilir. Do\u011frudan SQL sorgulama ile, bu topic’lerden belirli zaman aral\u0131klar\u0131ndaki \u00f6zet istatistikleri, trendleri veya KPI’lar\u0131 kolayca \u00e7ekebilir ve i\u015f zekas\u0131 panolar\u0131na aktarabilirler. Bu, veri ambar\u0131na ek bir ETL s\u00fcreci olmadan h\u0131zl\u0131 raporlama imkan\u0131 sunar.<\/p>\n Veri bilimciler ve analistler, Kafka’daki ham verilere do\u011frudan SQL ile eri\u015ferek h\u0131zl\u0131 ke\u015fifler yapabilir, hipotezleri test edebilir ve veri kalitesini kontrol edebilirler. Bu, veriyi ba\u015fka bir sisteme kopyalamaya gerek kalmadan an\u0131nda i\u00e7g\u00f6r\u00fcler elde etmelerini sa\u011flar. \u00d6rne\u011fin, belirli bir hata kodunun son 24 saatteki frekans\u0131n\u0131 sorgulamak.<\/p>\n Kafka, veri ambar\u0131 veya veri g\u00f6l\u00fcne giden birincil veri kayna\u011f\u0131 olarak i\u015flev g\u00f6rebilir. Do\u011frudan SQL sorgulama, veri ambar\u0131na veya veri g\u00f6l\u00fcne veri y\u00fcklemeden \u00f6nce \u00f6n analizler yapmak, veri kalitesini kontrol etmek veya veriyi zenginle\u015ftirmek i\u00e7in kullan\u0131labilir. Bu, veri y\u00fckleme s\u00fcre\u00e7lerini daha verimli hale getirir.<\/p>\n A\u015fa\u011f\u0131daki \u00f6rnek, Trino’nun Kafka connector’\u00fc arac\u0131l\u0131\u011f\u0131yla JSON format\u0131ndaki bir Kafka topic’ini nas\u0131l sorgulayabilece\u011finizi g\u00f6stermektedir.<\/p>\n <\/code> Bu yakla\u015f\u0131m\u0131n avantajlar\u0131 olsa da, baz\u0131 \u00f6nemli s\u0131n\u0131rlamalar\u0131 ve dikkat edilmesi gereken noktalar\u0131 vard\u0131r.<\/p>\n E\u011fer i\u015f gereksinimi saniyeler i\u00e7inde s\u00fcrekli g\u00fcncellenen sonu\u00e7lar, anl\u0131k uyar\u0131lar, karma\u015f\u0131k olay i\u015fleme (CEP) veya s\u00fcrekli ETL boru hatlar\u0131 ise, bir streaming motoru vazge\u00e7ilmezdir. Do\u011frudan SQL sorgulama, belirli bir an\u0131n anl\u0131k g\u00f6r\u00fcnt\u00fcs\u00fcn\u00fc veya belirli bir zaman aral\u0131\u011f\u0131ndaki veriyi sorgulamak i\u00e7in daha uygundur, ancak s\u00fcrekli de\u011fi\u015fen bir ak\u0131\u015f\u0131 takip etmek i\u00e7in tasarlanmam\u0131\u015ft\u0131r.<\/p>\n Kafka'daki veriler genellikle JSON, Avro, Protobuf veya d\u00fcz metin gibi \u00e7e\u015fitli formatlarda bulunur. Sorgu motorunun bu formatlar\u0131 anlayabilmesi ve \u015fema evrimini (schema evolution) y\u00f6netebilmesi \u00f6nemlidir. \u015eemas\u0131z veya yar\u0131 yap\u0131land\u0131r\u0131lm\u0131\u015f veriler (\u00f6rn. d\u00fcz JSON) i\u00e7in, SQL sorgular\u0131nda ek parse i\u015flemleri veya veri d\u00f6n\u00fc\u015f\u00fcmleri gerekebilir, bu da sorgu karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 art\u0131rabilir. Avro veya Protobuf gibi \u015femal\u0131 formatlar genellikle daha kolay sorgulan\u0131r.<\/p>\n \u00c7ok b\u00fcy\u00fck Kafka topic'lerini do\u011frudan sorgulamak, sorgu motorunun ve Kafka k\u00fcmesinin performans\u0131n\u0131 zorlayabilir. Geleneksel veritabanlar\u0131ndaki gibi indeksleme veya \u00f6nceden toplanm\u0131\u015f g\u00f6r\u00fcn\u00fcmler (materialized views) gibi optimizasyonlar genellikle do\u011frudan Kafka \u00fczerinde m\u00fcmk\u00fcn de\u011fildir. Sorgu motoru, veriyi okumak i\u00e7in Kafka broker'lar\u0131na g\u00fcvenir. Bu nedenle, sorgulanan veri miktar\u0131, Kafka k\u00fcmesinin kapasitesi, a\u011f gecikmesi ve sorgunun karma\u015f\u0131kl\u0131\u011f\u0131 performans\u0131 do\u011frudan etkiler. Y\u00fcksek QPS (Query Per Second) veya milisaniye gecikme beklenen senaryolar i\u00e7in bu yakla\u015f\u0131m optimize edilmeyebilir.<\/p>\n Apache Kafka, modern veri mimarilerinin temel ta\u015f\u0131 olmaya devam ederken, verilerini i\u015fleme yakla\u015f\u0131mlar\u0131m\u0131z da evrilmektedir. Geleneksel d\u00fc\u015f\u00fcncenin aksine, Kafka verilerini SQL ile sorgulamak i\u00e7in her zaman karma\u015f\u0131k ve s\u00fcrekli \u00e7al\u0131\u015fan bir streaming motoruna ihtiya\u00e7 duyulmayabilir. Trino, Apache Flink SQL'in batch modu veya Spark SQL gibi ara\u00e7lar, Kafka topic'lerini do\u011frudan birer tablo gibi ele alarak, batch analitik, ge\u00e7mi\u015f veri raporlamas\u0131 ve ad-hoc sorgulama gibi bir\u00e7ok kullan\u0131m durumu i\u00e7in g\u00fc\u00e7l\u00fc ve verimli \u00e7\u00f6z\u00fcmler sunar.<\/p>\n Bu yakla\u015f\u0131m, altyap\u0131 karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 azaltma, kaynak t\u00fcketimini optimize etme ve analitik platformlara daha fazla esneklik katma potansiyeline sahiptir. Ancak, ger\u00e7ek zamanl\u0131 ve s\u00fcrekli i\u015fleme gerektiren kritik i\u015f y\u00fckleri i\u00e7in streaming motorlar\u0131n\u0131n vazge\u00e7ilmez oldu\u011funu unutmamak \u00f6nemlidir. \u00d6nemli olan, i\u015f gereksinimlerini do\u011fru bir \u015fekilde analiz etmek ve en uygun arac\u0131 ve mimariyi se\u00e7erek hem performans hem de maliyet a\u00e7\u0131s\u0131ndan en iyi dengeyi sa\u011flamakt\u0131r. Kafka, do\u011fru ara\u00e7larla birle\u015fti\u011finde, hem ak\u0131\u015f hem de toplu analitik i\u00e7in g\u00fc\u00e7l\u00fc bir temel sunar.<\/p>\n C1: Kafka'y\u0131 do\u011frudan SQL ile sorgulamak, Kafka topic'lerindeki veriyi, Apache Flink veya Spark Streaming gibi ayr\u0131 bir streaming motoru \u00fczerinden ge\u00e7irmeden, do\u011frudan bir SQL sorgu motoru (\u00f6rne\u011fin Trino, Flink SQL batch modu) kullanarak sorgulamak anlam\u0131na gelir. Bu motorlar i\u00e7in Kafka topic'leri birer veritaban\u0131 tablosu gibi davran\u0131r.<\/p>\n C2: S\u00fcrekli g\u00fcncellenen, d\u00fc\u015f\u00fck gecikmeli sonu\u00e7lar (milisaniye veya saniye), anl\u0131k uyar\u0131lar, karma\u015f\u0131k olay i\u015fleme (CEP), ger\u00e7ek zamanl\u0131 g\u00f6sterge tablolar\u0131 veya s\u00fcrekli ETL boru hatlar\u0131 gerektiren senaryolarda streaming motorlar\u0131 (Flink, Spark Streaming, ksqlDB) idealdir ve vazge\u00e7ilmezdir.<\/p>\n C3: Ba\u015fl\u0131ca ara\u00e7lar aras\u0131nda Trino (PrestoSQL) ve onun Kafka connector'\u00fc, Apache Flink SQL (\u00f6zellikle<\/p>\n","protected":false},"excerpt":{"rendered":"Kafka Verilerini SQL ile Sorgulamak \u0130\u00e7in Her Zaman Bir Streaming Motoruna \u0130htiya\u00e7 Duyulmaz\nModern veri mimarilerinin kalbinde yer alan Apache Kafka, y\u00fc…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1505],"tags":[],"class_list":{"0":"post-37740","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-sql-2","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nTABLE<\/code> olarak tan\u0131mlayarak bu verilere SQL ile eri\u015fim sa\u011flar. Flink SQL’in batch modu, belirli bir zaman aral\u0131\u011f\u0131ndaki veya t\u00fcm ge\u00e7mi\u015f Kafka verisini sorgulamak i\u00e7in kullan\u0131labilir. Bu, Flink’in ger\u00e7ek zamanl\u0131 ak\u0131\u015f i\u015fleme yeteneklerini kullanmadan, sadece Kafka’daki mevcut veriyi bir kez i\u015flemek isteyenler i\u00e7in idealdir.<\/p>\nDi\u011fer SQL-on-Kafka \u00c7\u00f6z\u00fcmleri<\/h4>\n
\n* ClickHouse Kafka Motoru:<\/strong> Y\u00fcksek performansl\u0131 bir OLAP veritaban\u0131 olan ClickHouse, do\u011frudan Kafka topic’lerinden veri okuyabilen \u00f6zel bir motor sunar. Bu, Kafka’dan al\u0131nan veriyi h\u0131zl\u0131 bir \u015fekilde indeksleyip sorgulamak isteyenler i\u00e7in g\u00fc\u00e7l\u00fc bir se\u00e7enektir.
\n* Confluent ksqlDB:<\/strong> Her ne kadar bir streaming veritaban\u0131 olsa da, ksqlDB, Kafka topic’leri \u00fczerinde SQL benzeri sorgular (KSQL) \u00e7al\u0131\u015ft\u0131rma yetene\u011fi sunar. Hem s\u00fcrekli sorgular (streaming) hem de tek seferlik sorgular (pull queries) i\u00e7in kullan\u0131labilir.<\/p>\nMimari Esneklik ve Maliyet Optimizasyonu<\/h3>\n
Altyap\u0131 Karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 Azaltma<\/h4>\n
Kaynak T\u00fcketimini Optimize Etme<\/h4>\n
Farkl\u0131 Analitik \u0130htiya\u00e7lara Uyum Sa\u011flama<\/h4>\n
Uygulama Senaryolar\u0131 ve Avantajlar\u0131<\/h3>\n
Ge\u00e7mi\u015f Veri Raporlamas\u0131 ve Panolar<\/h4>\n
Ad-hoc Analizler ve Veri Ke\u015ffi<\/h4>\n
Veri Ambar\u0131\/G\u00f6l\u00fc Entegrasyonu<\/h4>\n
Kod \u00d6rne\u011fi (Trino ile Kafka sorgulama)<\/h4>\n
-- Trino'da Kafka connector yap\u0131land\u0131rmas\u0131 (\u00f6rnek)\n-- Bu yap\u0131land\u0131rma genellikle Trino sunucusunun 'catalog' dizininde\n-- 'kafka.properties' ad\u0131nda bir dosya i\u00e7inde yap\u0131l\u0131r.\n-- connector.name=kafka\n-- kafka.nodes=kafka1:9092,kafka2:9092\n-- kafka.table-names=my_topic_json,my_topic_avro\n-- kafka.default-schema=default\n-- kafka.hide-internal-columns=true\n\n-- JSON format\u0131nda bir Kafka topic'ini sorgulama\n-- 'my_topic_json' adl\u0131 topic'ten gelen JSON mesaj\u0131n\u0131 ayr\u0131\u015ft\u0131rarak\n-- belirli s\u00fctunlara eri\u015fiyoruz.\nSELECT\n CAST(json_parse(message) AS ROW(id VARCHAR, event_time TIMESTAMP, value DOUBLE)).id AS event_id,\n CAST(json_parse(message) AS ROW(id VARCHAR, event_time TIMESTAMP, value DOUBLE)).event_time AS event_timestamp,\n CAST(json_parse(message) AS ROW(id VARCHAR, event_time TIMESTAMP, value DOUBLE)).value AS event_value,\n _partition_id, -- Kafka partition ID'si\n _offset -- Kafka offset'i\nFROM kafka.default.my_topic_json\nWHERE _partition_id = 0 AND _offset BETWEEN 1000 AND 2000\nLIMIT 10;\n\n-- E\u011fer Kafka verisi Avro veya Protobuf gibi \u015femal\u0131 bir formatta ise,\n-- sorgulama daha basit olabilir ve \u015fema otomatik olarak alg\u0131lanabilir:\n-- SELECT * FROM kafka.default.my_topic_avro LIMIT 10;<\/pre>\n
\nBu \u00f6rnekte, json_parse<\/code> fonksiyonu JSON string'ini bir yap\u0131ya d\u00f6n\u00fc\u015ft\u00fcr\u00fcr ve CAST<\/code> ile belirli s\u00fctunlara eri\u015fim sa\u011flan\u0131r. _partition_id<\/code> ve _offset<\/code> gibi dahili Kafka s\u00fctunlar\u0131 da sorgulama i\u00e7in kullan\u0131labilir.<\/p>\nDikkat Edilmesi Gerekenler ve S\u0131n\u0131rlamalar<\/h3>\n
Ger\u00e7ek Zamanl\u0131 S\u00fcrekli \u0130\u015fleme \u0130htiya\u00e7lar\u0131<\/h4>\n
Veri Formatlar\u0131 ve \u015eema Y\u00f6netimi<\/h4>\n
Performans ve \u00d6l\u00e7eklenebilirlik Fakt\u00f6rleri<\/h4>\n
Sonu\u00e7<\/h3>\n
SSS (S\u0131k Sorulan Sorular)<\/h3>\n
S1: Kafka'y\u0131 do\u011frudan SQL ile sorgulamak ne anlama geliyor?<\/h4>\n
S2: Ne zaman bir streaming motoru kullanmal\u0131y\u0131m?<\/h4>\n
S3: Hangi ara\u00e7lar Kafka \u00fczerinde SQL sorgulamay\u0131 destekler?<\/h4>\n