Azure HDInsight 3.6 Hive iş yüklerini HDInsight 4.0'a geçirme
HDInsight 4.0, HDInsight 3.6'ya göre çeşitli avantajlara sahiptir. HdInsight 4.0'daki yeniliklere genel bir bakış aşağıdadır.
Bu makale, Hive iş yüklerini HDInsight 3.6'dan 4.0'a geçirme adımlarını kapsar.
- Hive meta veri deposu kopyalama ve şema yükseltme
- ACID uyumluluğu için güvenli geçiş
- Hive güvenlik ilkelerini koruma
Yeni ve eski HDInsight kümelerinin aynı Depolama Hesaplarına erişimi olmalıdır.
Hive tablolarının yeni bir Depolama Hesabına geçirilmesi ayrı bir adım olarak yapılmalıdır. Bkz. Depolama Hesapları arasında Hive Geçişi.
Hive 3'teki değişiklikler ve yenilikler:
Hive istemci değişiklikleri
Hive 3, komut satırından sorguları çalıştırmak için yalnızca ince istemci, Beeline ve Hive yönetim komutlarını destekler. Beeline, tüm komutları yürütmek için HiveServer'a bir JDBC bağlantısı kullanır. Ayrıştırma, derleme ve yürütme işlemleri HiveServer'da gerçekleşir.
Hive kullanıcı olarak Hive anahtar sözcüğünü kullanarak Beeline'ı çağırarak veya kullanarak beeline -u <JDBC URL>
bir beeline çağırarak desteklenen Hive CLI komutlarını girersiniz. JDBC URL'sini Ambari Hive sayfasından alabilirsiniz.
Beeline kullanın (artık desteklenmeyen kalın istemci Hive CLI yerine) aşağıdakiler gibi çeşitli avantajlara sahiptir:
- Hive kod tabanının tamamını korumak yerine yalnızca JDBC istemcisini koruyabilirsiniz.
- Hive kod tabanının tamamı dahil olmadığından Beeline kullanıldığında başlangıç yükü daha düşüktür.
JDBC URL'sini kullanarak bir betik bağlantısı çağıran "/usr/bin" dizininin altındaki Hive betiğini de yürütebilirsiniz.
İnce istemci mimarisi,
- Oturum durumu, iç veri yapıları, parolalar vb. sunucu yerine istemcide bulunur.
- Sorguları yürütmek için gereken az sayıda daemon, izlemeyi ve hata ayıklamayı kolaylaştırır.
HiveServer, komutları kullanarak SET
değiştirebileceğiniz izin verilenler listesi ve blok listesi ayarlarını zorunlu kılabilir. Blok listelerini kullanarak, Hive Server kararlılığını önlemek için bellek yapılandırmasını kısıtlayabilirsiniz. Farklı kararlılık düzeyleri oluşturmak için farklı izin verilenler listesine ve blok listesine sahip birden çok HiveServer örneği yapılandırabilirsiniz.
Hive Meta Veri Deposu değişiklikleri
Hive artık katıştırılmış meta veri deposu (HS2 JVM içinde) yerine yalnızca uzak meta veri depolarını destekliyor. Hive meta veri deposu, HDInsight yığınının bir parçası olarak Ambari tarafından yönetilen bir kümedeki bir düğümde bulunur. Küme dışındaki tek başına bir sunucu desteklenmez. Hive Meta Veri Deposunu yapılandırmak için artık komut satırında key=value komutlarını ayarlamazsınız. "hive.metastore.uris=' ' " " HMS hizmeti kullanıldı ve bağlantı kuruldu.
Yürütme altyapısı değişikliği
Apache Tez, varsayılan Hive yürütme altyapısı olarak MapReduce'un yerini alır. Hive 2.0'dan itibaren MapReduce kullanım dışı bırakıldı Hive-12300'e başvurun. Yönlendirilmiş ansiklik grafiklerin (DAG' ler) ifadeleri ve veri aktarımı temel öğeleriyle, Tez altında Hive sorgularının yürütülmesi performansı artırır. Hive'a gönderdiğiniz SQL sorguları aşağıdaki gibi yürütülür
- Hive sorguyu derler.
- Tez sorguyu yürütür.
- YARN, küme genelindeki uygulamalar için kaynaklar ayırır ve YARN kuyruklarında Hive işleri için yetkilendirmeyi etkinleştirir.
- Hive, ABFS veya WASB'deki verileri güncelleştirir.
- Hive, bir JDBC bağlantısı üzerinden sorgu sonuçlarını döndürür.
Eski bir betik veya uygulama yürütme için MapReduce belirtiyorsa, aşağıdaki gibi bir özel durum oluşur
Not
Kullanıcı tanımlı işlevlerin çoğu (UDF) MapReduce yerine Tez üzerinde yürütülecek bir değişiklik gerektirmez.
ACID işlemi ve CBO ile ilgili değişiklikler:
ACID tabloları, HDInsight 4.x'te performans veya işletimsel aşırı yükleme olmadan varsayılan tablo türüdür.
Basitleştirilmiş uygulama geliştirme, daha güçlü işlem garantilerine sahip işlemler ve SQL komutları için daha basit semantikler
Hive iç, HDInsight 4.1'de ACID tabloları için demetleme işlemini üstlenir ve bakım yükünü ortadan kaldırır.
Gelişmiş iyileştirmeler – CBO'da yükseltme
Otomatik Sorgu önbelleği. Sorgu önbelleğe almayı etkinleştirmek için kullanılan Özellik şeklindedir
hive.query.results.cache.enabled
. Bu özelliği true olarak ayarlamanız gerekir. Hive, sorgu sonuç önbelleğini varsayılan olarak, Hive sorgu sonucu önbelleği/tmp/hive/__resultcache__/.
için 2 GB ayırır. Aşağıdaki parametreyi baythive.query.results.cache.max.size
cinsinden yapılandırarak bu ayarı değiştirebilirsiniz.Daha fazla bilgi için Azure HDInsight 4.0'a geçişin avantajları.
Gerçekleştirilmiş görünüm yeniden yazmaları
Daha fazla bilgi için Hive - Gerçekleştirilmiş Görünümler
Apache Hive 3'e yükselttikten sonra yapılan değişiklikler
Yükseltmeden sonra Apache Hive 3 tablolarınızı bulmak ve kullanmak için yükseltme işlemi sırasında gerçekleşen değişiklikleri anlamanız gerekir. Tabloların yönetiminde ve konumunda yapılan değişiklikler, tablo dizinlerine yönelik izinler, tablo türleri ve ACID uyumluluğuyla ilgili sorunlar.
Tabloların Hive Yönetimi
Hive 3, Hive 2'den daha fazla tablo denetimine sahip olur ve yönetilen tabloların katı bir tanıma uymasını gerektirir. Hive'ın tabloları devralma denetimi düzeyi, geleneksel veritabanları için homojendir. Hive, verilerde yapılan değişiklik değişikliklerini kendi kendine algılar; bu denetim çerçevesi performansı artırır.
Örneğin, Hive bir sorguyu çözümlemenin yeni veriler için tablo tarama gerektirmediğini biliyorsa Hive, hive sorgu sonuç önbelleğinden sonuçlar döndürür. Gerçekleştirilmiş görünümdeki temel veriler değiştiğinde Hive'ın gerçekleştirilmiş görünümü yeniden oluşturması gerekir. ACID özellikleri tam olarak hangi satırların değiştiğini ve işlenmesi ve gerçekleştirilmiş görünüme eklenmesi gerektiğini gösterir.
Hive, ACID özelliklerine değişir
Hive 2.x ve 3.x'in hem işlemsel (yönetilen) hem de işlem dışı (dış) tabloları vardır. İşlem tabloları atomik, tutarlı, yalıtım ve dayanıklı (ACID) özelliklere sahiptir. Hive 2.x'te ACID işlem işleminin ilk sürümü ACID v1'dir. Hive 3.x'te varsayılan tablolar ACID v2 ile olacaktır.
Yerel ve yerel olmayan depolama biçimleri
Depolama biçimleri, tablo türlerine yapılan yükseltme değişikliklerinde bir faktördür. Hive 2.x ve 3.x, aşağıdaki Hadoop yerel ve yerel olmayan depolama biçimlerini destekler
Yerel: Hive'da aşağıdaki dosya biçimlerinde yerleşik desteğe sahip tablolar
- Metin
- Sıralı Dosya
- RC Dosyası
- AVRO Dosyası
- ORC Dosyası
- Parquet Dosyası
Yerel olmayan: DruidStorageHandler veya HBaseStorageHandler gibi bir depolama işleyicisi kullanan tablolar
HDInsight 4.x yükseltme değişiklikleri tablo türlerine
Aşağıdaki tablo, HDInsight 3.x'ten yükseltmeden önce ve HDInsight 4.x'e yükseltmeden sonra Hive tablo türlerini ve ACID işlemlerini karşılaştırır. Hive tablo dosyasının sahipliği, yükseltmeden sonra tablo türlerini ve ACID işlemlerini belirlemede bir faktördür
HDInsight 3.x ve HDInsight 4.x Tablo türü karşılaştırması
HDInsight 3.x | - | - | - | HDInsight 4.x | - |
---|---|---|---|---|---|
Tablo Türü | ACID v1 | Biçim | Hive Tablo Dosyasının Sahibi (kullanıcı) | Tablo Türü | ACID v2 |
Harici | Hayır | Yerel veya yerel olmayan | Hive veya Hive olmayan | Harici | Hayır |
Yönetilen | Yes | ORC | Hive veya Hive olmayan | Yönetilen, güncelleştirilebilir | Yes |
Yönetilen | Hayır | ORC | Hive | Yönetilen, güncelleştirilebilir | Yes |
Yönetilen | Hayır | ORC | Hive olmayan | Dış, veri silme ile | HAYIR |
Yönetilen | Hayır | Yerel (ANCAK ORC olmayan) | Hive | Yönetilen, yalnızca ekle | Yes |
Yönetilen | Hayır | Yerel (ANCAK ORC olmayan) | Hive olmayan | Dış, veri silme ile | Hayır |
Yönetilen | Hayır | Yerel olmayan | Hive veya Hive olmayan | Dış, veri silme ile | Hayır |
Hive Kimliğe Bürünme
Hive kimliğe bürünme özelliği Hive 2'de (doAs=true) varsayılan olarak etkinleştirildi ve Hive 3'te varsayılan olarak devre dışı bırakıldı. Hive kimliğe bürünme, Hive'ı son kullanıcı olarak çalıştırır veya çalıştırmaz.
Diğer HDInsight 4.x yükseltme değişiklikleri
- Yönetilen, Hive kullanıcısının sahip olmadığı ACID tabloları yükseltmeden sonra yönetilen tablolar olarak kalır, ancak Hive sahip olur.
- Yükseltmeden sonra, Hive tablosunun biçimi yükseltmeden öncekiyle aynıdır. Örneğin, yerel veya yerel olmayan tablolar sırasıyla yerel veya yerel olmayan olarak kalır.
Konum Değişiklikleri
Yükseltmeden sonra, yönetilen tabloların veya bölümlerin konumu aşağıdaki koşullardan herhangi biri altında değişmez:
- Eski tablo veya bölüm dizini, yükseltmeden önce varsayılan konumunda /apps/hive/warehouse değildi.
- Eski tablo veya bölüm, yeni ambar dizininden farklı bir dosya sistemindedir.
- Eski tablo veya bölüm dizini, yeni ambar dizininden farklı bir şifreleme bölgesindedir.
Aksi takdirde, yönetilen tabloların veya bölümlerin konumu değişir. Yükseltme işlemi yönetilen dosyaları öğesine /hive/warehouse/managed
taşır. Varsayılan olarak Hive, HDInsight 4.x'te oluşturduğunuz tüm yeni dış tabloları /hive/warehouse/external
/apps/hive directory
Hive 2.x ambarının eski konumu olan , HDInsight 4.x'te var olabilir veya olmayabilir
Konum değişiklikleri için aşağıdaki Senaryolar mevcuttur
1\. Senaryo
Tablo HDInsight-3.x'te yönetilen bir tabloysa ve konumda /apps/hive/warehouse
bulunuyorsa ve HDInsight-4.x'te dış tablo olarak dönüştürülüyorsa, HDInsight 4.x'te de konum aynıdır /apps/hive/warehouse
. Hiçbir konumu değiştirmez. Bu adımdan sonra, aynı konumda /apps/hive/warehouse
mevcut olan yönetilen (acid) tablosu olarak dönüştürmek için alter table komutunu gerçekleştiriyorsanız.
2\. Senaryo
Tablo HDInsight-3.x içinde yönetilen bir tabloysa ve konumda /apps/hive/warehouse
bulunuyorsa ve HDInsight 4.x'te yönetilen (ACID) tablosuna dönüştürüldüyse, konum olur /hive/warehouse/managed
.
Senaryo 3 Dış tablo oluşturuyorsanız, HDInsight-4.x'te herhangi bir konum belirtmeden konumunda /hive/warehouse/external
gösterilir.
Tablo dönüştürme
Yükseltmeden sonra, işlem dışı bir tabloyu ACID v2 işlem tablosuna dönüştürmek için komutunu kullanır ALTER TABLE
ve tablo özelliklerini olarak ayarlarsınız
transaction'='true' and 'EXTERNAL'='false
- YÖNETILEN tablo, ACID olmayan, ORC biçimi ve HDInsight-3.x'te Hive olmayan kullanıcının sahip olduğu tablo, HDInsight-4.x'te dış, ACID olmayan tabloya dönüştürülür.
- Kullanıcı dış tabloyu (ACID olmayan) ACID olarak değiştirmek isterse, dış tabloyu da yönetilen ve ACID olarak değiştirmelidir. HDInsight-4.x'te tüm yönetilen tablolar varsayılan olarak kesinlikle ACID olduğundan. Dış tabloları (ACID olmayan) ACID tablosuna dönüştüremezsiniz.
Not
Tablo bir ORC tablosu olmalıdır.
Dış tabloyu (ACID olmayan) Yönetilen (ACID) tablosuna dönüştürmek için,
- Aşağıdaki komutu kullanarak dış tabloyu yönetilen tabloya dönüştürün ve acid eşittir true:
alter table <table name> set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');
- Dış tablo için aşağıdaki komutu yürütmeye çalışırsanız aşağıdaki hatayı alırsınız.
1\. Senaryo
Tablo dış tablodur rt
(ACID olmayan). Tablo ORC olmayan bir tabloysa,
alter table rt set TBLPROPERTIES ('transactional'='true');
ERROR : FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. The table must be stored using an ACID compliant format (such as ORC): work.rt
The table must be ORC format
2\. Senaryo
>>>> alter table rt set TBLPROPERTIES ('transactional'='true'); If the table is ORC table.
ERROR:
Error: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. work.rt can't be declared transactional because it's an external table (state=08S01,code=1)
Tablo dış tablo olduğundan ve dış tabloyu rt
ACID'e dönüştüremediğiniz için bu hata oluşuyor.
3\. Senaryo
>>>> alter table rt set TBLPROPERTIES ('EXTERNAL'='false');
ERROR:
Error: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. Table work.rt failed strict managed table checks due to the following reason: Table is marked as a managed table but isn't transactional. (state=08S01,code=1)
Burada önce dış tabloyu yönetilen tablo olarak değiştirmeye çalışıyoruz. HDInsight 4.x'te kesinlikle yönetilen bir tablo olmalıdır (yani ACID olmalıdır). İşte, kilitlenme var. Dış tabloyu (NON_ACID) yönetilen (ACID) olarak dönüştürmenin tek yolu şu komutu izlemeniz gerekir:
alter table rt set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');
Söz dizimi ve semantik
Tablo oluşturma Kullanılabilirliği ve işlevselliği geliştirmek için Hive 3 tablo oluşturmayı değiştirdi. Hive tablo oluşturmayı aşağıdaki yollarla değiştirdi
- HDP'de varsayılan olan ACID uyumlu tablo oluşturur
- Basit yazma ve eklemeleri destekler
- Birden çok bölüme yazar
- Tek bir SELECT deyimine birden çok veri güncelleştirmesi ekler
- Demetleme gereksinimini ortadan kaldırır.
Hive'da tablolar oluşturan bir ETL işlem hattınız varsa, tablolar ACID olarak oluşturulur. Hive artık erişimi sıkı bir şekilde denetler ve tablolarda düzenli aralıklarla sıkıştırma gerçekleştirir
HDInsight 3.x'te Yükseltmeden önce CREATE TABLE varsayılan olarak ACID olmayan bir tablo oluşturmuştur.
Yükseltmeden Sonra Varsayılan olarak CREATE TABLE ORC biçiminde tam bir ACID işlem tablosu oluşturur.
Eylem Gerekli Spark'tan Hive ACID tablolarına erişmek için Hive Ambar Bağlayıcısı'nı (HWC) kullanarak Hive'a bağlanırsınız. Spark'tan Hive'a ACID tabloları yazmak için HWC ve HWC API'sini kullanırsınız
db.table
Kaçış BaşvurularıHive'ın db.table dizesinin tamamını tablo adı olarak yorumlamasını önlemek için db.table başvurularını kullanan sorguları değiştirmeniz gerekir. Hive 3.x, SQL sorgularında reddeder
db.table
. Tablo adlarında nokta (.) kullanılmasına izin verilmez. Veritabanı adını ve tablo adını backticks içine alırsınız. Sorunlu tablo başvurusuna sahip bir tablo bulun.math.students
create TABLE deyiminde görünür. Veritabanı adını ve tablo adını backticks içine alın.TABLE `math`.`students` (name VARCHAR(64), age INT, gpa DECIMAL(3,2));
CASTING TIMESTAMPS Sayısalları zaman damgalarına dönüştüren uygulamaların sonuçları Hive 2'den Hive 3'e farklılık gösterir. Apache Hive, BIR saat dilimini TIMESTAMP türüyle ilişkilendirmeyen SQL Standard'a uymak için CAST davranışını değiştirdi.
Yükseltmeden önce, kümenin saat dilimini yansıtan bir sonuç üretmek için bir sayısal tür değerini zaman damgasına dönüştürme kullanılabilir. Örneğin, 1597217764557 2020-08-12 00:36:04 PDT'dir. Aşağıdaki sorgunun çalıştırılması, sayısal değeri PDT'deki bir zaman damgasına döndürür:
SELECT CAST(1597217764557 AS TIMESTAMP);
| 2020-08-12 00:36:04 |Yükseltmeden sonra bir sayısal tür değerini zaman damgasına dönüştürme, kümenin saat dilimi yerine UTC değerini yansıtan bir sonuç üretir. Sorgunun çalıştırılması, sayısal değeri UTC'de bir zaman damgasına döndürür.
SELECT CAST(1597217764557 AS TIMESTAMP);
| 2020-08-12 07:36:04.557 |Eylem Gerekli Uygulamaları değiştirme. Yerel bir saat dilimi elde etmek için bir rakamdan atama yapmayın. From_utc_timestamp ve to_utc_timestamp yerleşik işlevler, yükseltmeden önceki davranışı taklit etmek için kullanılabilir.
SÜTUN DEĞİşİkLİkLerİN UYUMLULUĞUNU DENETLEME Varsayılan yapılandırma değişikliği, sütun türlerini değiştiren uygulamaların başarısız olmasına neden olabilir.
HDInsight'ta Yükseltmeden önce 3.x Hive.metastore.disallow.incompatible.col.type.changes varsayılan olarak yanlıştır ve uyumsuz sütun türlerinde değişikliklere izin verir. Örneğin, STRING sütununu MAP<STRING, STRING> gibi uyumsuz türde bir sütunla değiştirebilirsiniz. Hata oluşmaz.
Yükseltmeden Sonra Hive.metastore.disallow.incompatible.col.type.changes varsayılan olarak doğrudur. Hive, uyumsuz sütun türlerinde değişiklik yapılmasını engeller. INT, STRING, BIGINT gibi uyumlu sütun türü değişiklikleri engellenmez.
Eylem Gerekli Olası veri bozulmalarını önlemek için uygulamaları uyumsuz sütun türü değişikliklerine izin vermek için değiştirin.
BÖLÜMLERI BıRAKMA
Bölümleri bırakmaya yönelik CASCADE yan tümcesindeki OFFLINE ve NO_DROP anahtar sözcükleri performans sorunlarına neden olur ve artık desteklenmez.
Yükseltmeden önce, bölümlerin okunmasını veya bırakılmasını önlemek için CASCADE yan tümcesinde ÇEVRİmDIŞI ve NO_DROP anahtar sözcükleri kullanabilirsiniz.
YÜKSELTMEDEN SONRA ÇEVRİmDIŞI ve NO_DROP CASCADE yan tümcesinde desteklenmez.
Eylem Gerekli CASCADE yan tümcesinden OFFLINE ve NO_DROP kaldırmak için uygulamaları değiştirin. Bölümlerin bırakılması veya okunmasını önlemek için Ranger gibi bir yetkilendirme düzeni kullanın.
TABLO YENIDEN ADLANDıRıLıYOR Yükseltmeden sonra yönetilen tabloyu yeniden adlandırma, yalnızca tablo yan
LOCATION
tümcesi olmadan oluşturulduysa ve veritabanı dizini altındaysa konumunu taşır.
CBO ile ilgili sınırlamalar
Seçme çıkışının birkaç sütunda sondaki sıfırları verdiğini görüyoruz. Örneğin, ondalık (38,4) olarak veri türüne sahip bir tablo sütunumuz varsa ve verileri 38 olarak eklersek, sondaki sıfırları ekler ve sonuç olarak ve https://issues.apache.org/jira/browse/HIVE-24389başına https://issues.apache.org/jira/browse/HIVE-12063 38.0000 sonucunu verir. Fikir, ondalık sütunlarda sarmalayıcı çalıştırmak yerine ölçek ve duyarlık olarak korunur. Hive 2'deki varsayılan davranış budur. Bu sorunu çözmek için aşağıdaki seçeneği izleyebilirsiniz.
- Duyarlılığı sütun1 (ondalık(38,0)) olarak ayarlamak için kaynak düzeyinde veri türünü değiştirin. Bu değer, sonunda sıfır olmadan sonucu 38 olarak sağlar. Ancak verileri 35.0005 olarak eklerseniz 0,0005 olur ve yalnızca 38 1 değerini sağlar. Sorunu olan sütunlar için sondaki sıfırları kaldırın ve dizeye yayınlayın,
- TRIM(cast(<column_name> AS STRING))+0 FROM <table_name>;
- Regex kullanın.
- Duyarlılığı sütun1 (ondalık(38,0)) olarak ayarlamak için kaynak düzeyinde veri türünü değiştirin. Bu değer, sonunda sıfır olmadan sonucu 38 olarak sağlar. Ancak verileri 35.0005 olarak eklerseniz 0,0005 olur ve yalnızca 38 1 değerini sağlar. Sorunu olan sütunlar için sondaki sıfırları kaldırın ve dizeye yayınlayın,
Sorguda UNIX_TIMESTAMP kullandığımızda Hive sorgusu "Desteklenmeyen Alt Sorgu İfadesi" ile başarısız oluyor. Örneğin, bir sorgu çalıştırırsak "Desteklenmeyen Alt Sorgu İfadesi" hatası oluşturur
select * from (SELECT col_1 from table1 where col_2 >= unix_timestamp('2020-03-07','yyyy-MM-dd'));
Bu sorunun kök örneği, Calcite'in olarak
BIGINT
tanıdığı duyarlık eşlemesiHiveTypeSystemImpl.java code
olmadığından geçerli Hive kod tabanının UNIX_TIMESTAMP ayrıştıran bir özel durum oluşturmasıdırUNIX_TIMESTAMP
. Ancak aşağıdaki sorgu düzgün çalışırselect * from (SELECT col_1 from table1 where col_2 >= 1);
col_2 bir tamsayı olduğundan bu komut başarıyla yürütülür. Yukarıdaki sorun hdi-3.1.2-4.1.12(4.1 yığını) ve hdi-3.1.2-5.0.8(5.0 yığını) ile düzeltildi
Yükseltme adımları
1. Verileri hazırlama
HDInsight 3.6 varsayılan olarak ACID tablolarını desteklemez. Ancak ACID tabloları varsa, üzerinde 'MAJOR' sıkıştırması çalıştırın. Sıkıştırma hakkında ayrıntılı bilgi için bkz. Hive Dil Kılavuzu .
Özellik Değer Bash betik URI'si https://hdiconfigactions.blob.core.windows.net/linuxhivemigrationv01/hive-adl-expand-location-v01.sh
Düğüm türleri Head Parametreler
2. SQL veritabanını kopyalayın
Küme varsayılan hive meta veri deposu kullanıyorsa, meta verileri dış meta veri deposuna aktarmak için bu kılavuzu izleyin. Ardından, yükseltme için dış meta veri deposunun bir kopyasını oluşturun.
Küme bir dış Hive meta veri deposu kullanıyorsa, bunun bir kopyasını oluşturun. Seçenekler arasında dışarı/içeri aktarma ve belirli bir noktaya geri yükleme yer alır.
3. Meta veri deposu şemasını yükseltme
Bu adım, meta veri deposu şemasını Hive Schema Tool
yükseltmek için HDInsight 4.0'dan kullanır.
Uyarı
Bu adım geri alınamaz. Bunu yalnızca meta veri deposunun bir kopyasında çalıştırın.
4.0 Hive'a
schematool
erişmek için geçici bir HDInsight 4.0 kümesi oluşturun. Bu adım için varsayılan Hive meta veri depolarını kullanabilirsiniz.HDInsight 4.0 kümesinden yürüterek
schematool
hedef HDInsight 3.6 meta depoyu yükseltin. SQL server adınızı, veritabanı adınızı, kullanıcı adınızı ve parolanızı eklemek için aşağıdaki kabuk betiğini düzenleyin. Baş düğümde bir SSH Oturumu açın ve çalıştırın.SERVER='servername.database.windows.net' # replace with your SQL Server DATABASE='database' # replace with your 3.6 metastore SQL Database USERNAME='username' # replace with your 3.6 metastore username PASSWORD='password' # replace with your 3.6 metastore password STACK_VERSION=$(hdp-select status hive-server2 | awk '{ print $3; }') /usr/hdp/$STACK_VERSION/hive/bin/schematool -upgradeSchema -url "jdbc:sqlserver://$SERVER;databaseName=$DATABASE;trustServerCertificate=false;encrypt=true;hostNameInCertificate=*.database.windows.net;" -userName "$USERNAME" -passWord "$PASSWORD" -dbType "mssql" --verbose
Not
Bu yardımcı program, içinde
/usr/hdp/$STACK_VERSION/hive/scripts/metastore/upgrade/mssql/upgrade-*.mssql.sql
SQL betiklerini yürütmek için istemcisinibeeline
kullanır.Bu betiklerdeki SQL Söz Dizimi diğer istemci araçlarıyla uyumlu olmayabilir. Örneğin, Azure Portal'da SSMS ve Sorgu Düzenleyicisi her komut sonrasında anahtar sözcük
GO
gerektirir.Kaynak kapasitesi veya işlem zaman aşımları nedeniyle herhangi bir betik başarısız olursa SQL Veritabanı ölçeğini artırın.
sorgusuyla
select schema_version from dbo.version
son sürümü doğrulayın.Çıktı, HDInsight 4.0 kümesindeki aşağıdaki bash komutuyla eşleşmelidir.
grep . /usr/hdp/$(hdp-select --version)/hive/scripts/metastore/upgrade/mssql/upgrade.order.mssql | tail -n1 | rev | cut -d'-' -f1 | rev
Geçici HDInsight 4.0 kümesini silin.
4. Yeni bir HDInsight 4.0 kümesi dağıtma
Yükseltilen Hive meta depoyu ve aynı Depolama Hesaplarını seçerek yeni bir HDInsight 4.0 kümesi oluşturun.
Yeni küme aynı varsayılan dosya sistemine sahip olmayı gerektirmez.
Meta veri deposu birden çok Depolama Hesabında bulunan tablolar içeriyorsa, bu tablolara erişmek için bu Depolama Hesaplarını yeni kümeye eklemeniz gerekir. Bkz. HDInsight'a ek Depolama Hesapları ekleme.
Hive işleri depolamaya erişilememesi nedeniyle başarısız olursa, tablo konumunun kümeye eklenmiş bir Depolama Hesabında olduğunu doğrulayın.
Tablo konumunu belirlemek için aşağıdaki Hive komutunu kullanın:
SHOW CREATE TABLE ([db_name.]table_name|view_name);
5. ACID Uyumluluğu için Tabloları Dönüştürme
Yönetilen tablolar HDInsight 4.0 üzerinde ACID uyumlu olmalıdır. ACID olmayan tüm yönetilen tabloları özelliğine 'external.table.purge'='true'
sahip dış tablolara dönüştürmek için HDInsight 4.0 üzerinde çalıştırınstrictmanagedmigration
. Baş düğümden yürüt:
sudo su - hive
STACK_VERSION=$(hdp-select status hive-server2 | awk '{ print $3; }')
/usr/hdp/$STACK_VERSION/hive/bin/hive --config /etc/hive/conf --service strictmanagedmigration --hiveconf hive.strict.managed.tables=true -m automatic --modifyManagedTables
6. Ile sınıf bulunamadı hatası MultiDelimitSerDe
Sorun
Hive sorgusu çalıştırırken belirli durumlarda, java.lang.ClassNotFoundException
sınıf bulunamadığını belirtebilirsiniz org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe
. Bu hata, müşteri HDInsight 3.6'dan HDInsight 4.0'a geçtiğinde oluşur. HDInsight 3.6'nın bir parçası hive-contrib-1.2.1000.2.6.5.3033-1.jar
olan SerDe sınıfı org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe
kaldırılır ve HDI-4.0'ın bir parçası hive-exec jar
olan sınıfını kullanıyoruzorg.apache.hadoop.hive.serde2.MultiDelimitSerDe
. hive-exec jar
hizmeti başlattığımızda varsayılan olarak HS2'ye yüklenir.
SORUN GIDERME ADıMLARı
- Bir klasörün altındaki herhangi bir JAR dosyasının (büyük olasılıkla HDInsight'taki Hive kitaplıkları klasörünün
/usr/hdp/current/hive/lib
altında olması gerekir) bu sınıfı içerip içermediğini denetleyin. - sınıfını
org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe
veorg.apache.hadoop.hive.serde2.MultiDelimitSerDe
çözümde belirtildiği gibi denetleyin.
Çözüm
JAR dosyası ikili bir dosya olsa da, belirli bir sınıf adını aramak için aşağıdaki gibi anahtarlarla
-Hrni
komutunu kullanmayagrep
devam edebilirsinizgrep -Hrni "org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe" /usr/hdp/current/hive/lib
Sınıfı bulamazsa, çıkış döndürmez. Sınıfı bir JAR dosyasında bulursa çıkışı döndürür
Aşağıda HDInsight 4.x kümesinden alınan örnek verilmiştir
sshuser@hn0-alters:~$ grep -Hrni "org.apache.hadoop.hive.serde2.MultiDelimitSerDe" /usr/hdp/4.1.9.7/hive/lib/ Binary file /usr/hdp/4.1.9.7/hive/lib/hive-exec-3.1.0.4.1-SNAPSHOT.jar matches
Yukarıdaki çıkıştan hiçbir jar dosyasının sınıfını
org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe
ve hive-exec jar dosyasının öğesini içermediğiniorg.apache.hadoop.hive.serde2.MultiDelimitSerDe
doğrulayabiliriz.DerDe satır biçiminde tablo oluşturmayı deneyin
ROW FORMAT SERDE org.apache.hadoop.hive.serde2.MultiDelimitSerDe
Bu komut sorunu düzeltir. Tabloyu zaten oluşturduysanız, aşağıdaki komutları kullanarak tabloyu yeniden adlandırabilirsiniz
Hive => ALTER TABLE TABLE_NAME SET SERDE 'org.apache.hadoop.hive.serde2.MultiDelimitSerDe' Backend DB => UPDATE SERDES SET SLIB='org.apache.hadoop.hive.serde2.MultiDelimitSerDe' where SLIB='org.apache.hadoop.hive.contrib.serde2.MultiDelimitSerDe';
Update komutu, arka uç DB'de ayrıntıları el ile güncelleştirmektir ve beeline veya Hive'dan yeni SerDe sınıfıyla tabloyu değiştirmek için alter komutu kullanılır.
Hive Arka Uç DB şeması Betiği karşılaştırır
Geçişi tamamladıktan sonra aşağıdaki betiği çalıştırabilirsiniz.
Arka uç db'de birkaç sütunun eksik olma olasılığı vardır ve bu da sorgu hatalarına neden olur. Şema yükseltmesi düzgün gerçekleşmediyse geçersiz sütun adı sorunuyla karşılaşabiliriz. Aşağıdaki betik, müşteri arka uç veritabanından sütun adını ve veri türünü getirir ve eksik sütun veya yanlış veri türü varsa çıkışı sağlar.
Aşağıdaki yol schemacompare_final.py ve test.csv dosyasını içerir. Betik dosyada schemacompare_final.py
bulunur ve "test.csv" dosyası, tüm tabloların tüm sütun adını ve veri türünü içerir ve bu, hive arka uç db'sinde mevcut olmalıdır.
https://hdiconfigactions2.blob.core.windows.net/hiveschemacompare/schemacompare_final.py
https://hdiconfigactions2.blob.core.windows.net/hiveschemacompare/test.csv
Bu iki dosyayı bağlantıdan indirin. Bu dosyaları hive hizmetinin çalıştığı baş düğümlerden birine kopyalayın.
Betiği yürütme adımları:
"/tmp" dizini altında adlı schemacompare
bir dizin oluşturun.
"schemacompare_final.py" ve "test.csv" klasörlerini "/tmp/schemacompare" klasörüne yerleştirin. "ls -ltrh /tmp/schemacompare/" yapın ve dosyaların mevcut olup olmadığını doğrulayın.
Python betiğini yürütmek için "python schemacompare_final.py" komutunu kullanın. Bu betiğin yürütülmesi başlatılır ve tamamlanması beş dakikadan kısa sürer. Yukarıdaki betik otomatik olarak arka uç veritabanınıza bağlanır ve Hive'ın "return.csv" adlı yeni csv dosyasındaki ayrıntıları kullandığı ve güncelleştirdiği her tablodan ayrıntıları getirir. Dosya return.csv oluşturduktan sonra verileri "test.csv" dosyasıyla karşılaştırır ve tablo adının altında eksik bir şey varsa sütun adını veya veri türünü yazdırır.
Betiği yürüttkten sonra, tablolar için ayrıntıların getirildiğini ve betiğin devam ettiğini gösteren aşağıdaki satırları görebilirsiniz
KEY_CONSTRAINTS
Details Fetched
DELEGATION_TOKENS
Details Fetched
WRITE_SET
Details Fetched
SERDES
Details Fetched
Ayrıca fark ayrıntılarını "FARK AYRINTILARI:" satırı altında görebilirsiniz. Bir fark varsa,
PART_COL_STATS;
('difference', ['BIT_VECTOR', 'varbinary'])
The line with semicolon PART_COL_STATS; is the table name. And under the table name you can find the differences as ('difference', ['BIT_VECTOR', 'varbinary']) if there are any difference in column or datatype.
Tabloda fark yoksa çıkış
BUCKETING_COLS;
('difference', [])
PARTITIONS;
('difference', [])
Bu çıktıda eksik veya yanlış olan sütun adlarını bulabilirsiniz. Sütunun eksik olup olmadığını doğrulamak için arka uç veritabanınızda aşağıdaki sorguyu çalıştırabilirsiniz.
SELECT * FROM INFORMATION_SCHEMA.columns WHERE TABLE_NAME = 'PART_COL_STATS';
Tabloda sütunlardan herhangi birinin kaçırılması durumunda, örneğin, ekleme veya ekleme üzerine yazma gibi sorguları çalıştırırsak istatistikler otomatik olarak hesaplanır ve PART_COL_STATS ve TAB_COL_STATS gibi istatistik tablosunu güncelleştirmeye çalışır. Tablolarda "BIT_VECTOR" gibi bir sütun eksikse "Geçersiz sütun adı" hatasıyla başarısız olur. Sütunu aşağıdaki komutlarda belirtildiği gibi ekleyebilirsiniz. Geçici bir çözüm olarak, aşağıdaki özellikleri ayarlayarak istatistikleri devre dışı bırakabilirsiniz. Bu özellikler arka uç Veritabanındaki istatistikleri güncelleştiremez.
hive.stats.autogather=false;
hive.stats.column.autogather=false;
To Fix this issue, run the following two queries on backend SQL server (Hive metastore DB):
ALTER TABLE PART_COL_STATS ADD BIT_VECTOR VARBINARY(MAX);
ALTER TABLE TAB_COL_STATS ADD BIT_VECTOR VARBINARY(MAX);
Bu adım, geçişten sonra bir kez "Geçersiz sütun adı" ile başarısız olan sorgu hatalarını önler.
HDInsight sürümleri arasında Hive'ın güvenliğini sağlama
HDInsight isteğe bağlı olarak HDInsight Enterprise Security Package (ESP) kullanarak Microsoft Entra ID ile tümleşir. ESP, küme içindeki belirli kaynakların izinlerini yönetmek için Kerberos ve Apache Ranger kullanır. HDInsight 3.6'da Hive'a dağıtılan Ranger ilkeleri, aşağıdaki adımlarla HDInsight 4.0'a geçirilebilir:
- HDInsight 3.6 kümenizde Ranger Hizmet Yöneticisi paneline gidin.
- HIVE adlı ilkeye gidin ve ilkeyi bir json dosyasına aktarın.
- Dışarı aktarılan ilke json dosyasında başvuruda bulunılan tüm kullanıcıların yeni kümede bulunduğundan emin olun. İlke json'unda bir kullanıcıya başvurulsa ancak yeni kümede yoksa, kullanıcıyı yeni kümeye ekleyin veya ilkeden başvuruyu kaldırın.
- HDInsight 4.0 kümenizde Ranger Service Manager paneline gidin.
- HIVE adlı ilkeye gidin ve 2. adımdaki ranger ilkesi json dosyasını içeri aktarın.
HDInsight 4.0'da uygulama değişiklikleri gerektirebilecek Hive değişiklikleri
ACID tabloları için meta veri depolarını Spark ile Hive arasında paylaşmak için bkz . Hive Ambarı Bağlayıcısı kullanarak ek yapılandırma.
HDInsight 4.0, Depolama Tabanlı Yetkilendirme kullanır. Dosya izinlerini değiştirirseniz veya Hive'dan farklı bir kullanıcı olarak klasör oluşturursanız, depolama izinlerine bağlı olarak büyük olasılıkla Hive hatalarına isabet edersiniz. Düzeltmek için kullanıcıya erişim verin
rw-
. Bkz. HDFS İzinleri Kılavuzu.HiveCLI
ileBeeline
değiştirilir.
Diğer değişiklikler için HDInsight 4.0 Duyurusu'na bakın.
Geçiş sonrası
Geçişi tamamladıktan sonra bu adımları izlediğinize emin olun.
Tablo Sanity
- Tablo özelliklerini değiştirmek yerine tablo türünü değiştirmek için CTAS veya IOW kullanarak Hive 3.1'de tabloları yeniden oluşturun.
- DoA'ları false olarak tutun.
- Yönetilen tablo/veri sahipliğinin "hive" kullanıcısıyla olduğundan emin olun.
- Tablo biçimi ORC ise yönetilen ACID tablolarını, ORC olmayan türler için ise ACID olmayan yönetilen tabloları kullanın.
- Yeniden oluşturulan tablolarda istatistikleri yeniden oluşturun, geçiş yanlış istatistiklere neden olabilir.
Küme Durumu
Birden çok küme aynı depolama alanını ve HMS DB'yi paylaşıyorsa, otomatik sıkıştırma/sıkıştırma iş parçacıklarını yalnızca bir kümede etkinleştirmeli ve diğer her yerde devre dışı bırakmalıyız.
Cpu kullanımını azaltmak için Meta Veri Deposu'nda ayarlamalar yapın.
İşlem olay dinleyicilerini devre dışı bırakın.
Not
Yalnızca kovan çoğaltma özelliği kullanılmadıysa aşağıdaki adımları gerçekleştirin.
- Ambari kullanıcı arabiriminden hive.metastore.transactional.event.listeners değerini kaldırın.
- Varsayılan Değer:
org.apache.hive.hcatalog.listener.DbNotificationListener
- Yeni değer:
<Empty>
Hive PrivilegeSynchronizer'ı devre dışı bırakma
- Ambari kullanıcı arabiriminde hive.privilege.synchronizer = false değerini ayarlayın.
- Varsayılan Değer:
true
- Yeni değer:
false
Bölüm onarım özelliğini iyileştirme
Bölüm onarımını devre dışı bırakma - Bu özellik, depolama konumundaki Hive tablolarının bölümlerini Hive meta veri deposuyla eşitlemek için kullanılır. Veri alımından sonra kullanılırsa
msck repair
bu özelliği devre dışı bırakabilirsiniz.Özelliği devre dışı bırakmak için ALTER TABLE kullanarak tablo özelliklerinin altına "discover.partitions=false" ekleyin. VEYA (özellik devre dışı bırakılamıyorsa)
Bölüm onarım sıklığını artırın.
Ambari kullanıcı arabiriminden "metastore.partition.management.task.frequency" değerini (saniye cinsinden) artırın.
Not
Bu değişiklik, depolama alanına alınan bazı bölümlerin görünürlüğünü geciktirebilir.
- Varsayılan Değer:
60
- Önerilen değer:
3600
- Varsayılan Değer:
Gelişmiş İyileştirmeler Aşağıdaki seçeneklerin üretime uygulanmadan önce daha düşük (üretim dışı) bir ortamda test edilmesi gerekir.
- Gerçekleştirilmiş görünüm kullanılmıyorsa Gerçekleştirilmiş görünümle ilgili dinleyiciyi kaldırın.
- Ambari kullanıcı arabiriminden özel bir özellik ekleyin (özel hive-site.xml) ve istenmeyen arka plan meta veri deposu iş parçacıklarını kaldırın.
- Özellik adı: metastore.task.threads.remote
- Varsayılan Değer:
N/A (it uses few class names internally)
- Yeni değer:
org.apache.hadoop.hive.metastore.txn.AcidHouseKeeperService,org.apache.hadoop.hive.metastore.txn.AcidOpenTxnsCounterService,org.apache.hadoop.hive.metastore.txn.AcidCompactionHistoryService,org.apache.hadoop.hive.metastore.txn.AcidWriteSetService,org.apache.hadoop.hive.metastore.PartitionManagementTask
Çoğaltma devre dışı bırakılırsa arka plan iş parçacıklarını devre dışı bırakın.
- Ambari kullanıcı arabiriminden özel bir özellik ekleyin (özel hive-site.xml) ve istenmeyen iş parçacıklarını kaldırın.
- Özellik adı: metastore.task.threads.always
- Varsayılan Değer:
N/A (it uses few class names internally)
- Yeni değer:
org.apache.hadoop.hive.metastore.RuntimeStatsCleanerTask
Sorgu Ayarlama
- Sorguları TPC-DS iş yükleri için ayarlanmış olarak çalıştırmak için Hive'ın varsayılan yapılandırmalarını koruyun. Yalnızca başarısız olursa veya yavaş çalışıyorsa sorgu düzeyi ayarlaması gerekir.
- Hatalı plan veya yanlış sonuçlardan kaçınmak için istatistiklerin güncel olduğundan emin olun.
- Dış ve yönetilen ACID tablolarını birleştirme sorgusu türünde karıştırmaktan kaçının. Böyle bir durumda, rekreasyon aracılığıyla hariciyi YÖNETILEN ACID olmayan tabloya dönüştürmeyi deneyin.
- Hive-3'te, ürün hataları olabilecek vektörleştirme, CBO, bölge ile zaman damgası vb. üzerinde çok fazla çalışma oldu. Bu nedenle, herhangi bir sorgu yanlış sonuçlar verirse, bunun işe yarar olup olmadığını görmek için vektörleştirmeyi, CBO'yu, harita birleştirmeyi vb. devre dışı bırakmayı deneyin.
Geçiş sonrasında yanlış sonuçları ve düşük performansı düzeltmek için izlenecek diğer adımlar
Hive sorgusu yanlış sonuç veriyor. Select count(*) sorgusu bile yanlış sonuç verir.
Neden "hive.compute.query.using.stats" özelliği varsayılan olarak true olarak ayarlanmıştır. True olarak ayarlarsak sorguyu yürütmek için meta veri deposunda depolanan istatistikleri kullanır. İstatistikler güncel değilse yanlış sonuçlara neden olur.
Çözümleme , tablo düzeyinde ve sütun düzeyinde komutu kullanarak
alter table <table_name> compute statics;
yönetilen tabloların istatistiklerini toplar. Başvuru bağlantısı - https://cwiki.apache.org/confluence/display/hive/statsdev#StatsDev-TableandPartitionStatisticsSorunun Hive sorgularının yürütülmesi uzun sürüyor.
Neden Sorgunun bir birleştirme koşulu varsa hive, tablo boyutuna ve birleştirme koşuluna göre eşleme birleştirme veya birleştirme birleştirmesi kullanıp kullanmayacağınız bir plan oluşturur. Tablolardan biri küçük bir boyut içeriyorsa, bu tabloyu belleğe yükler ve birleştirme işlemini gerçekleştirir. Bu şekilde, birleştirme birleştirmeye kıyasla sorgu yürütme daha hızlı olur.
Çözüm Varsayılan değer olan "hive.auto.convert.join=true" özelliğini ayarladığınızdan emin olun. False olarak ayarlanması birleştirme birleştirmeyi kullanır ve performansın düşmesine neden olabilir. Hive, kümede ayarlanan aşağıdaki özelliklere göre eşleme birleştirmenin kullanılıp kullanılmayacağını belirler
set hive.auto.convert.join=true; set hive.auto.convert.join.noconditionaltask=true; set hive.auto.convert.join.noconditionaltask.size=<value>; set hive.mapjoin.smalltable.filesize = <value>;
Ortak birleşim,
hive.auto.convert.join.noconditionaltask=true
tahmini küçük tablo boyutu hive'dan küçükse, otomatik olarak eşleme birleşimine dönüştürülebilir.auto.convert.join.noconditionaltask.size
(varsayılan değer 10000000 MB'tır).Özelliği
hive.auto.convert.join
true olarak ayarlayarak OOM ile ilgili herhangi bir sorunla karşılaşırsanız, küme düzeyinde değil, yalnızca oturum düzeyinde söz konusu sorgu için false olarak ayarlamanız önerilir. bu sorun, istatistikler yanlışsa ve Hive istatistiklere göre harita birleştirmeyi kullanmaya karar verirse oluşabilir.
Hive sorgusunun birleştirme koşulu varsa ve söz konusu tablolarda null veya boş değerler varsa Hive sorgusu yanlış sonuç verir.
Neden Sorguda yer alan tablolarda çok fazla null değer varsa bazen null değerlerle ilgili bir sorun yaşayabiliriz. Hive, sorgu iyileştirmesini hatalı sonuçlara neden olan null değerlerle yanlış gerçekleştirir.
Çözüm Yanlış sonuçlar alırsanız özelliği
set hive.cbo.returnpath.hiveop=true
oturum düzeyinde ayarlamayı denemenizi öneririz. Bu yapılandırma birleştirme anahtarlarında null filtrelemeye neden olmaz. Tablolarda birden çok tablo arasındaki birleştirme işlemini iyileştirmek için çok sayıda null değer varsa, bu yapılandırmayı etkinleştirerek yalnızca null değerleri dikkate almamasını sağlayabiliriz.Hive sorgusunun birden çok birleştirme koşulu varsa, Hive sorgusu yanlış sonuç verir.
Neden Bazen Tez, eşlem birleşimleriyle birden çok kez aynı birleşimler olduğunda hatalı çalışma zamanı planları üretir.
Çözüm False olarak ayarlandığında
hive.merge.nway.joins
yanlış sonuçlar alma olasılığı vardır. Yalnızca etkilenen sorgu için true olarak ayarlamayı deneyin. Bu, aynı koşulda birden çok birleştirmeyle sorgulamaya yardımcı olur, birleştirmeleri tek bir birleştirme işlecinde birleştirir. Bu yöntem, yeniden birleştirme aşamasını önlemek için büyük karıştırma birleştirmeleri durumunda kullanışlıdır.Sorun' Önceki çalıştırmalarla karşılaştırıldığında sorgu yürütme süresinde her gün bir artış var.
Neden Daha fazla küçük dosya sayısında artış olduğunda bu sorun oluşabilir. Bu nedenle hive, verileri işlemek için tüm dosyaları okurken zaman alır ve bu da yürütme süresinin artmasına neden olur.
Çözüm Yönetilen tablolar için sıkıştırmayı sık sık çalıştırdığınızdan emin olun. Bu adım, küçük dosyaları önler ve performansı artırır.
Başvuru bağlantısı: Hive İşlemleri - Apache Hive - Apache Software Foundation.
Sorun Hive sorgusu, müşteri yönetilen acid ork tablosu ve yönetilen ACID olmayan ork tablosunda birleştirme koşulu kullandığında yanlış sonuç verir.
Neden HIVE 3'ten başlayarak, tüm yönetilen tabloların asit tablosu olarak tutulması kesinlikle istenir. Bunu bir asit tablosu olarak tutmak istiyorsak tablo biçimi ork olmalı ve ana ölçüt budur. Ancak "hive.strict.managed.tables" katı yönetilen tablo özelliğini false olarak devre dışı bırakırsak, yönetilen bir ACID olmayan tablo oluşturabiliriz. Bazı durumlarda müşteri bir dış ORC tablosu oluşturur veya geçiş sonrasında tablo dış tabloya dönüştürülür ve katı yönetilen tablo özelliğini devre dışı bırakır ve yönetilen tabloya dönüştürür. Bu noktada, tablo ACID tarafından yönetilmeyen ork biçimine dönüştürülür.
Acid tarafından yönetilen ork tablosuyla ACID tarafından yönetilmeyen ORC tablosuyla tabloya katılırsanız Çözüm Hive iyileştirmesi yanlış olur.
Dış tabloyu yönetilen tabloya dönüştürüyorsanız,
- "hive.strict.managed.tables" özelliğini false olarak ayarlamayın. Ayarlarsanız ACID tarafından yönetilmeyen bir tablo oluşturabilirsiniz ancak HIVE-3'te istenmiyor
- Yerine aşağıdaki alter komutunu kullanarak dış tabloyu yönetilen tabloya dönüştürün
alter table <table_name> set TBLPROPERTIES ('EXTERNAL'='false');
alter table rt set TBLPROPERTIES ('EXTERNAL'='false', 'transactional'='true');
Sorun giderme kılavuzu
Hive iş yükleri için HDInsight 3.6 - 4.0 sorun giderme kılavuzu, Hive iş yüklerini HDInsight 3.6'dan HDInsight 4.0'a geçirirken karşılaşılan yaygın sorunların yanıtlarını sağlar.