ClickHouse ile Gerçek Zamanlı Büyük Veri Raporları

Günümüz teknolojisinde her saniye binlerce, milyonlarca veri akışı olmaktadır. Akıllı telefonlar, akıllı saatler, bileklikler, beacon teknolojileri, para transferleri, her şey artık dijital olarak yapılmakta ve sonucunda milyonlarca veri oluşmaktadır.

Eski tip veritabanları ile olan çözümlerde, oluşan bu verinin artması, sunucuların işlem gücünü arttırmış, artan işlem gücü daha fazla sunucuya, daha fazla alana ve daha fazla maliyete neden olmuştur. Bu soruna bir çözüm gerektiği için veritabanına yaklaşım yöntemleri de değişmiştir.

Bu aşamada, saklanan verilere erişim yöntemleri değişti (birden fazla katmanda yaklaşılmaya başlandı-cache mekanizmaları), verileri saklama anında çözümler geliştirilmeye başlandı, sürekli erişebilmek için geliştirmeler yapıldı ve sonunda verileri farklı biçimlerde saklayıp onlara çeşitli katmanlar aracılığıyla daha hızlı ulaşılabilmesini sağlayan sistemler geliştirildi ve geliştirilmeye devam ediyor.

Veriler anlamak, içeriğine göre saklamak, erişmek ve tüm bu bahsedilenleri anlık olarak milyonlarca veri için yapmak bir sorun haline geldiğinde, diğerleri arasından sıyrılarak, birçok sorunumuzun çözümü olan ClickHouse ortaya çıktı.

ClickHouse Nedir?

ClickHouse, Yandex.Metrica için geliştirilmiş olan, sütun tabanlı, dağıtık, paralel işlem yapan, yatay genişleyebilen, disk veya bellek üzerinde veri saklayan, SQL desteği olan -standart SQL ile bazı farklılıkları var-, ancak gerçek güncelleme/silme ve transaction desteği olmayan bir OLAP (Online Analytical Processing), Database Management System(DBMS)’dir.

➡ Açık kaynaklı ve ücretsiz bir projedir.

➡ Yandex’in ifadesiyle, dünyadaki en büyük ikinci OLAP projesinde kullanılmıştır. OLAP olduğu için transaction desteği yoktur.

➡ Sorgu sorunlarında kendi içinde yük dengelemesi ve veri tutarlılığı için de diğer çözümlerden farklı mekanizmaları vardır.

➡ DDL desteği sayesinde, sorgular pratik bir şekilde tüm bağlı sunucularda çalışmaktadır.

➡ Veri tutarlılığı, hız, seçilim ve birleştirme, dağıtık çalışma gibi süreçler için tablo yapısı seviyesinde destek sağlamaktadır.

➡ Kullanılmaya başlandığı andan itibaren, özellikle de veri büyüdükçe faydasını ve hızını hissettirmektedir.

➡ Teknik altyapı olarak bakıldığında;

-C++ ile geliştirilmektedir. -JDBC driver doğal olarak sunulmaktadır. -Verileri işlemek için TCP/IP veya HTTP üzerinden çalışabilir. -Linux sunucu üzerinde çalışır ancak burada kendilerinin deyimiyle Ubuntu 12.04 ve üzeri kullanılması önerilir. -Eğer farklı bir distro kullanılacaksa x86_64 mimarisinde SSE 4.2 desteği olmalıdır.

SQL ile Temel Farklar

ClickHouse yapısı gereği SQL desteklemektedir. Ancak bildiğimiz SQL ifadelerinden farklı yazılmaktadır.

Örneğin; adı soyadı aynı olan sonuçlardan bir örnek alınması için SQL’de distinct first_name şeklinde yazılırken ClickHouse bunu uniq(first_name) şeklinde beklemektedir. (Ancak ClickHouse bunu bu şekilde beklediği için, o şekilde yazma zorunluluğu yoktur, bildiğiniz şekilde “distinct” işlemi yapabilirsiniz.) Bu farkın temelinde yatan, hızlı olma problemidir.

Kullanmaya başladıkça farkedeceksiniz ki; projenin kalbini oluşturan C++ kendini sorgularda hissettirmektedir. Sorgulardaki en büyük fark da aggregation için kullanılacak kelimelerin ifadeden ziyade fonksiyon mantığında yazılmasını istemesi ve ALTER işlemleri için farklı bir yazım şekli kullanmasıdır.

Veri Tipleri

ClickHouse genel olarak bildiğimiz veri tiplerinden farklı olarak yazıldığı dilin veri tiplerinde çalışmaktadır. Örneğin MySQL’de kullanılan ‘integer’ işlemini ele alalım.

Yazım farkları yukarıda açıkça görülmektedir.

Tablolarınızı sıfırdan oluştururken veya var olan tablolarınızı ClickHouse’a göç ettirirken, dökümantasyonunda belirttiği tiplerden kendiniz için uygun olanını seçerek projenizi ayağa kaldırabilirsiniz.

Tablo Yapıları

Daha öncesinde MySQL, Cassandra veya benzer bir DBMS ile çalıştıysanız, onlarda sınırlı sayıda tablo yapıları varken, ClickHouse’da daha fazla tablo yapısı olduğunu görürsünüz. ClickHouse’da Distributed, Merge, MergeTree, *MergeTree, Log, TinyLog, Memory, Buffer, Null, File gibi birkaç farklı tablo yapısı vardır. En çok kullanılanlar Distributed, Memory, MergeTree ve alt kırılımlarıdır.

“Distributed” aslında tam bir tablo yapısından ziyade, view olarak çalışır. Tanımı yapılırken de bunun bir yapı olduğu ancak veri barındırmadığı vurgulanmaktadır.

“MergeTree” ve kırılımları bizim büyük sorunlarımız için çözüm oluşturmaktadır. Öyle ki; MergeTree detaylı çözüm için ReplicatedMergeTree, AggregatingMergeTree, SummingMergeTree şeklinde kırılımlar yapmıştır.

Örnek bir senaryo: Kullanıcı bazında içerik tıklanma verisi toplanması

İstenilen: Kullanıcıların içeriğe kaç defa tıkladığını hesaplamak (Bir kullanıcı aynı noktaya birden fazla kez tıklayabilir)

Problem: Bu hesaplama yatay tablolarda ekstra fazla veri yaratacağı için işlemin süresi uzamaktadır.

Çözüm: ClickHouse bu gibi durumlarda, “SummingMergeTree” tablo yapısını kullanarak, aynı kayıtların sayısını kendi içerisinde topladığından, sadece bu alan için bir toplama işlemi yaparak hem mükerrer kayıt sayısının önüne geçer, hem de daha hızlı bir hesaplama işlemi yapmış olur.

Şimdi bizim asıl sorunumuz olan büyük veriler için ClickHouse’un nasıl bir çözüm sağladığına geçebiliriz.

Cluster Kullanımı

Verilerin çoğalması maliyetleri de arttırır demiştik. Veriler önceden beri süregelen yapıda satırlar halinde tutulurlar. Ancak bunun dezavantajı veri arttıkça, dikeyde de kapasite artırmanız gerekmesidir. Çünkü hesaplama işleminde alt alta tüm satırlar incelenmelidir. Ancak column-based sistemlerde veriler sütunlar halinde tutulur ve artış yatay yönde olduğu için, sunucu ihtiyaçlarınız benzer özellikte sunucular yan yana eklenerek çözülebilir.

Bunu normal şekilde değil de, “cluster” adını verdiğimiz, saklayacağımız verileri bir küme içine alarak, veri arttıkça kümenin elemanını değil, kümeyi büyütme yoluyla yapıyoruz.

Bu işlemi yapmak için ClickHouse bize şöyle bir seçenek sunuyor:

“ReplicatedMergeTree” tablo yapısı, verileri aynı küme içerisinde alt küme düğümleri(node) oluşturarak kopyalamaya yarar ve herhangi bir alt kümeden bir elemanın dahi çalışır olması bizim sonucumuzun doğruluğunu değiştirmez.

Distributed tablo yapısı ise bu alt kümelerin kapsayıcı kümesi olarak davranır. Bu sayede biz içeride hangi alt kümelerin olduğunu ve o alt kümelerin nasıl dağıldığını düşünmeksizin sonuçlar alabiliriz. Ayrıca verileriniz için dağıtık alt kümeler oluşturduğunuzda, her alt küme kendi içerisinde sorgulama yaparak size daha hızlı sonuçlar sağlayabilir. Dökümantasyonunda da belirttiği şekilde maksimum 300 node olması tavsiye edilir.

DDL Sorgular

Cluster yapısında çalıştığınızda sunucunuzun her zaman çalışır vaziyette olduğunu bilemezsiniz. Bakımı ve yönetimi zordur. Şunu düşünün: Sunucunuzun donanım veya yazılım güncellemesi yapılacak ve sunucuya bir süreliğine erişim sağlanamayacak. Ancak verilerde bir kesinti olmayacak. Bu durumda hangi sunucunuzun çalışır halde olduğunu bilmediğiniz için, sorgularınızda da değişiklikler olacaktır.

Örneğin; eskiden sadece tek bir IP veya domain’e bağlı node’a istek yaparken, şimdi bir dizi IP veya domain’e bağlı node’lardan çalışır durumunda olanlarına istek yapmalısınız. Hangisinin çalışır olduğunu denetlemek normal şartlarda ekstra bir maliyet ve yönetim ihtiyacı doğurur.

ClickHouse burada bizim durumumuza şu şekilde yaklaşıyor ve diyor ki:

“Sen bana clusterdaki node’ların listesini ver, ben senin için veriyi hangisi çalışıyorsa ona yazarım. Hatta diğerlerine de dağıtırım. Ama bir şartla, sorgularında bunu mutlaka belirtmelisin.”  

İşte bu nedenle, ClickHouse’da bu işi yapmak sunucu seviyesinden başlar ve sorgu seviyesinde biter.

Peki sunucu yapılandırmasında bu nasıl belirtilir?

Cluster  tanımlaması

Dikkat edilmesi gerekenler;

1. Shard(parça) bölümleri replikaları(kopyaları) kapsayabilirken, replikalar shard’ları kapsamaz.
2. Replika sayısı bulunduğu shard için bağımsız olabilir ve hangi shard ne kadar veriyi işleyerek bir sonraki shard’a geçeceğini belirtebilir. Sorgularınıza kuracağınız SQL cümleleri için sadece ON CLUSTER {custom cluster} parçasıyla bunun bulunduğu cluster için çalışmasını sağlayabilir. Bu yöntemle de hangi cluster’ın kaç parçadan, kaç kopyadan oluştuğunu bilmeden, sadece adıyla yazım, anında çalışan herhangi bir node üzerinden tüm verinizi cluster için yazabilir.
3. “ClickHouse kurdum, bununla her şeyi çözerim” düşüncesine kapılmayın. ClickHouse bu işlemi yaparken Zookeeper servisine ihtiyaç duymaktadır ve tanımlaması aşağıdaki şekilde yapılabilir.

<yandex>
. . .
<remote_servers>
    <custom_cluster>
        <shard>
            <weight>1</weight>
            <internal_replication>false</internal_replication>
            <replica>
                <host>example01-01-1</host>
                <port>9000</port>
            </replica>
            <replica>
                <host>example01-01-2</host>
                <port>9000</port>
            </replica>
        </shard>
        <shard>
            <weight>2</weight>
            <internal_replication>false</internal_replication>
            <replica>
                <host>example01-02-1</host>
                <port>9000</port>
            </replica>
            <replica>
                <host>example01-02-2</host>
                <port>9000</port>
            </replica>
            <replica>
                <host>example01-02-3</host>
                <port>9000</port>
            </replica>
        </shard>
    </custom_cluster>
</remote_servers>
. . .
<zookeeper>
    <node index="1">
        <host>example1</host>
        <port>2181</port>
    </node>
    <node index="2">
        <host>example2</host>
        <port>2181</port>
    </node>
    <node index="3">
        <host>example3</host>
        <port>2181</port>
    </node>
</zookeeper>
. . .
</yandex>

Dikkat Edilmesi Gerekenler

➡ Eğer çözümünüzde Zookeeper gerektiren bir yöntem kullandıysanız, herhangi bir durumda ClickHouse sunucunuzu çalıştırmak için, Zookeeper sunucunuz da çalışır vaziyette olmalıdır. Aksi halde sunucunuz çalışır gibi görünür ancak loglara baktığınızda Zookeper’a bağlanamadığı için size hizmet veremediğini görürsünüz.

➡ DDL sorgular Zookeeper üzerinde çalıştığı için, eğer sunucunuza yeni bir node ekler ve bunu cluster’a tanımlarsanız, ClickHouse sizin için (eğer replika ise) bulunduğu alt kümenin verilerini otomatik olarak eşitler. Ancak yüksek kayıt içeren alt kümeler için yeni replika ekleme işlemi çok tavsiye edilmez. En baştan bunun planı yapılarak cluster hazırlanmalıdır.

Özet

Her proje, her ihtiyacınızı karşılayamaz. Bu nedenle çeşitli projeleri deneyimlemek önemlidir. Siz de ihtiyaçlarınızın analizini en baştan doğru şekilde yaparak, kendinize en uygun yöntemi ve çözümü elde edebilirsiniz. Eğer dökümantasyonunda belirttiği kriterler ile, sizin ihtiyaçlarınız uyuşuyorsa, ClickHouse sizin problemlerinizi de çözecektir.

Yayınlanma Tarihi: 21.09.2018