Автор Тема: хранилища за данни  (Прочетена 3326 пъти)

villimon

  • Напреднали
  • *****
  • Публикации: 65
    • Профил
хранилища за данни
« -: Mar 12, 2015, 08:00 »
Здравейте не съм убеден че темата е за тази категория. Моля да ме извините предварително. Реших да пиша защото ме глождят разни "лоши мисли" ако се намерят добри хора да ми помогнат с изчистването на концепциите ще съм благодарен.

По същина, не знам до колко е говорещо заглавието въпроса ми е свързан със "Data Warehouse", "Data mining" и "OLAP" системи.

До момента съм открил множество решения свързани със релационни бази от данни предполагам, че това тенденцията на развитие.

Но цялата идея, че имам n на брой хранилища който се обединяват в един "Data Warehouse" където нормализации не са задължителни, повтаряемостта на данните не е порок.

Се сещам за "Big Table", "NoSQL", "Graph Database"

Не забравям че се търси скорост на обработка, анализиране на данните и подобни неща.

Но "NoSQL" решения не са ли възможни?
Има ли някакви разработки в тази насока?
Активен

romeo_ninov

  • Напреднали
  • *****
  • Публикации: 2155
    • Профил
Re: хранилища за данни
« Отговор #1 -: Mar 12, 2015, 10:48 »
Възможни са два пътя:
1. комерсиално DWH решение (Оракъл, ИБМ), хардуерно или софтуерно
2. нещо безплатно, базирано на NoSQL/Hadoop, само че си иска и хардуера за да може консолидирането и агрегирането да станат в приемливо време

Но конкретното решение зависи от конкретния проблем
Активен

0x2B|~0x2B

villimon

  • Напреднали
  • *****
  • Публикации: 65
    • Профил
Re: хранилища за данни
« Отговор #2 -: Mar 12, 2015, 20:31 »
Можеш ли да дадеш малко повече информация, някоя статия по темата?
При какви ситуации какво може да се използва.
Някакви примери ?
Активен

sharena_sol

  • Гост
Re: хранилища за данни
« Отговор #3 -: Mar 12, 2015, 21:01 »
My 2 cents:

Въпреки, че NoSQL е много общо понятие и различните така наречени NoSQL бази данни са най-разнообразни мисля, че една обща черта при тях е възможността за поддържнане на разпределени данни (за сметка на консистента структура). Това ги прави подходящи за съхранение на данни за приложения работещи в интернет с огромно количество потребители от различни точки на света и голямо натоварване, което може да се разпредели на множество сървари, но за сравнително прости приложения.

От друга страна DWH системи обикновено се внедрявад за сложни бизнес приложения (с брой потребители много по-малък от този на facebook примерно) но с много по сложна схема. Такива OLTP приложения (чиито данни ще налееш в DWH) обикновено ползват релационни данни и най-естественото нещо при ETL от такива он-лайн бази данни към DWH е да продължиш да ползваш релационна база данни.

И докато OLTP приложенията имат сравнително малко на брой потребители, то OLAP/data mining приложениято, които ще работят върху извлечените в DWH кубове и т.н. имат даже още по-малко наброй потребители - някой друг анализатор, разработчик на репорти за някой мениджър и толкова. Така че основната полза от NoSQL - разпределението на данните се губи тотално, макар че си прав че и недостатъкът им също става малко по-нерелевантен защото DWH са крайно денормализирани.

Обаче незнам с тия NoSQL системи какви заявки би могъл да правиш освен примерно прости key-value look-ups. Не съм експерт там но можеш ли да правиш group by или sum(x) over (partition by y,z) или grouping sets, cube etc.

Да не говорим че DWH съществуват от сто години и има една камара tool-ове, а NoSQL има кажи речи от както смартфоните се появиха и има милионите им невиждали интернет дотогава потребители имат нужда някъде да си запишат highscore-овете на plants vs zombies.

Виж за hadoop незнам. Имам бегли спомени че съм чел че се ползва за web mining, но това е различно от data mining, както google заявка e различно от SQL заявка.
Активен

villimon

  • Напреднали
  • *****
  • Публикации: 65
    • Профил
Re: хранилища за данни
« Отговор #4 -: Mar 13, 2015, 08:11 »
sharena_sol напълно съм съгласен релационните бази данни ги има далеч преди "NoSQL".

В DWH имам огромни масиви от данни, които искам да обработвам по някакви вероятностни алгоритми, за да се направи в крайна сметка анализ за развитието на бизнеса.

Затова си мисля, че система позволяваща сравнително бързо четене на данните с минимално или по възможност никакво преобразуване към обекти и използването на оптимални структури от данни, естествено за сметка на памет, може да намали времето за изчисления.

По скоро си мисля за Граф базите данни от колкото за ключ-стойност.

Търсещата машина на Google работи доста бързо, мисля че не ползва класически релационни бази. Наистина бизнеса и в частност банковия е много чувствителен към промени и там нещо такова на дали ще бъде прието и приложимо но може другаде да върши работа.
Активен

romeo_ninov

  • Напреднали
  • *****
  • Публикации: 2155
    • Профил
Re: хранилища за данни
« Отговор #5 -: Mar 13, 2015, 15:50 »
sharena_sol напълно съм съгласен релационните бази данни ги има далеч преди "NoSQL".

В DWH имам огромни масиви от данни, които искам да обработвам по някакви вероятностни алгоритми, за да се направи в крайна сметка анализ за развитието на бизнеса.

Затова си мисля, че система позволяваща сравнително бързо четене на данните с минимално или по възможност никакво преобразуване към обекти и използването на оптимални структури от данни, естествено за сметка на памет, може да намали времето за изчисления.

По скоро си мисля за Граф базите данни от колкото за ключ-стойност.

Търсещата машина на Google работи доста бързо, мисля че не ползва класически релационни бази. Наистина бизнеса и в частност банковия е много чувствителен към промени и там нещо такова на дали ще бъде прието и приложимо но може другаде да върши работа.
За бизнес анализи обикновено се ползват агрегиращи функции, които не са толкова бързи при граф базите. един хадууп се справя по-добре (според мен)
Активен

0x2B|~0x2B

sharena_sol

  • Гост
Re: хранилища за данни
« Отговор #6 -: Mar 13, 2015, 16:07 »
Значи не съм никакъв DWH експерт но от общат култура долу горе представата ми за стуктурите и таблиците на DWH система ти дават възможност да правиш различни изгледи върху събраните данни - примерно да групираш бързо по нещо и т.н.

Machine Learning обикновено работи върху някакъв плосък dataset. Моделът който ще обучаваш има някакви параметри и трябва да обходиш целия dataset за да ги fit-неш. Така че нямаш никаква полза този dataset да го държиш в каквато и да е база данни, още по-малко пък graph. Този dataset е само един изглед от всички възможни, които DWH ти дава възможност да правиш. Запази този изглед във един CSV файл или в какъвто формат machine learning tool-a или MATLAB или каквото там ползваш за статистически модел приема. И от това по-бързо няма, защото така или иначе трябва да го обходиш целия - всички datapoints/редове, А всеки ред ще съдържа feature-ите които са ти нужни за обучение на модел, бил той linear regression или невронна мрежа или квото там си си избрал или измислил сам. Генерираш ли си подходящия dataset, бази данни не са ти нужни.

Добре има по-бързо и от това, и това е ако моделът ти позволява да го пралелизираш с някъв map-reduce примерно, тогава hadoop може би би ти свършил работа, но отнова самите данни от dataset-a няма никакъв смисъл да седят в каквато и да е база данни. Google примерно (вероятно) ползва map-reduce за да обходи индексите си - примерно търсиш "linux", това се праща на всички сървъри и всеки от тях дава резултат спрямо документите които съхранява/индексира локално. Всички тези резултати накрая се reduce-ват централно и най-релевантните ти се връщат обратно.

Но обратно на темата - DWH свършва в момента, в който ти си решил какъв ще е статистическият модел, какви ще са feature-ите които те интересуват и какъв е обхватът на данните. Тук DWH ти дава възможност да направиш изглед на тази данни (демек таблица) да ги извлечеш и да си ги запишеш в какъвто си искаш формат - сигурно може да ги налееш и в граф база данни ма няма никакъв смисъл защото machine learning модела ти така или иначе ще ги разглежда като списък от вектори а за тази цел и CSV ти е пре-достатъчен. При дистрибутирания вариант това CSV ще го разбиеш на толкова на брой файла колкото node-ове имаш в клъстера, а при не-дистрибутирания вариант dataset-a ти ще е в един файл. Но и в двата случая тези файлове ще се обходят последователно, ред по ред, колона по колона - никакъв смисъл от база данни.

Примерно DWH може да ти съдържа информация за това колко сняг е валяло в българия:
* по градове, (number) (cm)
* по дни,  (number) (cm)
* по часове, (number) (cm)
* дали по време на валежа Бойко Борисов е давал интервю (true/false)
* колко водка към момента е изпил Волен Сидеров (number) (литри)

DWH просто ти дава възможност и удобството да правиш каквито заявки намериш за необходими от всички тези събрани данни, които да речем са събрани от 3 различни системи - метереолозите към БАН, някъв медиен мониторинг и разходите на ФСБ за руска водка предоставяна на чужди агенти.
До тук свършва ролята на DWH - да събере тези данни е подходяща структура и ти да решиш каква точно разбивка и кои точно стойности те интересуват.
Примерно решаваш че ще правиш модел който търси корелация между медиините изяви на ББ и колко общо сняг е паднал в цялата страна. Ами тогава dataset-a ти ще е нещо такова:
#date_time, snow_summed_all_cities_in_cm, is_borisov_on_air
20150101-0935, 43, true
20150101-1005, 3,   false
20150101-1035, 73, true

правиш си заявката, DWH е така добър да ти даде данните и не го интересува PDF ли ще правиш с тях, в ексел ли ще ги записваш. графики ли ще чертаеш или machine learning.

Леле оср*х се да пиша, айде стига толкова глупости от мен.
Активен

sharena_sol

  • Гост
Re: хранилища за данни
« Отговор #7 -: Mar 13, 2015, 18:26 »
Айде още малко глупости да до-уточня предните си глупости (ако сме се разбрали че за dataset-a не ти трябва база данни)

Hadoop или каквото и да е разпределено изчисление би ти свършило работа само ако имаш повече от един сървър на които да разхвърляш dataset-a. Защото основният ти bottleneck е четенето от диска. Така или иначе параметрите на статистическия модел ще се пресмятат на един компютър/процес, който просто ще получава datapoints от много места. Но не всички статистически модели са подходящи - т.е. трябва да няма значение последователността на (векторите с feature-и)/datapoints така че всеки сървър, който чете неговата порция от dataset-a и ги праща към компютъра, който пресмята модела, да ги праща свободно когато са му налични.
  Но ако примерно моделът ти зависи от последователността на постъпване на данните, примерно http://en.wikipedia.org/wiki/Recurrent_neural_network тогава незнам дали можеш да го паралелизираш изобщо. Добре де - може, но не тривиално
Активен

villimon

  • Напреднали
  • *****
  • Публикации: 65
    • Профил
Re: хранилища за данни
« Отговор #8 -: Mar 13, 2015, 20:47 »
благодаря доста е подробно
Активен

sharena_sol

  • Гост
Re: хранилища за данни
« Отговор #9 -: Mar 14, 2015, 00:42 »
наздраве.

Още веднъж. Смисълът на DWH е да ти даде възможност да правиш разнообразни заявки над събраните данни. Ако утре искаш да изследваш корелацията на снега в Сливен и пиенето на Сидеров - правиш си заявката и DWH възможно най бързо ти дава плоския списък който след това ще моделираш. За това не са нормализирани и даже не са RDBMS даже а некви други странни кубове и нам си кви си. Но дотам - просто смисълът им е да ти дадът възможност да правиш всевъзможни разбивки, агрегации и т.н. Решиш ли какво те интересува, казваш на DWH, той ти връща данните и след това кеф ти datamining кеф ти чартове, графики ексели и репорти.

Смисълът на hadoop не е DWH а просто рамка за разпределено изчисление и туй то.
« Последна редакция: Mar 14, 2015, 02:36 от sharena_sol »
Активен

villimon

  • Напреднали
  • *****
  • Публикации: 65
    • Профил
Re: хранилища за данни
« Отговор #10 -: Apr 11, 2015, 14:37 »
Здравейте,
Попаднах на интересен проект казва се HANA който обединява скоростта за записване на данни от транслационните бази данни и скоростта за извличане на данни от хранилището за данни. Като поддържа данните на едно място подредени в колони а не като в класическите СУБД на редове, ползва алгоритми за криптиране като обединяване на еднаквите поредни записи, ползването на числови типове за по бързи операции и различни известни оптимизации. Но събрани на едно място работят добре.

Не съм специалист просто ми се стори интересно.
Активен