Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
kDnZP
Member [заблокирован]

Откуда: ★[msg=16399436]★[msg=20850760]
Сообщений: 11289
Maxx
Пища для размышлений

Кстати, сходил по ссылке и вспомнил... На течдейс вроде вебкасты были по SSIS, сейчас искать лень, но может ТС будет интересно поглядеть.
6 июл 11, 15:57    [10933344]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
[quot delpasso]
DeColo®es
Хм. Забавно.
А какой производительности добились, если не секрет?
В колличестве вставленных строк нет смысла наверно мерять.
У нас порядка 400 столбцов и данные достаточно дыряво распределены между ними.
Если мерять скажем в МегаБайт/секунду?
Ну, у нас производительность не такая большая - мы на загрузку 6 ГБ исходных данных (это файлы трасс сервера, 66 столбцов) тратим 45 минут.
Но на выходе у нас не только сама трасса (~5М строк), но и "проиндексированное" текстовое поле - а это уже более 100М строк в таблице индекса.
То есть мы пишем в 2 Bulk потока - исходные данные + "индекс".

В любом случае, на чтение и обработку данных уходит большая часть времени - до перехода на Bulk время загрузки было полтора-два часа и больше.
6 июл 11, 16:16    [10933549]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
delpasso
Member

Откуда:
Сообщений: 77
mike909
1.1. Есть ли в них дубляж от которого нужно избавляться ?

дупликатов нет. чистые данные.
mike909
1.2. Есть ли вероятность/необходимость перезагрузки данных в хранилище ?

нет. разве только на нашей стороне будет ошибка.
mike909
2. Нужна ли какая либо дополнительная обработка данных (агрегация, дополнение иной информацией (OnLine Billing) ) ?

определенные агрегаты будут строится примерно каждый час. где-то 7000+ точек в год.
mike909
3. Что бы это значило ? Варианты ответа:
3.2. Эти 400 столбцов - Ваша попытка засунуть разные данные в некий "унифицированный" формат

это реал-тайм данные. есть порядка 40 типов сообщений. какие-то поля/тэги общие для всех. какие-то уникальны для определенного типа.
распускать их в 40 различных таргет-таблиц (каждая под свой тип) так потом их один хрен во временной ряд собирать нужно из 40 табличек.
вобщем согласен. надо посмотреть на это место внимательнее.
mike909
4. Источник данных один или их много ?

источник один громадный файл в день, но сейчас мы его распускаем самописным шредером на более мелкие куски и парсим каждый отдельно.
именуем просто определенным образом штоб сохранить порядок.
результат(CSV file) мы пока никуда не запихиваем. ни в какое хранилище.
CSV выбран как - временный формат, так каk его куда угодно засунуть можно и в SAS и в SQL и т.д.
Если окончательно решим отказатся от SQL хранилища перейдем на бинарный формат какой-то.
mike909
4.1. Если много, то можно ли раскидать по разным SQL_ям по источникам ? Это сильно усложнит бизнес-логику ?

вы имеете в виду раскидать именно по разным инстансам SQL?
а как работать потом? коннекшен строки те же...
mike909
5. За какой интервал времени нужно хранить данные в OnLine_е ?

год
mike909
5.1. OffLine_е ?

3-4 года
mike909
6. Данные нужно грузить в хранилище как можно быстрее или, например, допустима загрузка раз в сутки ?

раз в сутки, а может даже раз в неделю.
mike909
6.1. Большая чать запросов к текущим данным или к "историческим" ?

сложно сказать пока.
свежие данные (последний год) будут дергатся чаще безусловно.
исторические (3-4 года) - иногда и точечно.
6 июл 11, 18:16    [10934619]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
delpasso
Member

Откуда:
Сообщений: 77
Andrey Sribnyak
alexeyvg
пропущено...
Это один из типов физической организации таблиц. Вы бы почитали про матчасть, преждде чем советовать отказаться от сиквела :-)


Кстати есть очень классная статья по оптимизации массовой вставки. Можно начать изучение с нее. Там много дельных советов есть

http://msmvps.com/blogs/gladchenko/archive/2010/03/09/1761298.aspx

отличная статья. спасибо.
6 июл 11, 18:18    [10934636]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
delpasso
Member

Откуда:
Сообщений: 77
Maxx
Пища для размышлений

отлично. 1ТБ за 30 мин. хорошая скорость.
6 июл 11, 18:24    [10934665]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
НуДа
Guest
delpasso,

НУ да... там железно не хилое такое.
Хотя если надо, то мы за ценой не постоим... ? ;-)
6 июл 11, 18:34    [10934711]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
delpasso
Member

Откуда:
Сообщений: 77
НуДа
delpasso,

НУ да... там железно не хилое такое.
Хотя если надо, то мы за ценой не постоим... ? ;-)

ну сейчас уже вот такие есть штуки.
дорого конечно за 1.2Тб - $5000.
но быстро.
6 июл 11, 19:36    [10934969]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
delpasso
Member

Откуда:
Сообщений: 77
[quot DeColo®es]
delpasso
пропущено...
Ну, у нас производительность не такая большая - мы на загрузку 6 ГБ исходных данных (это файлы трасс сервера, 66 столбцов) тратим 45 минут.
Но на выходе у нас не только сама трасса (~5М строк), но и "проиндексированное" текстовое поле - а это уже более 100М строк в таблице индекса.
То есть мы пишем в 2 Bulk потока - исходные данные + "индекс".

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

А как вы BULKОМ в индекс файл пишите?
вы данные через свою имплементацию DataReader скармливаете BulkCopy. Отлично.
А с индексом как?
Вы свой собственный текстовый индекс строите?
6 июл 11, 21:55    [10935375]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
Andrey Sribnyak
Member

Откуда: Киев
Сообщений: 600
delpasso
ну сейчас уже вот такие есть штуки.
дорого конечно за 1.2Тб - $5000.
но быстро.


В данном случае интересней распараллеливать все потоки, каждый на свой шпиндель. (лучше меньше, но быстрей)
А такие монстры, они обычно очень тихогодные
6 июл 11, 23:06    [10935565]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2680
delpasso,

В любом случае, в этой ветке форума дадут советы по оптимизации запросов к MSSQL, но не дадут советов по принятию решения, использовать ли вообще СУБД.
7 июл 11, 00:17    [10935743]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
delpasso
Member

Откуда:
Сообщений: 77
Andrey Sribnyak
delpasso
ну сейчас уже вот такие есть штуки.
дорого конечно за 1.2Тб - $5000.
но быстро.


В данном случае интересней распараллеливать все потоки, каждый на свой шпиндель. (лучше меньше, но быстрей)
А такие монстры, они обычно очень тихогодные

этот монстр дает 1ГБ в секунду и на чтение и на запись.
в чем тихоходность-то выражается?
7 июл 11, 01:43    [10935846]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2680
delpasso
Andrey Sribnyak
В данном случае интересней распараллеливать все потоки, каждый на свой шпиндель. (лучше меньше, но быстрей)
А такие монстры, они обычно очень тихогодные

этот монстр дает 1ГБ в секунду и на чтение и на запись.
в чем тихоходность-то выражается?
Были-были исследования про распараллеливание по шпинделям силами MSSQL, а не силами контроллера.
И вроде после сложных телодвижений с настройками приходили к выводу, что параллелить лучше именно силами MSSQL...

Только вот...
Ой... СИИИИЛЬНО сомневаюсь, что одна булка в одну таблицу как-то так настроится, чтобы выиграть таким макаром )))
Так что в твоем случае - можно не слушать такие псевдорецепты по оптимизации.
7 июл 11, 01:51    [10935855]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2680
delpasso,

попробуй описать проблему еще раз, с учетом тутошних советов, но не в ветке конкретного СУБД, а в ветке того языка, на котором вы пишете.
может, там другую СУБД посоветуют, или как я, посоветуют не пожадничать на лишних 300-1000 строк кода, но сделать свой простейший, но сверхбыстрый индекс в своем, нативном формате.

P.S. Я, когда мне очень-приочень хоцца сэкономить на спичках (вызовах) - пишу структурированный код, вместо объектного.
Если нормально продумать структуру параметров - можно сэкономить вплоть до 20-30% (в случае сложных вложенных вызовов).
7 июл 11, 02:01    [10935860]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2680
delpasso,

P.P.S. Объектный код, ясен пень, отлаживать легче и проще.
И сам исходный код лаконичнее. (чего не сказать о ассемблере, в который его компайлер превращает).
Структурное программирование, по мнению многих (ну или некоторых) - себя изжило.
Но пока у нас процессоры не "объектные" - в общем случае, объектный код будет работать медленнее структурного.
7 июл 11, 02:18    [10935878]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31984
delpasso
этот монстр дает 1ГБ в секунду и на чтение и на запись.
в чем тихоходность-то выражается?
Ну это же ооочень медленно.

Скорость должна быть 100 мб/с на шпиндель
7 июл 11, 08:49    [10936201]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31984
Makar4ik
delpasso,

В любом случае, в этой ветке форума дадут советы по оптимизации запросов к MSSQL, но не дадут советов по принятию решения, использовать ли вообще СУБД.
Это понятно, но нужно хоть немного узнать про сиквел, чтобы такие решения принимать.
А то если человек не знает ни про сиквел, ни про другие варианты, из чего он будет выбирать? :-)
Makar4ik
Так что в твоем случае - можно не слушать такие псевдорецепты по оптимизации.
Ну какие псевдорецепты??? Это просто стандартная практика - те, кто работает с хранилищами делают такое на автомате, как фигурные скобки расставлять в коде на C или C#

Разделение по шпинделям, перенос драйверов в близкие ядра, распаралеливание загрузки, построение индексов без использования дисков - это всё просто стандартные операции.
Вы бы, повторю, поизучали сиквел, прежде чем давать по нему советы. Смешно просто звучат ваши "открытия" :-)
7 июл 11, 08:57    [10936228]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
mike909
Member

Откуда:
Сообщений: 662
delpasso,

Что-то я перестал понимать Ваши проблемы. С чего Вы уперлись в скорость загрузки ?
Если
delpasso
mike909
6. Данные нужно грузить в хранилище как можно быстрее или, например, допустима загрузка раз в сутки ?
раз в сутки, а может даже раз в неделю.

Неужели балком нельзя за сутки загрузить пару - тройку Тб в простую таблицу без индексов, затем построить индексы и за пару - тройку микросекунд впихнуть эту таблицу в пустую секцию, ну очень большой секционированной талицы ?
А...
delpasso
Понятно что нужно делать партишенс. Вопрос как их делать оптимально?
Делать одну партицию на день данных и иметь 300 партиций в год или на ндедлю данных и соответственно иметь 50 партиций в год?

Вас это напрягает
Ну так попробуйте рассмотреть это с такой стороны:
1) Кол-во секций - вего лишь записи в системных таблицах
2) Удалять старые данные (в Вашем и моем случае - старее года) нужно не по секциям а по файловым группам.
3) Одна файловая группа может содержать более одной секции. У меня в одной файловой группе их три по 10 дней.
Соответственно в одной файловой группе - 1 месяц. И удаляю/добавляю файловые группы/секции раз в месяц.
4) Даже с раздачи в SQL2k5 можно создавать до 999 секций => Вам хватить на три года с разбивкой по дням.
7 июл 11, 09:25    [10936331]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
mike909
Member

Откуда:
Сообщений: 662
delpasso,

В догонку...
Не надо изобретать велосипед.
Я лет 10 назад тоже увлекался изобретением мини SQL сервера по бинарным файлам с индексами и select_ами и поддержкой таких операций как Like. Со своим датапровайдером с Linked Server_ами и т.д. и т.п.
И даже это все около года работало рядом с SQL2k во время опытной эксплуатации последненго..
Да, быстрее в несколько раз (iocompletionport - forever)
Да, место на дисках раза в три меньше жрет...
Да, много чего еще ...
Но, как известно, аппетиты приходят во время еды.
Пошла аналитика, которую невозможно было представить в момент разработки и выяснилось, что, конечно можно и эти задачи порешать, вот только тягаться с SQL_ем с каждой новой задачей становилось все труднее...
7 июл 11, 09:46    [10936449]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
delpasso
А как вы BULKОМ в индекс файл пишите?
вы данные через свою имплементацию DataReader скармливаете BulkCopy. Отлично.
А с индексом как?
Вы свой собственный текстовый индекс строите?
"Индекс" - это не файл, это просто еще одна таблица в этой же базе.
У нас 2 DataReader-а, которые синхронизируются друг с другом.
7 июл 11, 11:43    [10937464]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2680
alexeyvg
Разделение по шпинделям, перенос драйверов в близкие ядра, распаралеливание загрузки, построение индексов без использования дисков - это всё просто стандартные операции.
Подскажите, плз, как можно разделить по шпинделям одну большую BULK операцию?
7 июл 11, 14:44    [10939309]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Makar4ik
Подскажите, плз, как можно разделить по шпинделям одну большую BULK операцию?
Лог на рейд, таблицы по файлгруппам, файлгруппы по дисковым массивам.
7 июл 11, 14:51    [10939356]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2680
Гавриленко Сергей Алексеевич
Makar4ik
Подскажите, плз, как можно разделить по шпинделям одну большую BULK операцию?
Лог на рейд, таблицы по файлгруппам, файлгруппы по дисковым массивам.
Это-то понятно, но...
Один BULK по одной таблице.
Таблица в файлгруппе.
Ну и как тут разделить одну файлгруппу по разным шпинделям?
А то предлагают ускорять единственную BULK операцию, разнося что-то по разным шпинделям, без создания массивов. :)
7 июл 11, 16:21    [10940137]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Makar4ik
Ну и как тут разделить одну файлгруппу по разным шпинделям?
А то предлагают ускорять единственную BULK операцию, разнося что-то по разным шпинделям, без создания массивов. :)
Вы прикалываетесь? Файлгруппа может состоять из более чем одного файла. Которые, в свою очередь, можно положить на более, чем один шпиндель.
7 июл 11, 16:23    [10940156]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 35396
Блог
Парсинг: попробуйте использовать диски в памяти, возможно получиться выиграть еще чуть-чуть.

Загрузка в MS SQL: у вас ежеминутный постоянный поток данных? то есть каждую минуту приходит примерно одинаковый по объему файл?
7 июл 11, 17:06    [10940574]     Ответить | Цитировать Сообщить модератору
 Re: ETL процесс и хранилище больших обьемов данных советы/идеи  [new]
delpasso
Member

Откуда:
Сообщений: 77
mike909
delpasso,
Что-то я перестал понимать Ваши проблемы. С чего Вы уперлись в скорость загрузки ?
Если
delpasso
пропущено...
раз в сутки, а может даже раз в неделю.

Неужели балком нельзя за сутки загрузить пару - тройку Тб в простую таблицу без индексов, затем построить индексы и за пару - тройку микросекунд впихнуть эту таблицу в пустую секцию, ну очень большой секционированной талицы ?

старина, в данный момент загрузка 1 минуты данных занимает 1.5 минуты.
это то, что есть. это плохо и медленно. с этого началась дискуссия.
mike909
А...
delpasso
Понятно что нужно делать партишенс. Вопрос как их делать оптимально?
Делать одну партицию на день данных и иметь 300 партиций в год или на ндедлю данных и соответственно иметь 50 партиций в год?

Вас это напрягает
Ну так попробуйте рассмотреть это с такой стороны:
1) Кол-во секций - вего лишь записи в системных таблицах
2) Удалять старые данные (в Вашем и моем случае - старее года) нужно не по секциям а по файловым группам.
3) Одна файловая группа может содержать более одной секции. У меня в одной файловой группе их три по 10 дней.
Соответственно в одной файловой группе - 1 месяц. И удаляю/добавляю файловые группы/секции раз в месяц.
4) Даже с раздачи в SQL2k5 можно создавать до 999 секций => Вам хватить на три года с разбивкой по дням.

да нет. абсолютно не напрягает. просто хотелось услышать мысли.
вот ваши к примеру. спасибо кстати.
7 июл 11, 17:29    [10940752]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить