BigData - Hadoop/HDFS, InputSplit, logiczne rekordy na więcej niż 2 blokach

W ramach postanowień noworocznych zacząłem dokształcać się z przetwarzania big data i gdzieś tam z tyłu głowy zrodziło się pytanie dotyczące Hadoopowego InputSplita. HDFSowe bloki danych mają domyślny rozmiar, np. 128MB. Może się zdarzyć, że część logicznego rekordu zostanie rozsmarowana na 2 blokach i to jest dość typowy przypadek.

Czy spotkał się ktoś w praktyce z sytuacją, gzie logiczny rekord z pliku zajmuje więcej niż 2 bloki HDFsowe? Jeśli tak, to czy może opisać czego dotyczyło przetwarzanie?

Dawno nie tykałem hdfsa ale jak dobrze pamiętam to hdfs trzyma dane w piłkach i bez znaczenia w ilu blokach będzie

UglyMan napisał(a):

Dawno nie tykałem hdfsa ale jak dobrze pamiętam to hdfs trzyma dane w piłkach i bez znaczenia w ilu blokach będzie

Techniczna strona jest jasna, bo to przykrywają InputFormaty. Konkretny InputFormat wie jak podzielić na InputSplity i logiczne rekordy. Wydaje mi się, że ilość bloków ma znaczenie, gdy okazuje się, że ilosć RAMu jest zbyt mała, żeby taki logiczny rekord załadować i przetworzyć, ale to tylko drobna uwaga.

Dla przykładu, jeśli na HDFSa wrzucimy 50GB plik z ripem filmu z BluRaya, to jako film może być niepodzielnym rekordem, ale możemy przecież mieć logiczny rekord zdefiniowany inaczej, np. jako "klatka filmu", "5 sekund filmu" i adekwatnie możemy utworzyć własne InputFormttery, RecordReadry itp.

Jeśli ktoś pracuje X czasu przy BigData, to może spotkał się z takim przypadkiem, że "niestety, nasz unit of work to było 1/2/5/10/100/...GB i nie dało się tego podzielić na mniejsze, a przetwarzaliśmy tak i tak". I o taki przypadek z życia pytam, z czystej ciekawości by mieć jakieś odniesienie. Może nikt się nie spotkał z czymś takim, a zaczynał pracę w big data przed pojawieniem się programistów cobola ;-)
To też jakaś informacja.