Niestandardowe konfiguracje źródła/zlewu nie są rozpoznawane

Napisałem moje niestandardowe źródło danych/ujście dla mojej aplikacji do przesyłania strumieniowego Spark i próbuję zainicjować ją z pliku metics.properties - ale to nie działa z executorami. Nie mam kontroli nad maszynami w klastrze Spark, więc nie mogę skopiować pliku właściwości w katalogu $ SPARK_HOME/conf/w klastrze. Mam go w słoiku, w którym działa moja aplikacja, ale do czasu, gdy mój słoik zostanie pobrany na węzły robocze w klastrze, programy wykonawcze są już uruchomione, a ich system metryk został już zainicjowany - w ten sposób nie pobieram pliku z niestandardową konfiguracją źródła w nim .Niestandardowe konfiguracje źródła/zlewu nie są rozpoznawane

następstwie tego post, mam określony „spark.files = metrics.properties” i „spark.metrics.conf = metrics.properties” ale do czasu „metrics.properties” dostarczany jest do wykonawców, ich system metryczny jest już zainicjowany.

Jeśli zainicjuję mój własny system metryk, to pobiera on mój plik, ale brakuje mi danych/właściwości poziomu/egzaminu na poziomie głównym/wykonawczym (np. Executor.sink.mySink.propName = myProp - nie można odczytać "propName" z "mySink"), ponieważ są one initialized według systemu metrycznego Sparka.

Czy istnieje (programowy) sposób dostarczenia "metryki.properties" przed wykonawcami initialize ich systemu metryk?

Update1: Próbuję to na samodzielne Spark 2.0.0 klaster

Update2: Myśl hacki na osiągnięcie tego celu - przed rozpoczęciem pracy „rzeczywistą” iskra, rozpocząć pracę atrapę do skopiowania metrics.properties na każdego pracownika. Następnie rozpocznij swoją obecną pracę od znanej lokalizacji pliku. Wady - jeśli pracownik umiera, a inny pracownik zajmie miejsce, nie będzie miał tego pliku w znanej ścieżce. Rozwiązanie alternatywne - po uruchomieniu nowego komputera pracującego, pobiera metits.properties z twojego git-repo i umieszcza je w znanej ścieżce. Chociaż może działać, jest strasznie hacky, a preferowanym rozwiązaniem jest, aby Spark wspierał go wewnętrznie.

Źródło

2016-09-06 K P

zobaczyć Spark metrics on wordcount example Zasadniczo uważam, trzeba dodać --files aby wysłać metrics.properties do wszystkich pracowników

Źródło

2016-09-07 05:24:38

Próbowałem tego. 2 problemy - 1) Nie kopiuje "metryki.properties" na maszynę sterownika - skoro ma kopiować pliki tylko w katalogu wykonawczym executorów. 2) Do czasu skopiowania tych plików na executorach system metryk próbowałby zainicjować i się nie udało - z powodu braku plików. –

SparkConf only load local system properties if they start with the prefix spark., masz tacy, aby załadować swoje właściwości dodając iskrę?

Źródło

2016-09-14 13:09:50 jlopezmat

Nie rozumiem, co to oznacza w kontekście pytania? –

'private val masterMetricsSystem = MetricsSystem.createMetricsSystem (" master ", conf, securityMgr)' Ta wartość conf to SparkConf, więc jeśli możesz wstawić do tej właściwości swoje właściwości, możesz utworzyć metrykęSystem z własnymi właściwościami, w twoim przykładzie spark.executor.sink.mySink.propName = myProp, a następnie odczytaj go w zlewie. Nigdy nie próbowałem nic zrobić z metricSystem, więc nie wiem, czy mógłbyś użyć tego, ale zmieniłem niektóre właściwości Executora, dodając --conf do sparkSubmit, więc mam nadzieję, że to ci się przyda. – jlopezmat

Widziałem również ten kod, a właściwości metryk określono jako: executor.source.mysource.class = MyClass. Dziękuję za odpowiedź, ale to nie działa. –

Niestandardowe konfiguracje źródła/zlewu nie są rozpoznawane

Odpowiedz

Powiązane problemy