Bu makale ben ve meslektaşım Kai Dai tarafından ortak yazılmıştır. Her ikimiz de aylık 800 milyon aktif kullanıcıya sahip bir müzik akışı hizmet sağlayıcısı olan Tencent Music'te (NYSE: TME) veri platformu mühendisleriyiz. Burada rakamı düşürmek övünmek değil, zavallı iş arkadaşlarımla benim her gün uğraşmak zorunda kaldığımız veri denizine dair bir ipucu vermektir. ClickHouse'u Ne İçin Kullanıyoruz? Tencent Music'in müzik kütüphanesi tüm biçim ve türlerdeki verileri içerir: kayıtlı müzik, canlı müzik, ses kayıtları, videolar vb. Veri platformu mühendisleri olarak bizim görevimiz, ekip arkadaşlarımızın daha iyi kararlar alabilmesini sağlayacak bilgileri verilerden ayrıştırmaktır. kullanıcılarımızı ve müzik ortaklarımızı desteklemek. Özellikle şarkıların, şarkı sözlerinin, melodilerin, albümlerin ve sanatçıların çok yönlü analizini yapıyor, tüm bu bilgileri veri varlıklarına dönüştürüyor ve bunları envanter sayımı, kullanıcı profili oluşturma, metrik analizi ve grup hedefleme için dahili veri kullanıcılarımıza iletiyoruz. . Verilerimizin çoğunu, verileri çeşitli etiket ve metrik sistemlere koyduğumuz ve ardından her nesneyi (şarkılar, sanatçılar vb.) ortalayan düz tablolar oluşturduğumuz çevrimdışı bir veri platformu olan Tencent Veri Ambarı'nda (TDW) saklayıp işledik. Daha sonra düz tabloları analiz için ClickHouse'a, veri arama ve grup hedefleme için Elasticsearch'e aktardık. Daha sonra veri analistlerimiz ihtiyaç duydukları etiket ve metriklerin altındaki verileri kullanarak farklı kullanım senaryolarına yönelik veri kümeleri oluşturdular ve bu sırada kendi etiket ve metriklerini oluşturabildiler. Veri işleme hattı şuna benziyordu: ClickHouse'la İlgili Sorunlar Yukarıdaki işlem hattıyla çalışırken birkaç zorlukla karşılaştık: : Sütunların kısmi güncellemesi desteklenmiyordu. Bu nedenle, veri kaynaklarının herhangi birindeki herhangi bir gecikme, düz tabloların oluşturulmasını geciktirebilir ve dolayısıyla veri zamanlılığını zayıflatabilir. Kısmi Güncelleme : Farklı etiketler ve metrikler altındaki veriler farklı sıklıklarda güncellendi. ClickHouse düz masalarla başa çıkmada ne kadar başarılı olsa da, tüm verileri düz bir masaya dökmek ve onu günlere göre bölmek, beraberinde gelen bakım maliyetinden bahsetmek bile büyük bir depolama kaynağı israfıydı. Yüksek depolama maliyeti : Mimari açıdan bakıldığında ClickHouse, depolama düğümleri ile bilgi işlem düğümlerinin güçlü birleşimiyle karakterize edildi. Bileşenleri büyük ölçüde birbirine bağımlıydı ve bu durum kümelenme istikrarsızlığı risklerini artırıyordu. Ayrıca ClickHouse ve Elasticsearch'teki birleştirilmiş sorgular için çok sayıda bağlantı sorunuyla ilgilenmek zorunda kaldık. Bu çok sıkıcıydı. Yüksek bakım maliyeti Apache Doris'e Geçiş Gerçek zamanlı bir analitik veritabanı olan , sorunlarımızı çözerken tam olarak ihtiyaç duyduğumuz birkaç özelliğe sahiptir: Apache Doris : Doris, çok çeşitli veri modellerini destekler; bunların arasında Toplu Model, sütunların gerçek zamanlı kısmi güncellemesini destekler. Buna dayanarak ham verileri doğrudan Doris'e aktarabilir ve orada düz tablolar oluşturabiliriz. Alım şu şekilde oluyor: Öncelikle Kafka'ya veri yüklemek için Spark'ı kullanıyoruz; daha sonra, artan veriler Flink aracılığıyla Doris ve Elasticsearch'e güncellenecektir. Bu arada Flink, Doris ve Elasticsearch'ün yükünü hafifletmek için verileri önceden toplayacak. Kısmi güncelleme : Doris, Hive, Iceberg, Hudi, MySQL ve Elasticsearch'te çok tablolu birleştirme sorgularını ve birleştirilmiş sorguları destekler. Bu, büyük düz tabloları daha küçük tablolara ayırmamıza ve bunları güncelleme sıklığına göre bölümlendirmemize olanak tanır. Bunu yapmanın faydaları arasında depolama yükünün hafifletilmesi ve sorgu veriminin artması yer alır. Depolama maliyeti : Doris basit mimariye sahiptir ve MySQL protokolüyle uyumludur. Doris'in devreye alınması, diğer sistemlere bağımlı olmaksızın yalnızca iki süreci (FE ve BE) içerir, bu da işletimi ve bakımı kolaylaştırır. Ayrıca Doris, harici ES veri tablolarının sorgulanmasını da destekler. ES'deki meta verilerle kolayca arayüz oluşturabilir ve ES'deki tablo şemasını otomatik olarak eşleyebilir, böylece karmaşık bağlantılarla boğuşmadan Doris aracılığıyla Elasticsearch verileri üzerinde sorgular gerçekleştirebiliriz. Bakım maliyeti Dahası Doris, HDFS ve S3 gibi uzak depolama birimlerinden toplu içe aktarma, MySQL binlog ve Kafka'dan veri okuma ve MySQL, Oracle ve PostgreSQL'den gerçek zamanlı veri senkronizasyonu veya toplu içe aktarma dahil olmak üzere birden fazla veri alma yöntemini destekler. Tutarlılık protokolü aracılığıyla hizmet kullanılabilirliğini ve veri güvenilirliğini sağlar ve otomatik hata ayıklama yeteneğine sahiptir. Bu, operatörlerimiz ve bakımcılarımız için harika bir haber. İstatistiksel olarak konuşursak, bu özellikler depolama maliyetimizi %42, geliştirme maliyetimizi ise %40 oranında azalttı. Doris'i kullanımımız sırasında, açık kaynak Apache Doris topluluğundan çok sayıda destek aldık ve şu anda Apache Doris'in ticari bir sürümünü çalıştıran SelectDB ekibinden zamanında yardım aldık. İhtiyaçlarımıza Hizmet Edecek Daha Fazla İyileştirme Semantik Katmanı Tanıtın Veri kümelerinden bahsetmişken, işin iyi tarafı, veri analistlerimize etiketleri ve ölçümleri kendilerine uygun bir zamanda yeniden tanımlama ve birleştirme özgürlüğü veriliyor. Ancak karanlık tarafta, etiket ve metrik sistemlerin yüksek heterojenliği bunların kullanımı ve yönetiminde daha fazla zorluğa yol açmaktadır. Çözümümüz, veri işleme hattımıza anlamsal bir katman eklemektir. Anlamsal katman, tüm teknik terimlerin dahili veri kullanıcılarımız için daha anlaşılır kavramlara çevrildiği yerdir. Başka bir deyişle, veri tanımlama ve yönetimi için etiketleri ve metrikleri birinci sınıf vatandaşlara dönüştürüyoruz. Bu neden yardımcı olsun? Veri analistleri için tüm etiketler ve ölçümler semantik katmanda oluşturulacak ve paylaşılacak, böylece daha az karışıklık ve daha yüksek verimlilik sağlanacak. Veri kullanıcıları için artık kendi veri kümelerini oluşturmaları veya her senaryo için hangisinin geçerli olduğunu bulmaları gerekmiyor; yalnızca kendi belirtilmiş etiket kümeleri ve metrik kümeleri üzerinde sorgular yürütebiliyorlar. Anlamsal Katmanı Yükseltme Semantik katmanda etiket ve metriklerin açıkça tanımlanması yeterli değildi. Standartlaştırılmış bir veri işleme sistemi oluşturmak için bir sonraki hedefimiz, tüm veri işleme hattı boyunca etiketlerin ve ölçümlerin tutarlı bir şekilde tanımlanmasını sağlamaktı. Bu amaçla semantik katmanı veri yönetim sistemimizin kalbi haline getirdik: O nasıl çalışır? TDW'deki tüm hesaplama mantıkları anlamsal katmanda tek bir etiket veya metrik şeklinde tanımlanacaktır. Anlamsal katman, uygulama tarafından mantık sorgularını alır, buna göre bir motor seçer ve SQL'i üretir. Daha sonra SQL komutunu yürütülmek üzere TDW'ye gönderir. Bu arada, yapılandırma ve veri alma görevlerini de Doris'e gönderebilir ve hangi metriklerin ve etiketlerin hızlandırılması gerektiğine karar verebilir. Bu sayede etiketleri ve metrikleri daha yönetilebilir hale getirdik. İşin kötü yanı, her etiket ve ölçü ayrı ayrı tanımlandığından, sorgular için geçerli bir SQL ifadesinin oluşturulmasını otomatikleştirmekte zorlanıyor olmamızdır. Bu konuda bir fikriniz varsa bizimle konuşmaktan memnuniyet duyarız. Apache Doris'e Tam Oyun Verin Gördüğünüz gibi Apache Doris çözümümüzde çok önemli bir rol oynadı. Doris kullanımını optimize etmek, genel veri işleme verimliliğimizi büyük ölçüde artırabilir. Bu bölümde Doris ile veri alımını ve sorgulamaları hızlandırmak ve maliyetleri azaltmak için neler yaptığımızı sizlerle paylaşacağız. Ne istiyoruz? Şu anda TDW'deki 80'den fazla kaynak tablodan türetilmiş 800'den fazla etiketimiz ve 1300'den fazla metriğimiz var. TDW'den Doris'e veri aktarırken şunları başarmayı umuyoruz: : Geleneksel T+1 çevrimdışı veri alımına ek olarak, gerçek zamanlı etiketlemeye ihtiyacımız var. Gerçek zamanlı kullanılabilirlik : Her kaynak tablo, kendi ETL görevi aracılığıyla çeşitli adımlarda veri üretir ve etiketlerin ve metriklerin yalnızca bir kısmını içerir, bu nedenle sütunların kısmi güncellemesi için desteğe ihtiyacımız var. Kısmi güncelleme : Grup hedefleme, analiz ve raporlama senaryolarında yalnızca birkaç saniyelik yanıt süresine ihtiyacımız var. Yüksek performans : Maliyetleri mümkün olduğu kadar azaltmayı umuyoruz. Düşük maliyetler Ne Yapıyoruz? TDW Yerine Flink'te Düz Tablolar Oluşturun TDW'de düz tablolar oluşturmanın birkaç dezavantajı vardır: : TDW'nin ayrık 80'den fazla kaynak tablosundan ayrı olarak ekstra bir düz tablo bulundurması gerekir. Bu çok büyük bir işten çıkarma. Yüksek depolama maliyeti : Kaynak tablolarındaki herhangi bir gecikme artacak ve tüm veri bağlantısını geciktirecektir. Düşük gerçek zamanlılık : Gerçek zamanlılığa ulaşmak, ekstra geliştirme çabaları ve kaynakları gerektirir. Yüksek geliştirme maliyeti Aksine Doris'te düz masalar oluşturmak çok daha kolay ve daha ucuzdur. Süreç aşağıdaki gibidir: Yeni verileri Kafka'ya çevrimdışı olarak aktarmak için Spark'ı kullanın. Kafka verilerini tüketmek için Flink'i kullanın. Birincil anahtar kimliği aracılığıyla düz bir tablo oluşturun. Düz tabloyu Doris'e aktarın. Aşağıda görüldüğü gibi Flink, Doris'te "ID"=1 olan beş satırlık veriyi tek satırda toplayarak Doris'in üzerindeki veri yazma baskısını azaltmıştır. TDW'nin artık iki veri kopyası tutması gerekmediğinden ve KafKa'nın yalnızca alım için bekleyen yeni verileri depolaması gerektiğinden bu, depolama maliyetlerini büyük ölçüde azaltabilir. Dahası, Flink'e istediğimiz ETL mantığını ekleyebilir ve birçok geliştirme mantığını çevrimdışı ve gerçek zamanlı veri alımı için yeniden kullanabiliriz. Sütunları Akıllıca Adlandırın Bahsettiğimiz gibi Doris'in Toplama Modeli sütunların kısmi güncellenmesine izin vermektedir. Burada referans olması açısından Doris'teki diğer veri modellerine basit bir giriş sunuyoruz: : Bu, birincil anahtar benzersizliği gerektiren senaryolar için geçerlidir. Yalnızca aynı birincil anahtar kimliğinin en son verilerini tutar. (Bildiğimiz kadarıyla Apache Doris topluluğu, Unique Model'deki sütunların kısmi güncellemesini de dahil etmeyi planlıyor.) Benzersiz Model : Bu model, tüm orijinal verileri herhangi bir ön toplama veya tekilleştirme olmadan tam olarak olduğu gibi saklar. Çoğaltılmış Model Veri modelini belirledikten sonra sütunları nasıl adlandıracağımızı düşünmemiz gerekiyordu. Etiketleri veya metrikleri sütun adları olarak kullanmak bir seçenek değildi çünkü: Ⅰ. Dahili veri kullanıcılarımızın metrikleri veya etiketleri yeniden adlandırması gerekebilir ancak Doris 1.1.3, sütun adlarının değiştirilmesini desteklemez. Ⅱ. Etiketler sık sık çevrimiçi ve çevrimdışı olarak alınabilir. Bu, sütunların eklenmesini ve çıkarılmasını içeriyorsa, bu yalnızca zaman alıcı olmakla kalmayacak, aynı zamanda sorgu performansına da zarar verecektir. Bunun yerine aşağıdakileri yapıyoruz: Etiketlerin ve metriklerin esnek bir şekilde yeniden adlandırılması amacıyla meta verileri (ad, genel benzersiz kimlik, durum vb.) depolamak için MySQL tablolarını kullanırız. İsimlerde yapılacak herhangi bir değişiklik yalnızca meta verilerde gerçekleşecek ancak Doris'teki tablo şemasını etkilemeyecektir. Örneğin bir 4 ID'si verilirse Doris'te a4 sütun adıyla saklanacaktır. Daha sonra bir sorguda yer alıyorsa SQL'de a4'e dönüştürülecektir. song_name song_name Etiketlerin çevrimiçi ve çevrimdışı duruma getirilmesi için, etiketleri ne sıklıkta kullanıldıklarına göre sıralıyoruz. En az kullanılanlara meta verilerinde çevrimdışı işareti verilecektir. Çevrimdışı etiketlerin altına yeni veri yerleştirilmeyecek ancak bu etiketlerin altındaki mevcut veriler mevcut olmaya devam edecek. Yeni eklenen etiketlerin ve metriklerin gerçek zamanlı kullanılabilirliği için, ad kimliklerinin eşleştirilmesine dayalı olarak Doris tablolarında birkaç kimlik sütununu önceden oluşturuyoruz. Bu ayrılmış kimlik sütunları, yeni eklenen etiketlere ve metriklere tahsis edilecektir. Böylece tablo şeması değişikliğinden ve bunun sonucunda ortaya çıkan ek yüklerden kaçınabiliriz. Deneyimlerimiz, etiketler ve metrikler eklendikten yalnızca 10 dakika sonra bunların altındaki verilerin kullanılabildiğini göstermektedir. Dikkat çekici bir şekilde, yakın zamanda piyasaya sürülen Doris 1.2.0, Işık Şeması Değişikliğini desteklemektedir; bu, sütun eklemek veya kaldırmak için yalnızca FE'deki meta verileri değiştirmeniz gerektiği anlamına gelir. Ayrıca tablolar için Işık Şeması Değişikliğini etkinleştirdiğiniz sürece veri tablolarındaki sütunları yeniden adlandırabilirsiniz. Bu bizim için büyük bir dertten kurtarıcıdır. Tarih Yazımını Optimize Edin Günlük çevrimdışı veri alma süremizi %75 oranında azaltan ve CUMU sıkıştırma puanımızı 600+'dan 100'e düşüren birkaç uygulamayı burada bulabilirsiniz. Flink ön toplama: yukarıda bahsedildiği gibi. Yazma grubunun otomatik boyutlandırılması: Flink kaynak kullanımını azaltmak için, bir Kafka Konusundaki verilerin çeşitli Doris tablolarına yazılmasını sağlıyoruz ve veri miktarına göre parti boyutunun otomatik olarak değiştirilmesini gerçekleştiriyoruz. Doris veri yazımının optimizasyonu: Her senaryo için tabletlerin ve kovaların boyutlarının yanı sıra sıkıştırma parametrelerine de ince ayar yapın: max_XXXX_compaction_thread max_cumulative_compaction_num_singleton_deltas BE kesinleştirme mantığının optimizasyonu: BE listelerinin düzenli olarak önbelleğe alınmasını gerçekleştirin, bunları toplu olarak BE düğümlerine aktarın ve daha hassas yük dengeleme ayrıntı düzeyi kullanın. Sorgularda Dori-on-ES'yi kullanın Veri sorgularımızın yaklaşık %60'ı grup hedeflemeyi içerir. Grup hedefleme, bir dizi etiketi filtre olarak kullanarak hedef verilerimizi bulmaktır. Veri işleme mimarimiz için birkaç gereksinim ortaya çıkarır: APP kullanıcılarıyla ilgili grup hedefleme çok karmaşık bir mantık içerebilir. Bu, sistemin yüzlerce etiketi aynı anda filtre olarak desteklemesi gerektiği anlamına gelir. Çoğu grup hedefleme senaryosu yalnızca en son etiket verilerini gerektirir. Ancak metrik sorgularının geçmiş verileri desteklemesi gerekir. Veri kullanıcılarının, grup hedeflemeden sonra metrik verilerinin daha ayrıntılı toplu analizini yapması gerekebilir. Veri kullanıcılarının grup hedefleme sonrasında etiketler ve metrikler hakkında ayrıntılı sorgulamalar yapması da gerekebilir. Değerlendirdikten sonra Doris-on-ES'i benimsemeye karar verdik. Doris, her senaryo için metrik verilerini bir bölüm tablosu olarak sakladığımız yerdir; Elasticsearch ise tüm etiket verilerini depolar. Doris-on-ES çözümü, Doris'in dağıtılmış sorgu planlama yeteneği ile Elasticsearch'ün tam metin arama yeteneğini birleştirir. Sorgu düzeni aşağıdaki gibidir: SELECT tag, agg(metric) FROM Doris WHERE id in (select id from Es where tagFilter) GROUP BY tag Gösterildiği gibi, Elasticsearch'te bulunan ID verileri, metrik analiz için Doris'teki alt sorguda kullanılacaktır. Pratikte sorgu yanıt süresinin hedef grubun büyüklüğüyle ilişkili olduğunu görüyoruz. Hedef grup bir milyondan fazla nesne içeriyorsa sorgu 60 saniye kadar sürecektir. Daha da büyükse zaman aşımı hatası oluşabilir. Araştırmanın ardından en büyük iki zaman kaybımızı belirledik: I. Doris BE, bir milyondan fazla nesneden oluşan bir hedef grup için Elasticsearch'ten veri çektiğinde (varsayılan olarak tek seferde 1024 satır), ağ G/Ç yükü çok büyük olabilir. II. Veri çekimi sonrasında Doris BE'nin SHUFFLE/BROADCAST üzerinden yerel metrik tablolarla Birleştirme işlemlerini gerçekleştirmesi gerekiyor ve bu oldukça maliyetli olabiliyor. Böylece aşağıdaki optimizasyonları yapıyoruz: Optimizasyonun etkinleştirilip etkinleştirilmeyeceğini belirten bir sorgu oturumu değişkeni ekleyin. es_optimize ES'ye veri yazarken, birincil anahtar kimliğinin hashing işleminden sonra paket numarasını depolamak için bir BK sütunu ekleyin. Algoritma, Doris'teki (CRC32) gruplandırma algoritmasıyla aynıdır. Bir Kovaya Birleştirme yürütme planı oluşturmak için Doris BE'yi kullanın, paket numarasını BE ScanNode'a gönderin ve ES'ye gönderin. Sorgulanan verileri sıkıştırmak için ES'yi kullanın; birden fazla veri alımını tek bir veriye dönüştürün ve ağ G/Ç yükünü azaltın. Doris BE'nin yalnızca yerel metrik tablolarla ilgili paket verilerini aldığından ve Doris BE'ler arasında veri karışıklığını önlemek için yerel Birleştirme işlemlerini doğrudan yürüttüğünden emin olun. Sonuç olarak, büyük grup hedefleme için sorgu yanıt süresini 60 saniyeden şaşırtıcı bir şekilde 3,7 saniyeye düşürüyoruz. Topluluk bilgileri, Doris'in yakında piyasaya sürülecek olan 2.0.0 sürümünden bu yana ters çevrilmiş indekslemeyi destekleyeceğini gösteriyor. Bu yeni sürümle, metin türleri üzerinde tam metin araması, metinlerin, sayıların ve tarih saatin eşdeğerliği veya aralık filtrelemesi gerçekleştirebileceğiz ve ters çevrilmiş indeksleme dizi türlerini desteklediğinden, filtrelemede AND, OR, NOT mantığını rahatlıkla birleştirebileceğiz. Doris'in bu yeni özelliğinin aynı görevde Elasticsearch'e göre 3~5 kat daha iyi performans sunması bekleniyor. Veri Yönetimini İyileştirin Doris'in soğuk ve sıcak veri ayırma yeteneği, veri işlemede maliyet azaltma stratejilerimizin temelini oluşturur. Doris'in TTL mekanizmasını esas alarak, Doris'te yalnızca o yılın verilerini saklıyor ve daha düşük depolama maliyeti için daha önceki geçmiş verileri TDW'ye koyuyoruz. Farklı veri bölümleri için kopya sayısını değiştiriyoruz. Örneğin sık kullanılan son üç aya ait veriler için üç kopya, altı aydan eski veriler için bir kopya ve aradaki veriler için iki kopya ayarladık. Doris, sıcak verilerin soğuk verilere dönüştürülmesini desteklemektedir, bu nedenle yalnızca son yedi güne ait verileri SSD'de saklıyoruz ve bundan daha eski verileri daha ucuz depolama için HDD'ye aktarıyoruz. Çözüm Buraya kadar kaydırıp bu uzun okumayı bitirdiğiniz için teşekkür ederiz. ClickHouse'dan Doris'e geçişimiz sırasında sevinçlerimizi, gözyaşlarımızı, öğrendiğimiz dersleri ve sizin için değeri olabilecek birkaç uygulamayı paylaştık. Apache Doris topluluğunun ve SelectDB ekibinin yardımını gerçekten takdir ediyoruz, ancak soğuk ve sıcak verilerin otomatik tanımlanmasını, sık kullanılan etiketlerin/metriklerin önceden hesaplanmasını gerçekleştirmeye çalıştığımız için onları bir süre daha takip ediyor olabiliriz. Materyalleştirilmiş Görünümler kullanılarak kod mantığının basitleştirilmesi vb.
