Meituan Dianping'de Druid SQL ve Güvenlik Uygulaması
Bugünkü paylaşımım dört bölümden oluşuyor. Öncelikle, size Meituan'ın Druid kullanımının mevcut durumunu ve Druid platformunu oluşturma sürecinde karşılaştığımız zorlukları tanıtmama izin verin. İkinci bölümde, Druid SQL'in temel ilkeleri ve kullanımı ile Druid SQL kullanım sürecinde karşılaştığımız sorunlar ve iyileştirmeler tanıtılmaktadır. Üçüncü bölüm, Druid'in veri güvenliğinde sağladığı desteği ve kendi iş ihtiyaçlarımızla birlikte Druid Security alanındaki pratik deneyimimizi tanıtıyor. Son olarak, bugünün paylaşılan içeriğinin bir özeti.
1. Druid'in Meituan'daki mevcut durumu ve zorlukları
1.1 Druid başvurusunun durumu
Meituan, 2016 yılında Druid kullanmaya başladı ve küme sürümü 0.8'den 0.12'ye yükseldi. Çevrimiçi olarak toplam yaklaşık 70 veri düğümüne sahip iki Druid kümesi vardır.
Veri ölçeği açısından, şu anda 100 TB depolamaya sahip 500'den fazla tablo var ve en büyük tablo her gün Kafka'dan on milyarlarca mesaj tüketiyor. Sorgular açısından, günde 17 milyondan fazla sorgu vardır.Bu, risk kontrol senaryolarında düzenli olarak tetiklenen çok boyutlu sorgular gibi programlar tarafından düzenli olarak başlatılan sorguları içerir. Performans açısından, farklı uygulama senaryolarının farklı gereksinimleri olacaktır, ancak genel olarak, TP99'un bir saniye içindeki yanıt süresi, tablonun% 80'ini oluşturmaktadır ve bu, ikinci seviye gerçek zamanlı bir OLAP motoru olan Druid'in konumlandırılmasıyla tutarlıdır.
1.2 Druid platformizasyon zorlukları
Druid'i iş kullanımı için bir hizmet olarak sunma sürecinde, kullanım kolaylığı, güvenlik ve istikrar açısından esas olarak üç zorlukla karşılaştık.
Kullanım kolaylığı: İşletme, Druid'i öğrenme ve kullanma maliyetinin ne kadar yüksek olduğunu ve buna hızlı bir şekilde erişilip erişilemeyeceğini önemseyecektir. Hepinizin bildiği gibi, Druid'in kendisi yalnızca veri yazma ve sorgulama için JSON tabanlı bir API arayüzü sağlar.Arayüzün nasıl kullanılacağını öğrenmeniz ve çeşitli alanların anlamını anlamanız gerekir.Kullanım maliyeti çok yüksektir. Platformlaştırma yoluyla çözmeyi umduğumuz sorun budur.
Güvenlik: Veriler, birçok işletmenin temel varlıklarından biridir ve işletmeler, Druid hizmetlerinin veri güvenliğini garanti edip edemeyeceği konusunda çok endişelidir. Druid'in önceki sürümleri güvenlik için zayıf desteğe sahip, bu nedenle bu kısım da geçen yıl odak noktamızın bir parçasıydı.
Kararlılık: Bir yandan açık kaynak sisteme iniş sürecinde çeşitli kararlılık problemlerinin çözülmesi gerekirken diğer yandan sorgu mantığı kontrol edilemediğinde çok kiracılı bir ortamda sorunların nasıl tespit edilip çözüleceği de çok büyük. meydan okuma.
2. Druid SQL'in uygulanması ve iyileştirilmesi
Druid SQL'in ortaya çıkmasından önce, Druid sorguları JSON tabanlı bir DSL (aşağıda) aracılığıyla ifade ediliyordu. Bu tür bir sorgu dilinin ilk başta öğrenilmesi çok pahalıdır.Kullanıcıların, Druid'in hangi queryType'ları sağladığını, her queryType için hangi parametrelerin geçirilmesi gerektiğini ve uygun bir queryType'ın nasıl seçileceğini bilmeleri gerekir. İkincisi, yüksek kullanım maliyetidir.Uygulamanın JSON istek oluşturma mantığını ve yanıt JSON ayrıştırma mantığını uygulaması gerekir.
Druid SQL ile, yukarıdaki karmaşık JSON'u aşağıdaki standart SQL'e yazabilirsiniz. SQL'in getirdiği kolaylık ortadadır.Bir yandan programcılar ve veri analistleri için ek bir öğrenme maliyeti yoktur, diğer yandan JDBC'ye benzer standart arayüzler kullanılabilir, bu da eşiği büyük ölçüde azaltır.
2.1 Druid SQL'e Giriş
Kısaca Druid SQL'i tanıtmama izin verin.
Öncelikle Druid SQL, 0.10 sürümüne eklenen yeni bir çekirdek modüldür.Druid topluluğu sürekli destek ve optimizasyon sağlar, bu nedenle hem kararlılık hem de bütünlük Druid'e SQL lehçeleri ekleyen diğer projelerden daha iyidir.
Prensip olarak Druid SQL, çeviri katmanını temel olarak SQL'den yerel JSON sorgu diline uygular. Yalnızca bir dil çevirisi katmanı yapıldığından, avantajı, Druid SQL'in kümenin kararlılığı ve performansı üzerinde büyük bir etkiye sahip olmamasıdır. Dezavantajı, yerel JSON'u sorgulama yeteneği ile sınırlı olmasıdır. Druid SQL yalnızca SQL işlevlerinin bir alt kümesini uygular. .
Druid SQL, arama yöntemleri açısından farklı uygulamaların ihtiyaçlarını karşılamak için HTTP ve JDBC'ye iki yöntem sağlar. Son olarak, ifade açısından, Druid SQL, JSON sorgularının uygulayabileceği hemen hemen tüm mantığı ifade edebilir ve otomatik olarak en uygun queryType'ı seçmenize yardımcı olabilir.
Aşağıda üç Druid SQL örneği verilmiştir.
İlk örnek yaklaşık bir TopN sorgusudur. Tek bir boyutun TopN değerini belirli bir göstergeye göre analiz etme ihtiyacı için yerel JSON sorgusu, yaklaşık bir TopN algoritmasının bir uygulamasını sağlar. Druid SQL bu modeli tanıyabilir ve karşılık gelen yaklaşık TopN sorgusunu oluşturabilir.
İkinci örnek, yarı birleştirmedir. Druid'in esnek JOIN'i desteklemediğini biliyoruz, ancak işletme genellikle ilk sorgunun sonucunun ikinci sorgunun filtre koşulu olarak kullanılmasını gerektirir.SQL'de alt sorgu veya yarı birleştirmede bulunur. Druid SQL, bu senaryo için özel destek sağlar.Kullanıcıların uygulama katmanında birden fazla sorgu başlatması gerekmez, yalnızca alt sorgu şeklinde yazılır. Druid SQL ilk olarak alt sorguyu çalıştıracak, sonuçları dış sorgu filtre koşullarında gerçekleştirecek ve ardından dış sorguyu yürütecektir.
Sonuncusu, iç içe geçmiş bir GroupBy örneğidir. Druid SQL, bu çok katmanlı GroupBy yapısını tanıyabilir ve karşılık gelen yerel iç içe geçmiş GroupBy JSON'u oluşturabilir.
2.2 Druid SQL mimarisi
Aşağıda Druid SQL'in genel mimarisi açıklanmaktadır.
Druid SQL, esas olarak iki modül içeren sorgu aracı düğümünde uygulanan bir işlevdir: Sunucu ve SQL Katmanı.
Sunucu modülü, HTTP ve JDBC dahil olmak üzere isteklerin alınmasından ve ayrıştırılmasından sorumludur. Sıradan HTTP istekleri için karşılık gelen REST Uç Noktasını eklemeniz yeterlidir. JDBC için Druid, Avatica projesinin JDBC Sürücüsü ve RPC tanımlarını yeniden kullanıyor, bu nedenle yalnızca Avatica'nın SPI'sini uygulaması gerekiyor. Avatica'nın RPC'si de HTTP tabanlı olduğundan, her ikisi de aynı Jetty Sunucusunu kullanabilir.
SQL Katmanı, SQL'i Calcite projesine dayanan yerel JSON sorgularına çevirmekten sorumludur. Kalsit, standart SQL'i özel yürütme planlarına ayrıştırabilen, analiz edebilen ve optimize edebilen genel bir SQL optimizer çerçevesidir ve büyük veri alanında yaygın olarak kullanılır. Resimdeki açık yeşil bileşenler Calcite tarafından sağlanmıştır ve açık mavi bileşenler Druid tarafından uygulanmıştır Üç ana bileşen vardır.
İlk olarak, DruidSchema bileşeni Calcite'a, kümeye hangi tabloların dahil edildiği ve her tablodaki alanların adları ve türleri gibi sorgu ayrıştırma ve doğrulama için gereken meta verileri sağlar. RulesSet bileşeni, optimize edici tarafından kullanılan dönüştürme kurallarını tanımlar. Druid SQL yalnızca dil çevirisi yaptığından, bazı mantıksal optimizasyon kuralları (projeksiyon eliminasyonu, sabit katlama vb.) Vardır ve fiziksel optimizasyon dahil değildir. RulesSet aracılığıyla, Calcite mantıksal planı bir DruidRel düğümüne dönüştürür ve DruidRel tüm sorgu bilgilerini içerir. Son olarak, QueryMaker bileşeni, DruidRel'i bir veya daha fazla yerel JSON sorgusuna dönüştürmeye çalışacak ve bunlar sonunda yürütme için Druid'in QueryExecution modülüne gönderilecektir.
2.3 API seçimi: HTTP veya JDBC
Druid SQL iki arayüz sağlar: HTTP ve JDBC, hangisini kullanmalıyım? Deneyimlerimiz, HTTP'nin tüm programlama dilleri için geçerli olmasıdır, Broker durumsuzdur ve işletim ve bakım nispeten basittir; dezavantaj, istemcinin görece daha fazla işlem mantığına sahip olmasıdır. JDBC, Java uygulamaları için daha dostudur, ancak Broker'ın karmaşık dengeleme yaparken özel dikkat gerektiren durum bilgisi olan bir düğüm olmasına neden olacaktır. Ek olarak, JDBC'de çözülmemiş bazı hatalar vardır.JDBC arayüzünü kullanıyorsanız, daha fazla dikkat etmeniz gerekir.
2.4 İyileştirme
İşte Druid SQL'de yaptığımız bazı iyileştirmeler.
İlk iyileştirme, Şema türetmenin performans optimizasyonu ile ilgilidir. Druid'in şemasız bir sistem olduğunu biliyoruz, tüm verilerin aynı şemaya sahip olmasını gerektirmiyor Druid tablolarının şeması nasıl tanımlanır? Topluluğun uygulaması şudur: Önce SegmentMetadataQuery aracılığıyla her bir segmentin şemasını hesaplayın, ardından tablonun segmentini elde etmek için segment şemasını birleştirin ve son olarak segment değiştiğinde tüm tablonun şemasını yeniden hesaplayın.
Topluluğun gerçekleşmesi senaryomuzda üç sorunla karşılaştı. Birincisi, Broker başlangıç süresinin çok uzun olmasıdır. Kümemizin 600.000 segmenti var ve test, bu segmentlerin şemasını hesaplamanın yarım saat sürdüğünü buldu. Bu, Broker'ın başladıktan sonra hizmetleri sağlamak için yarım saat beklemesine neden olacaktır. İkinci sorun, Broker'ın tüm Segmentlerin meta verilerini bellekte önbelleğe alması gerektiğidir, bu da yerleşik bellekte bir artışa yol açar.Ayrıca, şema yenileme, çok fazla GC baskısı getirecektir. Üçüncü sorun, topluluk planı tarafından gönderilen meta veri sorgusunun büyüklüğünün Aracı ve Segment sayısının ürünüyle orantılı olması, dolayısıyla ölçeklenebilirliğin iyi olmamasıdır.
Bu soruna yanıt olarak, iş gereksinimlerini ve kullanımı analiz ettikten sonra şunu bulduk: Birincisi, şema değişikliği nispeten düşük frekanslı bir işlemdir, yani segmentin şemasının çoğu aynıdır ve hesaplamaları tekrarlamaya gerek yoktur. Ek olarak, çoğu durumda, işletmelerin sorgulamak için yalnızca en son şemayı kullanması gerekir. Bu nedenle, çözümümüz şemayı türetmek için tüm segmentler yerine yalnızca en son zaman aralığını kullanmaktır. Dönüşümden sonra, komisyoncunun şemayı hesaplama süresi yarım saatten 20 saniyeye düşürüldü ve GC basıncı da önemli ölçüde azaldı.
İkinci optimizasyon, günlük kaydı ve izleme ile ilgilidir. Talep günlükleri ve izleme göstergeleri, işletim ve bakım sürecinde büyük ölçüde güvendiğimiz iki araçtır. Örneğin, yavaş sorguların konumlandırılması, SLA göstergelerinin hesaplanması ve trafik oynatma testlerinin tümü günlüklere ve izlemeye dayanır. Ancak, SQL'in 0.12 sürümünde ne istek günlükleri ne de izleme göstergeleri vardır.Bu, çevrimiçi olmadan önce çözülmesi gereken bir sorundur. Hedeflerimiz iki yönlüdür: İlk olarak, istek süresi, kullanıcı, SQL içeriği, zaman alıcı vb. Gibi tüm SQL isteklerinin temel bilgilerini kaydedebiliriz; ikincisi, SQL isteklerini yerel JSON sorguları ile ilişkilendirebiliriz. Yürütme seviyesi göstergelerinin tümü JSON sorgu granülerliği olduğundan, JSON sorgusuna karşılık gelen orijinal SQL sorgusunu bulmamız gerekir.
Çözümümüz 0.14 sürümüyle birleştirildi. İlk olarak, her SQL isteğine benzersiz bir sqlQueryId atayacağız. Daha sonra RequestLogger arayüzünü genişlettik ve SQL günlüklerinin çıktısını almak için bir yöntem ekledik. Aşağıdaki şekil bir örnektir: Her SQL isteği için, SQL içeriğinin çıktısının yanı sıra, istemci günlüğü ile ilişkilendirmek için kullanılabilecek sqlQueryId de çıktı olarak alınacaktır. Ayrıca, JSON sorgularıyla korelasyon analizi için kullanılabilen, SQL'e karşılık gelen her JSON sorgusunun queryId'sini çıkarır.
Üçüncü iyileştirme nispeten küçük olmasına rağmen, hizmetin istikrarı için çok önemlidir. JSON sorgularının, kullanıcıların sorgunun zaman aralığını belirtmelerini gerektirdiğini biliyoruz ve Druid, performansı artırmak için çok önemli olan bölüm kesme yapmak için bu aralığı kullanacak. Ancak Druid SQL'de bu sınırlama yoktur. Kullanıcılar genellikle SQL yazarken zaman aralığını sınırlamayı unuturlar, bu da tam bir tablo taramasına yol açar ve çok fazla küme kaynağı tüketir, bu da büyük bir risktir. Bu nedenle, nerede koşulu için bir kontrol ekledik.Kullanıcı, zaman damgası alanı için bir filtre koşulu belirtmezse, sorgu doğrudan bir hata bildirecektir.
3. Druid Güvenliği ile ilgili pratik deneyim
Öncelikle veri güvenliğinde karşılaştığımız sorunları tanıtın. O sırada 0.10 sürümü kullanıldı. Bu sürüm veri güvenliğini desteklemiyor. Tüm API'lerin erişim kontrolü yok. Herkes tüm verilere erişebilir ve hatta silebilir. Bu, işletme verileri güvenliği için çok büyük bir sorundur. Gizli tehlikeler.
Beş hedefe ulaşmayı umuyoruz: tüm API'ler doğrulanır, DB ayrıntı düzeyi kontrol edilir, tüm veri erişimi için denetim günlükleri kullanılabilir, işletmeler sorunsuz bir şekilde güvenli bir kümeye yükseltilebilir ve kod değişiklikleri daha az müdahaleci olur.
Bu hedeflere ulaşmak için önce Druid'in sonraki sürümlerde eklediği güvenlik özelliklerini araştırdık.
3.1 Druid Security işlevi ve prensibi
Sürüm 0.11, istemci ile küme arasında ve kümenin düğümleri arasında aktarım katmanı güvenliğini gerçekleştirebilen uçtan uca aktarım katmanı şifrelemesini (TLS) destekler. Sürüm 0.12, genişletilebilir bir kimlik doğrulama ve kimlik doğrulama çerçevesi sunmuştur ve bu çerçeveye dayalı olarak, BA ve Kerberos gibi kimlik doğrulama yöntemlerinin yanı sıra rol tabanlı bir kimlik doğrulama modülü sağlar.
Aşağıdaki şekil, kimlik doğrulama çerçevesinin ilkesini ve yapılandırmasını açıklamaktadır.
3.2 Druid Security Community Solution'ın dezavantajları
Topluluk programı ihtiyaçlarımızın çoğunu karşılayabilir, ancak yine de bazı sorunlar var.
İlk sorun, tarayıcının BA sertifikası için zayıf desteğine sahip olduğunu bulmamızdır. Bu nedenle, Web konsolu için birleşik bir SSO sertifikası almayı umuyoruz.
İkinci sorun ise işletmenin sorunsuz bir şekilde güvenli bir kümeye geçişini desteklemek için lansmanın ilk aşamasında sertifikasız isteklerle uyumlu olması gerektiğidir.O zamanlar kullandığımız 0.12 sürümünde bu fonksiyon yoktu.
Üçüncü sorun, topluluğun rol tabanlı kimlik doğrulama modülünün yalnızca temeldeki yönetim API'sini sağlamasıdır; bu, kullanıcıların bu API'leri doğrudan kullanması için çok zahmetlidir.
Son sorun, topluluğun henüz denetim günlüklerini desteklememesidir.
Bu sorunlara yanıt olarak üç büyük iyileştirme yaptık.
3.3 İyileştirme
İyileştirme 1: DB tabanlı erişim kontrolü
Her şeyden önce, izinlerin yönetimini basitleştirmek için, DB kavramını tanıttık ve DB granüler erişim kontrolü uyguladık. İşletme, DB'deki tablolara DB'nin okuma-yazma hesabı aracılığıyla erişir.
İyileştirme 2: Otomatik yönetim yetkisi DB
Görev erişim platformu aracılığıyla DB ve DataSource arasındaki eşleme ilişkisini koruyun ve DB ve DataSource değiştiğinde yetki DB'sini güncellemek için kimlik doğrulama modülü arabirimini çağırın.
İyileştirme 3: SSO sertifikalı ve sertifikasız erişimi destekleyin
Kimlik doğrulama zincirini özelleştirin, Web konsolunun SSO kimlik doğrulamasını SSO kimlik doğrulama filtresi aracılığıyla gerçekleştirin ve kimliği doğrulanmamış isteklerle uyumlu olması için güvenli olmayan erişim filtresini geçirin.
Önlemler
- Temel güvenlik işlevini etkinleştirin, allowAll kullanın
- Yetki DB'sini başlatın, anonim kullanıcı oluşturun ve yetkilendirin
- AllowAll'ı anonim olarak değiştirin
- Anonim kullanıcıların izinlerini kademeli olarak kurtarın
Dört, özet
4.1 SQL hakkında
- Sorgu performansı ve kararlılığı üzerinde çok fazla etkisi yoktur
- Druid'in kendi sorgu işleme yetenekleri ve desteklenen sınırlı SQL işlevleri ile sınırlıdır
- Büyük kümelerin şema türetme verimliliği
- Broker, hizmetleri sağlamadan önce şema başlatmayı beklemelidir (# 6742)
4.2 Güvenlik Hakkında
- Taşıma katmanı şifrelemesi
- Kimlik doğrulama çerçevesi
- BA ve Kerberos kimlik doğrulaması
- RBAC kimlik doğrulaması
yazar hakkında:
Apache Kylin PMC üyesi, Druid Commiter, açık kaynak ve veritabanı teknolojisi meraklısı Gao Dayue, SQL motoru ve büyük veri sistemi geliştirme konusunda uzun yıllara dayanan deneyime sahiptir. Şu anda Meituan Dianping'de OLAP motor çekirdeği geliştirme, platform yapımı ve iş inişinden sorumludur.
Bu makale Gao Dayue'nun DataFun tarafından düzenlenen DataFun topluluğundaki konuşmasından gelmektedir.
