2025-03-02
Wykonując testy, warto mieć pod ręką coś małego, co powinno zawsze zadziałać. Oto moja propozycja:
import findspark
findspark.init()
findspark.find()
from pyspark.sql import SparkSession
# Create a SparkSession object
spark = SparkSession.builder.appName("CreateDataFrame").getOrCreate()
# Use the SparkSession object to create a DataFrame
df_day_of_week = spark.createDataFrame([(0, "Sunday"), (1, "Monday"),
(2, "Tuesday"), (3, "Wednesday"),
(4, "Thursday"), (5, "Friday"),
(6, "Saturday")],
["day_of_week_num", "day_of_week"])
# Show the DataFrame
df_day_of_week.show()
Snippet pochodzi z https://stackoverflow.com/questions/76743484/configuration-of-pyspark-py4jjavaerror
2025-03-02
W świeżej instalacji Apache Spark po wykonaniu polecenia df.show() dla prostego data frame pojawiał się bład:
Py4JJavaError: An error occurred while calling o160.showString.
Instalacja nowa, robiona zgodnie z 1000 instrukcji dostępnych na necie.
Bez owijania w bawełnę – chodziło o wersje aplikacji. Tak więc krótko:
Instalacja dotyczy Spark 3.5.5 (FEB 27 2025) z wbudowanym Apache Hadoop 3.3
Java (JDK) – najnowsza jaką można wybrać to 17, bo na tej stronie https://spark.apache.org/docs/latest/index.html piszą, że Spark runs on Java 8/11/17,
WinUtils.exe – dopasowany numerem wesji do wersji Hadoop pobrany stąd: https://github.com/cdarlint/winutils
Python – piszą w dokumentacji, że wersja to ma być 3.8 i wyższe, ale uwaga… W momencie publikowania Sparka, na świecie nie było jeszcze Pythona 3.12. Dlatego nie wybieraj 3.12. Zostań maksymalnie przy 3.11. To ważne. Nawet jak instalacja sie uda, to potem można się spodziewać pułapek już podczas uruchamiania programów.
Co więcej – instalując wszystkie wymienione powyżej komponenty, zainstaluj je do katalogu, który w nazwie całej ścieżki nie ma spacji, ani znaków narodowych.
I co najśmieszniejsze – w świecie Linux/McOS, kiedy chcesz uruchomić pythona w wersji 3 piszesz python3. Ta reguła nie działa w świecie WIndows. Dlatego przejdź do katalogu z instalacją pythona i skopiuj plik python.exe zamieniając mu nazwę na python3.exe.
Pr
2025-02-23
Pracujesz sobie na systemie z bardzo okrojonymi uprawnieniami. Jesteś prawie że zwykłym użytkownikiem, zapomnij o instalacji programu tak jak należy. Z drugiej jednak strony na systemie jest zainstalowany stary program (w tym przypadku terraform), a ty chcesz używać nowszej wersji. Co zrobić?
Opcja 1
- Pobierz nową wersję programu i zapisz ją gdzie chcesz
- Uruchamiając terraforma podawaj pełną ścieżkę dostępu do tego programu (mało wygodne)
Opcja 2
- Utwórz katalog na programy, które chcesz „podmienić”
- Pobierz nową wersję programu i zapisz ją do tego katalogu
- Zmodyfikuj zmienną PATH użytkownika, tak aby wskazywała również na ten katalog
- Napisz skrypt, który będzie wywoływać właściwą wersję programu podając jego pełną ścieżkę. Zapisz skrypt w pliku o przyjemnej, krótkiej nazwie, np. tf.bat
@echo off
C:\Users\xxx\Desktop\bin\terraform.exe %*
Ten skrypt najpierw wyłącza wyświetlanie na ekran informacji o poszczególnych uruchamianych komendach, a potem wywołuje tę właściwą wersję terraforma przekazując do niego pełny zestaw argumentów %*
Dzięki temu można teraz uruchamiać najnowszą wersję programu używając wybranej krótkiej nazwy skryptu i przekazując do niego dowolne argumenty:
tf --version
2025-01-22
Log Analytics Workspace to taki „Azurowy śmietniczek na logi”. Z jednej strony koncepcja zapisywania wszystkich logów w jednym miejscu brzmi atrakcyjnie, ale korzystanie z tagiego zbioru… delikatnie mówiąc nie jest zbyt wygodne.
Ogólnie rzecz biorąc, LogAnalytics przechowuje tabele z danymi i to już jest w sumie krok we właściwą stronę, bo jednak nasze logi są rozrzucane między wiele tabel. Tabele te powstają po podłączeniu zasobów określonych typów. Masz np. SQL Server, to pojawią sie tabele pozwalające na śledzenie specyficznych zdarzeń związanych z określonym zasobem.
Ponieważ jest tam aż tyle rzeczy, to fajnie by było sprawdzić, np. jakie wartości występują w określonej kolumnie. Zrobisz to prostym poleceniem:
AzureDiagnostics
| summarize by operationname
| order by operationname asc
2024-12-27
Mam komputer z Windows, na którym jakiś czas temu podłączyłem się do sieci WiFi. Oczywiście podczas podłączania wprowadzałem klucz, ale… teraz go nie pamiętam. Co zrobić?
Najpierw uruchom polecenie
netsh
Teraz będąc już „w programie” netsh napisz
wlan
wlan odpowiada właśnie z wireless network czyli sieć bezprzewodową. Teraz można wyświetlić listę takich sieci uruchamiając:
show profiles
Tu powinno się udać zobaczyć nazwę sieci, dla której klucza szukamy. Zakładając że nazwa tej sieci to MYHOMEWIFI wpisz kolejne polecenie:
show profile MYHOMEWIFI key=clear
Klucz zobaczysz „czystym tekstem” w sekcji Security Settings –> Key Content. Gdyby show profile uruchomić bez opcji key=clear, to zboaczylibyśmy na ekranie w sumie te same informacje, ale z pominiętą częścią z kluczem.
Udało się? Super! Może zechcesz mi wysłać kilka drobniaków >> https://paypal.me/controlconversation ?
2024-12-19
Visual Studio Code robi czasami psikusy ze środowiskami wirtualnymi. Jeśli instalujesz moduły, a one nadal nie działają to można podejść do sprawy tak:
– utworzyć środowisko wirtualne, co robi się komendą:
python -m venv venv
aktywować to środowisko komendą:
venv/scripts/activate.ps1
Na tym środowisku można zaintalować wymagane pakiety (zakładając że to będzie nowe środowisko, to należy zaintalować wszystkie pakiety od początku)
Kiedy to wszystko już będzie gotowe, trzeba jeszcze zadbać, żeby VSC rzeczywiście uruchamiało programy w tym środowisku wirtualnym. Powinno wystarczyć uruchomienie Command Palette (Shift + Ctrl + P na Windows i Linux lub Shift + Cmd + P na macOS). Następnie wpisujemy/szukamy komendy „Python: Select Interpreter”. Wybieramy opcję naciskając Enter i z listy rozwijanej wybieramy Pythona z katalogu venv
Przy takiej konfiguracji wszystkie pakiety znajdują się w środowisku wirtualnym i python uruchamiający programy też będzie działać w tym samym środowisku i wszystko powinno działać.
Jak chcesz poczytać więcej o venv to zajrzyj tu: https://code.visualstudio.com/docs/python/environments
2024-12-01
Zdarza sie, że po zainstalowaniu PostgreSQL, domyślny jezyk ustawi się np. na Polski. Mikołaj Rej by się ucieszył, ale czytanie komunikatów po polsku, jest dla mnie dość egzotyczne.
W takim przypadku można uruchomić polecenie:
SET lc_messages TO 'en_US.UTF-8′;
Można też sprawdzić jakie aktualnie onowiązują ustawnienia uruchamiając:
SELECT * FROM pg_settings where name like '%lc_%’
W kolumnie reset_value zobaczysz jednak starą wartość (u mnie „Polish_Poland.1252”), co oznacza, że po ponownym uruchomieniu serwera komunikaty znowu będą w języku Kochanowskiego. Żeby zmiana była trwała należy ją wprowadzić w pliku konfiguracyjnym postgresql.conf. Odszukaj parametru lc_messages, wpisz mu wartość:
lc_messages = 'en_US.UTF-8′
Zrestartuj usługę i gotowe!