Функцію reduce можна вважати узагальненням агрегатної функції в SQL. Виходить, що аналітик при написанні нової аналітичної функції не зобов'язаний виходити за межі того набору понять, до якого він звик, працюючи з традиційною аналітичної СУБД.
Створюється враження, що підтримка MapReduce всередині паралельної аналітичної СУБД повинна повністю задовольнити потреби аналітиків, а майбутні аналітичні додатки стануть серверними, виконуваними паралельно поблизу від своїх даних. Все це означає, що може бути забезпечена горизонтальна масштабованість майбутніх аналітичних систем і тим самим вирішена і проблема Великих Даних. Однак тут хочеться зробити крамольне зауваження. Фактично в новому поколінні аналітичних паралельних СУБД забезпечується можливість паралельного програмування аналітичних додатків, яке простіше і зрозуміліше для непідготовлених фахівців. Тобто частково вирішується більш загальна проблема - проблема паралельного програмування для суперкомп'ютерів. Виникає питання, а не чи заслуговує цей підхід більш широкого застосування, ніж розширення аналітичного паралельного сервера баз даних? Чи не варто спробувати застосовувати MapReduce для програмування паралельних задач обробки великих обсягів даних? Дійсно, Великі Дані безглузді без великих обчислень, а великі обчислення найчастіше неможливі без підтримки ефективного доступу до Великим Даним. Чи не варто про це замислитися?
Список літератури
Для підготовки даної роботи були використані матеріали з сайту masters.donntu.edu/
Дата додавання: 26.01.2014
