[mk321]

#programowanie #java #elasticsearch #spark #bazydanych #pracait

Mamy dużą bazę danych (Oracle), z której generujemy raporty (SQL-ki z różnymi count, group by, join, where itd).

Obecnie mamy w bazie tyle danych, że takie zapytania wykonują się długo (mimo pozakładanych indeksów i optymalizacji przez speca od DB).

Chcielibyśmy użyć czegoś, żeby obok "indeksować" potrzebne dane do raportów (nie wiem, jakaś inna "baza").

Przy okazji, żeby łatwiej tworzyć nowe raporty (np. coś w stylu jak są hurtownie danych i kostki OLAP/ETL).

Czego do tego najlepiej użyć? Miałem dwa pomysły, ale chyba żaden nie jest dobry:
- Elasticsearch: Łatwo indeksować i wyszukiwać. Jest to "baza danych", więc mam gotowe rozwiązanie gdzie mogę obok przechowywać dane (ten "index"). Ale problematyczne są group by (których mamy sporo) i raporty agregujące dane (tzn. ciężko osiągnąć coś w stylu kostek OLAP).
- Spark: Wydaje mi się, że łatwo osiągnąć te group by i agregacje. Ale co z przechowywaniem tych zagregowanych danych? Nie chciałbym za każdym razem ciągnąć wszystkiego z bazy i liczyć od nowa. A tak w tutorialch jest: pociągnij wszystko z bazy, przelicz, zapisz do CSV i koniec. A jak jutro chcesz nowy raport z aktualnymi danymi, to od nowa wszystko (i mielisz bazę na produkcji :/ ). Trzeba sobie samemu podpiąć bazę i ręcznie zapisywać, a potem wczytywać? Czy inaczej się do tego podchodzi? Może coś w HDFS?

W którym kierunku powinienem iść? (Uwzględniając też dla mnie przydatność na rynku pracy.) A może coś innego? Słyszałem o rozwiązaniach np. QlikView lub Microsoft SQL Server, gdzie jest już gotowiec ze wszystkim (nawet z GUI, że można sobie takie raporty wyklikać). Ale kosztuje to miliony monet i jako Java dev wolałbym coś czego się używa na rynku (np. Spark często się pojawia w wymaganiach o pracę - chociaż słyszałem też głosy, że się od tego odchodzi), a nie zostać konfiguratorem jakiegoś płatnego rozwiązania.

[n.....a]

@mk321: Spark jest magiczny, polecam wypróbować

[mk321]

@nowa_zielonka: no właśnie jak patrzyłem, to w Sparku te agregacje i inne rzeczy robią się "same". Tylko co z zapisaniem tego, żeby nie ciągnąć za każdym razem ze źródłowej bazy?

[MikelThief]

@mk321: to może po prostu drugi server do bazki? albo informatica do kręcenia raportów? albo controlM. Albo widoki zmaterializowane które się przekręcają. no multum opcji jest

[piterRRR]

@mk321: przerzuć dane na hdfs, np sqoopem je sciągaj codziennie, jak je bedziesz miec na hdfs to juz lecisz spark, impala , itp..

[Kura_Wasylisa]

@mk321 możesz sobie kafka/nifi/sqoopem/sparkiem przerzucać dane na hdfs i robić partycje po dniach w plikach parquetowych.

Ew możesz odwzorowac relacyjna bazę w hivie ale to dość złożony proces.

Sparka mozesz wpiac do powerbi lub tableau. Impale tez.

Jak cos to chętnie pomogę.

[JacobTheLiar]

Czy raporty generujesz za każdym razem dla tych samych danych? U mnie w spółce mamy zestawy raportów które są generowane na danych które nie ulegają zmianom w czasie (dane sprzedażowe), są do tego zdefiniowane raporty, i jeżeli dla podanych parametrów nie ma wygenerowanego raportu to się generuje i zapisuje. Jak jest wyświetlam uprzednio wygenerowany lub też daje możliwość wymuszenia ponownego przeliczenia raport. Mam jakieś ciągotki do SQL i wykonałbym to na silniku

[Myzreal]

@mk321: Po pierwsze, juz popelniacie blad odpalajac tak dlugie zapytania na zywej bazie. Powinniscie robic read replica i na niej uruchamiac takie dlugie zapytania, podczas gdy glowna baza normalnie obsluguje ruch (chyba ze juz tak macie zrobione tylko nie wspomniales)

Po drugie, Spark jest imho najlepszym rozwiazaniem do tego. I nie musisz wszystkiego obliczac za kazdym razem raczej, nie pamietam juz szczegolow ale pogoogluj koncpet Sparkowego "checkpoint" - on jest w

[kaczors]

@mk321: Hej, w Sparku robię już od kilku lat. Jeżeli nie chcesz codziennie mielić od nowa caaałej bazy, to po prostu porobić trzeba jakieś takie joby pośrednie, które każdego dnia porobią jakieś agregacje dzienne (przykładowo) i zapiszą sobie gdzieś (może być jakiś hdfs, najlepiej jako parquet, czy nawet z powrotem do bazy) a dalej docelowy job raportujący po prostu będzie przelatywał po istniejących agregatach.

[dejanarchos]

@mk321: O to to, co napisał @kaczors. Proces preparujący dane cyklicznie i/lub na żądanie nie jest złym rozwiązaniem

[Marasson]

@dejanarchos , @Myzreal. Przyjaciele podepnę się do tematu. Aktualnie wybraliśmy do generowania raportów narzędzie KnowAge(darmową wersję). Mamy bazę na postgreSQL. W tej chwili już nie ogranicza mnie system, więc szukam innych platform. Czy PowerBi będzie też dobrym rozwiązaniem? Dziękuje.

[mk321]

może po prostu drugi server do bazki?

Powinniscie robic read replica i na niej uruchamiac takie dlugie zapytania

@MikelThief: @Myzreal: myślałem o tym na początku, żeby po prostu zrobić replikację do drugiej bazy Oracle obok. Aktualnie tego nie mamy, bo raporty, które są konieczne jeszcze obecnie dają radę się wykonywać (ale nie potrwa to długo). Jak mamy przerzucać dane obok, to zamiast takiej samej bazy wolelibyśmy coś dedykowanego pod to

[Kura_Wasylisa]

@mk321 co do kafki mozesz podlaczyc connector i dac kazda tabele na osobny topic. Nastepnie ustalic co ile chciałbyś robic streaming (moze byc eventowy, kafka rozpozna nowe rekordy, zobacz debezium).

Nastepnie procesowac np za pomoca nifi dalej.

Co do sqoopa mozesz ustawic crona lub oozie(przy hdfs) . W komendzie sqoopa mozesz podac warunek where (on dziala w calosci po jdbc)

Spark ma opcje podlaczenia sie za pomoca jdbc do bazy danych i

[piterRRR]

@mk321: mozna sqoopem pobierac tylko nowe wiersze albo te które zostały zaktualizowane (append lub lastmodified)
https://sqoop.apache.org/docs/1.4.2/SqoopUserGuide.html#_incremental_imports
w sqoop pobierasz całą tabele --table albo zapytaniem w --query mozesz sobie wybrac co tam chcesz, no i jak nawet byś pobierał całą tabele to sqooop moze to szybko robić (zwiekszenie num-mappers i podanie kolumny --split-by)

[dejanarchos]

@mk321: W ogóle optymalne rozwiązanie będzie zależało od specyfiki tego, co dokładnie robisz.
Cykliczne agregacje danych mają sens wtedy, gdy dane wejściowe albo wyjściowe będą się do tego nadawały.
Weźmy przykład z Mirko. Zakładając że masz tabele userów, wpisów i plusów, która zawiera id wpisu i id usera, robisz zapytanie do plusów o X wpisów z największą ich liczbą. Utrwalasz wtedy np. datę wygenerowania danej, id wpisu, liczbę plusów. Taka dzienna

[kaczors]

@mk321: Dwa słowa wstępu odnośnie Spark.
Spark to nie jest jakieś magiczne narzędzie, które potrafi samo coś mądrego policzyć. Siłą Sparka jest to, że potrafi rozdystrybuować zadania na X nodów, całkiem dynamicznie i szybko. No ale po co ten Spark? Tutaj, moim zdaniem kluczowe są:
- zdolność obsługi dużej ilości danych, bez struktury. Tu właśnie wchodzi hdfs (i różne jego odpowiedniki jak s3, gs). Wyobraź sobie, że masz logi aplikacji w