Анализ гигабайтов данных (проблемы и решения)

[neg_lib]

Данные = Знание (куда не посмотри везде Интеграл Гаусса)

https://www.youtube.com/watch?v=X_SIMMqPzsc

[matemat]

rockclimber в сообщении #1193170 писал(а):

Зависит от толщины прослойки между тем, с чем вы работаете, и СУБД. Возможно, поможет. Писать более оптимальный код извлечения данных, кэшировать результаты, выполнять часть расчетов силами СУБД. Например, если вам надо рассчитать среднее арифметическое по данным из столбца, вы можете написать ...

А как с помощью SQL рассчитать распределение хи-квадрат, выделить главные компоненты, построить ROC-кривую, кореллограмму и т.д.?

[rockclimber]

Еще б я знал, как их вообще посчитать. Ну ок, допустим, хи-квадрат я даже когда-то считал в институте, и могу вспомнить, как называется книжка с формулами. А вот главные компоненты и ROC-кривая прошли мимо меня.
Теперь по существу. Хи-квадрат, если я правильно помню, считается для набора чисел. То есть на входе - набор чисел, на выходе - одно число. Расскажу опять же применительно к ораклу.
Во-первых, там есть куча готовых агрегатных функций: https://docs.oracle.com/database/121/SQ ... SQLRF20035 Я в деталях не знаю, какая что из них считает, плюс не факт, что то, что у нас называется хи-квадрат, у них называется так же. Может, уже все давно готово.
Во-вторых, если у нас все еще оракл, можно написать свою агрегатную функцию. Тогда, допустим, у нас в таблице MY_TABLE есть столбец VALUE, для собственно расчета достаточно будет написать (после того, как вы написали вашу агрегатную функцию, конечно же)

Используется синтаксис SQL

SELECT my_hi_kvardat_function(VALUE) FROM my_table

вы получите ваш хи-квадрат. Теперь допустим, у вас в таблице данные нескольких экспериментов (поле experiment_number - номер эксперимента), и надо посчитать хи-квадрат для каждого эксперимента отдельно:

Используется синтаксис SQL

SELECT experiment_number, my_hi_kvardat_function(VALUE) 
FROM my_table
GROUP BY experiment_number

Вы получите список номеров экспериментов и хи-квадрат для каждого. И так далее.
Ну и просто пару примеров на SQL (таблица та же). Посчитать среднее для каждого эксперимента:

Используется синтаксис SQL

SELECT experiment_number, avg(VALUE) 
FROM my_table
GROUP BY experiment_number

Посчитать разницу между текущим значением и средним в эксперименте:

Используется синтаксис SQL

SELECT experiment_number, VALUE - avg(VALUE) OVER (partition BY experiment_number)
FROM my_table

Среднеквадратичное отклонение:

Используется синтаксис SQL

SELECT experiment_number, SUM(POWER(VALUE - avg(VALUE) OVER (partition BY experiment_number), 2)) / COUNT(*)
FROM my_table
GROUP BY experiment_number

А вообще, как выучите SQL (он реально простой, через пару месяцев будете уже колбасить запросы по 10 - 15 тысяч символов длиной), так и сами поймете, как вам лучше считать.

[neg_lib]

http://oracle-big-data.blogspot.ru - тут, много полезной информации.

Как, я понял, если у Oracle не хватает средств для анализа, то он применяет R.
Но, в R в основном стат. анализ, вейвлетов в нем нет, в Python богаче библиотеки.

Вопрос.

Я для профилирования клиентов применяю https://smartbear.com/product/aqtime-pro/overview/

А, чем подобным можно профилировать Oracle пакеты?

[rockclimber]

neg_lib в сообщении #1193239 писал(а):

А чем подобным можно профилировать Oracle?

Oracle Enterprise Manager
Но это для богатых. Для бедных есть системные вьюхи, онлайн-документация, explain plan, пакет dbms_profiler, трассировки сессий и что-то там еще было, все и не упомнишь.

-- 17.02.2017, 00:23 --

matemat в сообщении #1193166 писал(а):

Действительно я даже и не знаю какая в компании СУБД. А мне надо знать, поможет?

Забыл совсем одну штуку, а она тем временем очень может пригодиться.
У оракла есть такая штука, как хинты (про аналоги у конкурентов ничего не знаю, но это не значит, что аналогов нет). Хинт - это комментарий в запросе, написанный по определенным правилам. Это указание СУБД, как выполнять запрос. Хинтов много разных для разных случаев, но я хотел рассказать про тот, который вам будет наиболее интересен, как мне кажется. Это хинт PARALLEL, его использование выглядит так:

Используется синтаксис SQL

SELECT /*+ PARALLEL(4) */ <список полей>
FROM   <список таблиц>

Такая конструкция заставит СУБД выполнять запрос в четыре потока. При наличии соответствующего количества процессоров (и прав на многопоточное выполнение) данная операция вполне имеет смысл.

[neg_lib]

Цитата:

Для бедных есть системные вьюхи, онлайн-документация, explain plan, пакет dbms_profiler, трассировки сессий и что-то там еще было, все и не упомнишь.

А типа TOAD, но с профайлером, чтобы удобно и графически анализировать?
Не мучиться, не ковыряться в системных запросах и не смотреть на логи.
Оболочка, которая скроет весь мусор с глаз и избавит от ненужных знаний.
Которыми гордятся DBA
Просто, чтобы разработал и проанализировал узкие места, как в Aqtime

Сейчас везде хотят от разработчиков знаний DBA.
У разработчиков спрашивают про партиции
И рассказывают, разработчику о том, как они помогли, что теперь стало быстрее.

Говорят не про схемы, не про алгоритмы, а про хинты, индексы итд (временно решают проблему, откладывают ее)

Во всех книгах пишут, что надо алгоритмы менять - это помогает.

Я вот, рад, что нашел системную таблицу https://docs.oracle.com/cd/B19306_01/se ... m#i1588578
легко находить коды во всем проекте
может, для профилирования есть подобное

SELECT *
FROM ALL_SOURCE
WHERE upper(text) LIKE upper('%loc_work_get_open%');


-- просмотр всех джобов
select * from all_jobs t where t.what like '%ocs.ins_period_albert_jam%'


Не понимаю почему так делают.

[neg_lib]

https://iusoltsev.wordpress.com/profile ... tatistics/ - тут, много всякого, но мне надо просто посмотреть, где тормозит
в пакете(номер строки).
Может ткнете, где это найти. Или порядок действий(скрипты, которые все сделают сами).

https://iusoltsev.wordpress.com/2011/11 ... bms_hprof/ - что-то нашел, вроде.

[matemat]

Скажу еще вот что.
Мне по большей части приходится иметь дело с данными из журналов событий. Вам хорошо, у вас всё в ровненьких таблицах БД лежит. Мой источник данных - зашумленные лог-файлы. Файлов таких много, разной природы и структуры. Только за один день в компании может накапливается несколько миллионов лог-файлов. В одном файле может быть несколько миллионов записей/строк разной длины и содержания.
Так вот, чтобы иметь возможность провести анализ данных, нужно выполнить можно сказать почти что вручную много предварительной работы. Например, руководителей интересует частотное распределение определенных событий. Приходиться или парсить или грепать (чего особо не умею) файлы, потом это все еще агрегировать, если данные нужны за неделю/месяц/квартал ... Причем вся эта работа почему-то перекладывается на математика/аналитика.
Интересно, какие инструменты или системы позволяют хранить и обрабатывать логи с целью data analysis/mining?

[neg_lib]

Опять засада, в этой туле нужно иметь доступ к каталогам на сервере.
Ладно, в баню, буду по старинке ремачить код и щупать руками.

Никакого прогресса.

[rockclimber]

matemat в сообщении #1193261 писал(а):

Интересно, какие инструменты или системы позволяют хранить и обрабатывать логи с целью data analysis/mining?

Странно, мне показалось, что ваш стартап как раз и разрабатывает такие инструменты. Но я еще у своего родственника спрошу, вдруг это его стартап этим занимается.

matemat в сообщении #1193261 писал(а):

Только за один день в компании может накапливается несколько миллионов лог-файлов. В одном файле может быть несколько миллионов записей/строк разной длины и содержания.

Ничего не путаете? Если даже одна строка будет состоять из 1 символа, это 1 ТБ в день. А символов будет как минимум два (1 просто символ, второй - перенос строки).

neg_lib в сообщении #1193248 писал(а):

Сейчас везде хотят от разработчиков знаний DBA.
У разработчиков спрашивают про партиции
И рассказывают, разработчику о том, как они помогли, что теперь стало быстрее.

Говорят не про схемы, не про алгоритмы, а про хинты, индексы итд (временно решают проблему, откладывают ее)

И вы пришли искать у меня понимания, защиты и слов поддержки? Бесполезно, я тоже считаю, что разработчику надо знать про хинты, индексы и партиции. Тем более что знать там надо не так уж и много. И вообще, лучше знать больше, чем меньше.

neg_lib в сообщении #1193248 писал(а):

А типа TOAD, но с профайлером, чтобы удобно и графически анализировать?

Я ж говорю - Oracle Enterprise Manager. Удобно и графически. Погуглите скриншоты.

neg_lib в сообщении #1193248 писал(а):

Во всех книгах пишут, что надо алгоритмы менять - это помогает.

В каких книгах? SQL - это вообще не про алгоритмы. Алгоритмы - это в императивных языках, где вы указываете процессору: возьми байт отсюда, сложи с тем байтом, положи туда. SQL - декларативный язык, вы на нем описываете, как должен выглядеть результат, а способ получения этого результата (какие байты откуда брать, куда и как перекладывать) СУБД выбирает без вашего участия. PL/SQL - это, конечно, императивный язык, но в нем обычно тормозят SQL-запросы.

neg_lib в сообщении #1193248 писал(а):

Я вот, рад, что нашел системную таблицу https://docs.oracle.com/cd/B19306_01/se ... m#i1588578
легко находить коды во всем проекте
может, для профилирования есть подобное

SELECT *
FROM ALL_SOURCE
WHERE upper(text) LIKE upper('%loc_work_get_open%');

Искать текст в исходниках может любая нормальная IDE, главное нагуглить, где там эта функция запрятана.

neg_lib в сообщении #1193259 писал(а):

Может ткнете, где это найти. Или порядок действий(скрипты, которые все сделают сами).

Берете SID вашей тормозящей сессии, смотрите в v$session какой запрос в данный момент выполняется (поле sql_id), потом смотрите в v$sql его текст, потом смотрите его план. Общая схема примерно такая. Это конечно при условии отсутствия детских ошибок (вы не используете EXECUTE IMMEDIATE всуе и без параметров, не используете for .. loop там где можно нужно использовать forall и т. д.).

[matemat]

rockclimber в сообщении #1193309 писал(а):

Странно, мне показалось, что ваш стартап как раз и разрабатывает такие инструменты. Но я еще у своего родственника спрошу, вдруг это его стартап этим занимается.

Нет, компания разрабатывает и поддерживает АйТи продукты/сервисы. За время работы накопилось много информации, в том числе в виде файлов на жестких дисках. Компания в целом не стартап. Стартап заключается в самом направлении big data, data mining. До этого никто особо этим не занимался, файлы просто валялись без дела.

Странно, но я думал, что вы знаете про такие инструменты/системы, может быть есть какая-то подсистема log-OLAP?

rockclimber в сообщении #1193309 писал(а):

Ничего не путаете? Если даже одна строка будет состоять из 1 символа, это 1 ТБ в день. А символов будет как минимум два (1 просто символ, второй - перенос строки).

Вам как АйТи-специалисту думаю должно быть стыдно утверждать такие вещи. Можно привести пример файлов размеров не более нескольких Мбайт, которые содержат 1M+ строк одного символа. Какие Тб в день, о чем это вы? В общем да, но не один же файл!

[mustitz]

matemat в сообщении #1192530 писал(а):

Мне выгрузили из базы данных несколько десятков файлов, каждый размером не менее 1 Гб. Один файл (который кое как мучительно долго загрузился в R) представляет из себя более 10 млн. наблюдений (записей/строк) по 7-10 переменных. Практически, такой объем данных парализовал всю мою работу.

Я вроде не нашёл самого простого решения — увеличить размер оперативной памяти. Поставить 64G в общем-то на сегодня не сложно. Asus X99-WS/IPMI поддерживает 128G. Читай 50-100 файлов по гигу поместятся в памяти без проблем. Да и обычный своп, который можно поставить на один из SSD (+256G) может выручить, на другой систему.

Считаем, материнка 15000₴, память 15000-30000₴, SSD 5000₴ итого бюджет до 50000₴ ($2000), что меньше затрат на одного специалиста в месяц.

[Dmitriy40]

rockclimber в сообщении #1193309 писал(а):

matemat в сообщении #1193261 писал(а):

Только за один день в компании может накапливается несколько миллионов лог-файлов. В одном файле может быть несколько миллионов записей/строк разной длины и содержания.

Ничего не путаете? Если даже одна строка будет состоять из 1 символа, это 1 ТБ в день. А символов будет как минимум два (1 просто символ, второй - перенос строки).

Думаю тут указаны верхние пределы, а основное количество файлов будет сильно (на порядки) меньше, да и самих файлов обычно тоже не будет миллионы ежедневно. Так что обойдётся сотнями мегабайтов (плюс-минус порядок) в день.

[neg_lib]

rockclimber в сообщении #1193309 писал(а):

В каких книгах? SQL - это вообще не про алгоритмы.

https://www.ozon.ru/context/detail/id/4491539/ - таких много книг

Хинты применять не рекомендуют, система сама должна подбирать план.

Хинт помогает поменять алгоритм выполнения.

http://neerc.secna.ru/Algor/algo_base_ds_hashtab.html - это часто применяют итд

Я на них(хеш-таблицы) ускорил с 20 мин до 20 сек приложение

[rockclimber]

matemat в сообщении #1193317 писал(а):

Странно, но я думал, что вы знаете про такие инструменты/системы, может быть есть какая-то подсистема log-OLAP?

Нет, не знаю, но они точно есть. Жена рассказывала буквально месяц назад про такую систему, которая используется в ее конторе, но я не помню название. Попробуйте пока просто погуглить "анализ логов".

(Оффтоп)

А тот вышеупомянутый родственник даже пытался меня подбить организовать свой стартап по разработке такого инструмента. Года четыре назад где-то. Наверно, надо было соглашаться.

Еще есть продукты категории IN-MEMORY DB (гуглите), они разные бывают, и SQL, и NoSQL.
У меня (еще раз повторю) немного другой профиль и область интересов. Если бы такую задачу дали мне сейчас, я бы решал ее с помощью SQL инструментов, в соответствии с принципом "используй то, чем лучше всего владеешь". Но, поскольку есть еще принцип "человек, владеющий молотком, в любой задаче видит гвоздь", я так скажу: если вы попросите порекламировать среди вас SQL и инструменты для работы с ним - всегда пожалуйста, а если вопрос стоит как "а что еще есть для дата-майнинга" - я уже рассказал все, что знал, дальше в сторонке постою и послушаю.

matemat в сообщении #1193317 писал(а):

Вам как АйТи-специалисту думаю должно быть стыдно утверждать такие вещи. Можно привести пример файлов размеров не более нескольких Мбайт, которые содержат 1M+ строк одного символа. Какие Тб в день, о чем это вы? В общем да, но не один же файл!

А я и не говорил, что один файл. Вы сказали - "миллион файлов по миллиону строк". Я перемножил и получил триллион строк, если одна строка длиной 1 символ - это 1ТБ логов в день.

Dmitriy40 в сообщении #1193325 писал(а):

Так что обойдётся сотнями мегабайтов (плюс-минус порядок) в день.

Ну так и надо писать - "порядка сотен мегабайт в день". А еще лучше взять данные за год и усреднить.