pěkné povídání, na jednom projektu jsme stáli před podobným problémem a skončili jsme také podobně, BigTop artefakty, vlastní generování konfigurací, ansible atd.
Dospěli jsme ale k několika rozdílům:
- Apache Impalu jsme používali k generování reportů, Presto a ani jeho klony nedokázaly využít efektivitu partition pruning a jiných optimalizací, nakonec data částečně klonujeme do ClickHouse, kde běží reporty, na ad-hoc dotazy necháváme livy, spark sql/hive sql
- ponechali jsme spark, ale povýšili ho na poslední verzi, stejně tak se hodilo zvýšit verze hadoop komponent s vyřešit tím dlouhodé neduhy
- líbil se nám styl Cloudera Manageru a jeho agentů - vygenerovat dopředu celou konfiguraci pro službu a tu spouštět, dobře se to ladí, dobře se to předává jakémukoliv správci procesů, nakonec to děláme stejně jen místo supervisord jsme zvolil Hashicorp Nomad, prakticky to je ale jedno co se zvolí
- Mit kerberos se osvědčil, ale po vzoru CDH 7 jsme přidali Apache Knox a Atlas na jednotnou GW a datový katalog
- Monitoring jsme rozdělili na realtime a dlouhodobý (stejně Cloudera Manager neuměl uchovávat dlouhou historií grafů), realtime máme nad Netdatou s obohacenými metrikami kolem hadoop služeb, dlouhodobé nad VictoriaMetrics, Grafana (ale i PowerBI) k zobrazování. Zatím jsme nevyřešili reporting využití podle jednotlivých uživatelů, resource skupin, ale to stejně nebylo v Express, ale až v Enterprise verzi