Opowiadając o czymś na wykładach, często używam porównań pewnych abstrakcji zapisanych w programie to pojęć znanych z codziennego życia. To pozwala łatwiej zrozumieć i wyrobić sobie odpowiednie intuicje, które potem, a w zasadzie ich znajdowanie, będą konieczne w przyszłej pracy programisty. Ostatnio zacząłem się zastanawiać, do czego można porównać cały program – czyli całość przetwarzania danych które oferuje. Wystarczy zamienić słowo „dane” na „dokumenty”, by stało się niemal oczywiste, że przetwarzanie danych, przypomina to co dzieje się w urzędach przez które przepływają dokumenty. Dane mogą się pojawić, i powinniśmy na nie jakoś zareagować. Na przykład je zmienić – jak w przypadku podań, wcześniej sprawdzając czy mają wszystkie potrzebne załączniki i w zależności od rodzaju i wagi problemu – kierowane są do odpowiedniej akceptacji lub dalszego rozpatrywania po uzyskaniu opinii. Mamy tu też dane sterujące – okólniki a nawet stan układu lub podukładu w postaci regulaminów (zmienianych okólnikami).

Jeśli przyjrzymy się pracy pojedynczego urzędnika – możemy określić listę czynności którą musi wykonać. Lista ta jest zgodna z odpowiednia procedurą która określa co po kolei trzeba zrobić. To jest jakby program który realizuje urzędnik. Lista akcji, polegających na modyfikacjach dokumentu. Modyfikacji które mogą wymagać także innych operacji – jak na przykład telefonu do banku czy urzędu skarbowego by sprawdzić jakie procedury należy dalej wykonać. Dokładnie tak działa program, pod warunkiem, że jest stosunkowo prosty.

Tymczasem jeśli popatrzymy na urząd jako na całość, to co prawda, na poziomie pojedynczego urzędnika, możemy podać jakie na swoim stanowisku ma wykonać czynności i powinien je wykonać na każdym powierzonym dokumencie w miarę sprawnie, o tyle w przypadku całego urzędu – jest to nieco bardzo skomplikowane. Jeśli interesuje nas wydajność urzędu, to mniej istotny staje się średni czas przetwarzania pojedynczego dokumentu (choć to interesuje niewątpliwie jego adresata). Tu dobrym wyznacznikiem pracy – jest ilość przetworzonych dokumentów w jednostce czasu a na to łatwiej jest patrzeć od strony danych. I dróg ich przetwarzania.

Czy to nie to samo? W końcu i tak na końcu znajduje się procesor realizujący po kolei otrzymane instrukcje. Cóż. Hulk Hogan i Natalie Portman – to też na poziomie atomowym – niemal to samo.

Spojrzenie od strony data-flow{-> ang. Przepływ danych, w odróżnieniu od control-flow – przepływy instrukcji, polega na opisywaniu jak po kolei przetwarzana jest każda dana, a nie jakie po kolei wykonujemy czynności z danymi. jest tylko innym spojrzeniem na proces przetwarzania. Spojrzeniem dobrym do ogólnego opisu, bo na poziomie samej modyfikacji – tam gdzie nie wystarczą formuły – control flow jest po prostu najbardziej czytelny. Tu możemy na przykład dostrzec możliwości optymalizacji poprzez zrównoleglenia przetwarzania. To cenne, bo współczesne komputery mogą mieć wiele jednostek centralnych które warte są wykorzystania.

Data-flow przedstawiany jest zazwyczaj w formie diagramów, pozwalając, podobnie jak to jest w przypadku diagramów blokowych przedstawiających algorytmy, na pokazanie różnych dróg przetwarzania. Z tą różnicą, że pokazuje on co się dzieje z określonym dokumentem.

Do takiego przetwarzania danych w komputerze, potrzebujemy odpowiedniego procesora – zrealizowanego w postaci maszyny wirtualnej. Maszyny dla której pojedynczymi operacjami będą operacje na pojedynczym dokumencie¹. Jeśli dokumenty są niezależne – to bez problemu możemy zrównoleglić operacje przetwarzając jednocześnie wiele dokumentów, może nawet na wielu oddzielnych maszynach przesyłających sobie pracę poprzez sieć. Można nawet w czasie szczytów obłożenia – dokupować moc obliczeniową w chmurze, by za własne serwery nie przepłacać.

Maszyna działa według dość prostego programu. Bierzemy daną, patrzymy co z nią trzeba zrobić, i to robimy. Rezultat odkładamy do dalszego przetwarzania.

Dane, to lista spraw do zrobienia.

Proste?

Ale czy nie prościej jest po prostu brać każdą daną po kolei i przetwarzać od początku do końca?

Każda informacja wchodząca do systemu – jest na początku opisywana listą spraw do załatwienia – czyli listą procedur jakie, pracując nad nią, trzeba wykonać. Danych nie kopiujemy – tylko modyfikujemy. Możemy to zrobić bezpiecznie, bo maszyna wirtualna zapewnia, że nad pojedynczą daną wykonywana jest co najwyżej jedna procedura. Możemy je jednak niszczyć i tworzyć, w miarę potrzeb generując na przykład zbiory danych.

Śledzenie co się dzieje w takim natłoku danych i jednoczesnego przetwarzania nie jest łatwe, a pamiętajmy, że programiści, oprócz pisania programów muszą także analizować ich działanie – i to analizować czytając logi. Może wiec zwiążemy log z każdą daną? Czytanie tego będzie na pewno prostsze niż czytanie o wszystkich zdarzeniach w systemie w kolejności ich wystąpienia. Przetwarzanie danych może zmieniać stan systemu. Jego modyfikacje musimy trzymać w oddzielnym logu, który oglądany razem z logiem dokumentu przyniesie potrzebne informacje.

Skomplikowane?

Na pierwszy rzut oka – na pewno nie. Ot – zamiast wszystkimi danymi zajmujemy się pojedynczym dokumentem przetwarzając go od początku do końca, a gdzieś tam w głębi maszynowych trzewi siedzi demon – machina virtualna, który robi co może by mając tylko kilka procesorów przetwarza wszystkie na raz, to znaczy po kolei, ale po kolei po kawałku – czyli na raz. Jednak i tu mamy do czynienia z problemami synchronizacji, które realizuje się przy użyciu barier.

I znów warto zadać pytanie – czy nie prościej i nawet szybciej nie dałoby się przetwarzać tych informacji od początku do końca i po kolei?

W większości przypadków – można by. Ale jest taka szczególna klasa problemów, w których mogłoby to doprowadzić do problemów z wydajnością. Co by się stało, gdyby maszyna która ma cztery potoki przetwarzania dostała najpierw cztery bardzo długie zadania, a potem setki krótkich, które można by wykonać od razu i o nich zapomnieć. A tak – czekają. Nawet jeśli pojawi się jakiś problem priorytetowy, to do końca przetwarzania, żaden z procesorów nie będzie mógł go podjąć. A to może stanowić problem.

Data-flow sprawdza się także wszędzie tam, gdzie większe dane mogą być przetwarzane równolegle po podzieleniu ich na pakiet mniejszych danych i po ponownym połączeniu. Na tej zasadzie działa Hdup – w którym data-flow składa się z jedynie dwóch różnych operacji – mapowania czyli modyfikacji wartości i struktury pojedynczej danej, oraz redukcji – polegającej na zmniejszeniu liczby danych.

Dlaczego więc tego typu przetwarzanie nie zyskało na popularności? Bo, stworzone do rozwiązań architektonicznych, do programowania na poziomie businessu, poprzez łatwe modelowanie na komputerze działającej i sprawdzonej metody – tego jak robią to ludzie.

Ale architektami zostają programiści wyuczeni na procedurach, nie rozumiejący idei data-flowu.

Na pewno jednak warto zmierzyć się z tym sposobem przetwarzania, by potem umieć go dostrzec zarówno w problemach, jak i w ich rozwiązaniach. Na przykład w architekturze SOA.