Добрый день! Это равнозначные термины. На практике в части PostgreSQL чаще используют понятие секционирование, а в части Apache Hive – партиционирование. В статье указано, что партиционирование еще может называться секционированием.
Добрый день! Верно, задача аппроксимации может быть решена с использованием сторонних библиотек. R или Python как раз те языки, где есть библиотеки, предоставляющие такие решения. Если вас больше устраивает такой вариант, конечно, им можно пользоваться, тем более, что вам ближе R или Python, чем SQL. Но стоит остановиться на ряде недостатков такого подхода:
1) SQL-решение может быть (возможно, с небольшими доработками) перенесено практически на любой тип базы (Oracle, MS SQL, SAP и т.д.). Возможно ли его так же легко перенести со сторонними библиотеками? Скорее – нет;
2) Производительность – не самая сильная сторона R или Python. Сможет ли ваше решение работать с такой же производительностью, как SQL-запрос? Здесь могут быть сомнения;
3) Установка дополнительных библиотек – не всегда простая задача. Если вам доводилось работать в крупных организациях, то на согласование и установку библиотек уйдут месяцы;
4) По поводу того, что нельзя/сложно апроксимировать периодическую функцию: ряд Фурье считается SQL-ем практически так же, как и другим языком;
5) Какой код легче читать – здесь, как нам кажется, дело вкуса и привычки.
Добрый день! Рассмотренная в статье зависимость (количество Интернет-пользователей от времени) – это всего лишь один из возможных примеров. Предложенный вариант решения носит универсальный характер, то есть подходит под любой пример. По этой причине рассматриваются все варианты аппроксимации, даже если они заведомо плохо описывают конкретный пример (есть вероятность, что другой пример опишет как раз та аппроксимация, которая не дала хорошего согласия в нашем случае). Вариант степенной регрессии записан в виде y=ax^b. Надо понимать, что мало записать функцию произвольного вида, следующим шагом необходимо решить уравнения методом МНК, а это накладывает существенные ограничения. Не каждая система уравнений может быть решена аналитически. Как раз это и мешало добавить дополнительное слагаемое - с в уравнение (добавить можно, но решить нельзя). Для улучшения аппроксимации можно переопределить систему координат, и об этом говорится в статье. График функции 21 - y=b/x – это гипербола.
Если смотреть глубже - да, инструменты заточены под решение разных задач. Но в данном случае рассматривается конкретная задача, которая может быть решена обоими способами. Суть задачи максимально упрощена. Необходимо было показать - что могут предложить эти инструменты.
Уже в дальнейшем, исходя из бизнес-задач, которые могут возникать, мы можем здраво оценить, что будет предпочтительнее выбрать.
Ну и опять же - обработка ошибок, алертинг... не-еет
Тема данной статьи не связана с обработкой ошибок, настройкой алертинга и т. д. Эти вещи, безусловно, необходимы, но в текущей статье не требуют разработки и упоминания.
Но блин, вы запускаете 4 своих потока асинхронно, и надеетесь, что они всегда дадут 4 flow-file'а. А если нет? Если трафик обновления в таблицах разный? Пуф! Вы пролюбили данные.
А если кто-то остановил процессоры после первого инсерта? Пуф, вы пролюбили данные - следующий флоуфайл запустит truncate.
А если трафик изменений в таблицах действительно высокий? Пуф! Вы пролюбили данные - цепочка обработки не ждет прохождения каждого отдельного flow-file'а от начала и до конца.
Если БЫ вы использовали запуск по крону - этих проблем бы не было, но чистить временные данные "in general" все равно лучше после того, как завершили запись, а не до.
Проблема с количеством Flow Files очевидна. Конечно, мы потеряем данные, если их будет меньше четырех штук. Но в данном случае мы принимаем, что источник всегда будет отдавать новые записи.
В данной статье не говориться, что запуск потоков руками - это то, как нужно работать с данными процессорами. Стоило об этом написать, но в текущей статье подразумевается то, что процессоры будут запускаться одновременно с определенной периодичностью, которую мы можем самостоятельно настроить. Это обезопасит нас от повторных запусков и от преждевременного затирания данных.
Если вы уверены, что на каждый запуск у вас будут данные по всем четырем потокам - зачем вам тут скрипты? Используйте merge с min files = max files = 4 и expiration на очереди.
Использование скриптов объясняется желанием показать, что такая функциональность присутствует, а также показать на простом примере, как эти скрипты могут выглядеть.
Если у вас четыре идентичных потока обработки - не надо их контрол-цэ контрол-вэ - извлекли данные из таблиц - запускайте их в общий поток с параметризацией - под нагрузкой окупится.
По поводу общего потока согласны. Так как в данном случае мы получаем имя таблицы, которую захватываем + имеется возможность добавить атрибут, который более точно определял бы источник, мы могли бы реализовать процесс Truncate'а и записи через один процессор. Но нужно проверить, действительно ли это более оптимальное решение.
Не хочу никого обидеть, но главный поток, который я тут усматриваю - это поток сознания автора. Если в вашей компании не принято следовать законам логики в аналитической работе (а такой вывод напрашивается из ваших текстов), то работать у вас как-то совсем не хочется, извините.
Если вместо дискуссий откланяться на непродуктивную критику без конкретики и воображаемую реальность, то вряд ли легко дается работа в команде – а для компании это важный навык.
Нет уж, извините. Аналитик именно анализом и занимается. И это самое конкретное определение, которое вообще может быть. А если у вас тот же самый сотрудник кроме обязанностей (функции, роли) аналитика выполняет еще какие-то задачи, напр. change-manager'а, то это совсем другое дело.
Если вернуться к аналитику, то кроме анализа, есть задачи синтеза и в целом другие подходы. То есть определение минимум неполное. Если вспомнить, что есть другие специалисты по анализу, то определение неконкретное.
Если действительно интересны обязанности и навыки аналитика, то есть свежий профессиональный стандарт Системного аналитика от 27.4.2023 и немного устаревший стандарт Бизнес аналитика от 2018 г. Рекомендуем с ним ознакомиться, там прописаны в том числе и стандартная работа с изменениями, чтобы не путаться.
То есть, по-вашему, если внутри системы происходят какие-то процессы, то это какой-то исключительный случай??? Хм.
Есть еще одно базовое определение: система – это множество элементов, их свойств и связей. Как раз системный анализ рассматривает объекты как системы. Если мы говорим о таких объектах, как процессы, то это система, которая часто зависит от внешних реакций, инструментов и т.д.
Все определения в статье основаны на личном опыте работы автора в разных командах. Автор считает, что у определений есть свой «жизненный цикл»: например баг, курсор или брандмауэры менее ста лет назад значили совсем другое. Было бы интересно подискутировать и, возможно, найти более качественные интерпретации. В нашей компании мы часто это практикуем.
Специалист по анализу – это узкое и неконкретное определение, так как аналитик занимается не только анализом.
Заказчики приходят к нам не с решением, а с проблемой (то есть в процессе существования системы возникает некое изменение, которое его волнует). На начальном этапе аналитики собирают всю вводную и осмысливают эту информацию (при крупных или нетривиальных задачах прорабатываем задачу с архитекторами и разработчиками). Когда находим решение – обязательно согласовываем с заказчиком.
Любое неосмысленное изменение – мина замедленного действия. Если есть требование или характеристика, которую вы не учли, то в будущем это может стать проблемой. Например, десять лет назад начался шквал миграций\изменений хранилищ, потому что не ожидали, что данных будет настолько много. Масштабируемость сейчас – одна из главных характеристик, которую мы определяем на первичном этапе.
Согласимся: можно написать описание или план процесса. Хотя в нашу эпоху «философии эджайла» именно процесс, который уже пережил несколько этапов формирования, практического прохождения, модификаций, ближе к реальному положению дел.
Различия между потоками и процессами – это базовые понятия. Если кратко, потоки – это последовательности (данных, команд и т.д.), часто находящиеся в одной системе, на которую не влияют внешние условия. Процессы – это конкретные действия, часто связанные с внешними инструментами, реакциями и другими процессами.
Поток данных, которые также требуют осмысления. Сейчас работа аналитика кажется бесконечной, так как повсюду много изменений. Если у вас есть возможность и желание работать\развиваться в этой теме – добро пожаловать, в нашей компании есть задачи, которые этому поспособствуют.
Добрый день! Боимся, что это определение уже не в нашей власти: есть несколько крупных систем виртуализации данных, архитекторы виртуализации данных, и если вы захотите узнать об этом подробнее – искать комьюнити придется по этому словосочетанию. Действительно, определения часто запутывают. Хотя есть среди них и устоявшиеся, часто в области данных аналитикам приходится использовать один из принципов DDD и для команды – универсальный язык внутри домена. В начале проекта определяем глоссарий и синхронизируемся «по понятиям».
Добрый день! Действительно, внутренние инструменты Oracle могут закрыть основной функционал DataHub в плане сбора статистики. Однако, DataHub может собирать аналогичную статистику для большинства БД помимо Oracle (например, PostgreSQL, MySQL и т.д.) и хранить в все источники в одном пространстве. Также DataHub очень удобен, если таблиц профилирования очень много и от их количества не увеличивается сложность написания yml-файла – не нужно писать каждую таблицу, достаточно указать схему или regex-выражение, по которому он будет профилировать.
Спасибо за вопрос, в данном случае мы партиционировали по дате + остаток от кода продукта: PARTITION BY toUInt64(concat(toString(toYYYYMMDD(date)), toString(productCode % 50)))
модуль (деления с остатком) в данном случае никак не влияет на временной ряд - у нас как хранились данные за целые сутки в одной партиции, так и хранятся, от модуля остатка зависит строки с какими кодами продуктов в какую партицию попадут (в одной дате).
50 было получено эмпирическим путём, мы пробовали 5, 10, 25, 50 и даже 100. Чем больше модуль (деления с остатком), тем меньше оперативной памяти требуется для однопоточного перестроения витрины с даты T-N, но начиная с какого-то момента (в нашем случае оказалось при модуле > ~50) эффективность этой пропорции падает, поэтому важно найти золотую середину, как написали в конце статьи.
В целом Вы правы, можно, и решений можно найти несколько, но конкретно под нашу задачу нам показалось проще сделать скриптами, потому что:
Исходная таблица, если вкратце, — это готовая к использованию витрина, которая хранит результат нескольких трансформаций, она не просто пополняется новыми строками, а перестраивается целыми партициями через DROP/REPLACE, а мы, решая свою задачу, за наполнение исходной таблицы можем и не отвечать. Т.к. mat.view забирает новые строки из результата SELECT и вставляет в целевую таблицу, оно бы дублировало данные в целевой SummingMergeTree таблице. Можно было бы сделать другую более подходящую исходную таблицу для mat.view->SummingMergeTree, например, в которую пишется только инкремент изменений. Но для наполнения этой таблицы инкрементов скорее всего также понадобился бы скрипт или непростая цепочка mat.view->table и доп. место в БД.
SummingMergeTree (как и другие подобные "схлопывающие строки" движки таблиц CH) объединяет строки в неопределённый момент времени. А хотелось бы иметь готовую к использованию витрину и в любой момент быть уверенным, что там нет дублей. Из SummingMergeTree-таблицы пришлось бы выбирать данные не простым запросом SELECT/WHERE, а дополнительно еще раз агрегировать, не хотелось нагружать этой агрегацией клиентские приложения, которые забирают данные из витрины, или удлинять цепочку преобразований еще одним mat.view.
Ответ простой, но под этим простым ответом стоят сложные и интересные концепции и личный опыт, которыми хотелось поделиться. Ничего не мешает взять текущий пайплайн и применить для генерации не одно токена (класса), а для целой последовательности. Задача классификации hatespeech была взята в качестве демонстрации.
В целом, дельное замечание, но с LLaMA есть некоторые сложности. На данный момент порог вхождения выше для того, чтобы начать использовать эту модель дома. Во-первых, модель пока не представлена на HuggingFace и официально веса недоступны (да, есть неофициальные способы скачать веса). Во-вторых, квантизованная модель также не представлена, поэтому нужно квантизовать самому для чего требуются ресурсы. В-третьих, как вы и сказали, весов Stanford Alpaca готовых пока нет. GPT-J отличный бейзлайн, точка старта для тех, кто начинает работать с трансформерами. Кроме того, описанный здесь пайплан может быть применен к LLaMA.
С ходу сложно сказать, что получится, но идея интересная, стоит поисследовать! В целом никаких проблем нет, если грамотно составить датасет для дообучения. Более того, предобученная GPT-J тренировалась в том числе на данных с гитхаба, значит, должна уметь работать с кодом.
Добрый день! Это равнозначные термины. На практике в части PostgreSQL чаще используют понятие секционирование, а в части Apache Hive – партиционирование. В статье указано, что партиционирование еще может называться секционированием.
Добрый день! Для просмотра структуры определенной таблицы, можно сделать выборку из системного представления pg_catalog.pg_partitions
SELECT partitiontablename, partitionname, partitiontype, partitionlevel, partitionrankFROM pg_catalog.pg_partitionsWHERE schemaname = '<schema_name>'AND tablename = '<table_name>';Добрый день! Верно, задача аппроксимации может быть решена с использованием сторонних библиотек. R или Python как раз те языки, где есть библиотеки, предоставляющие такие решения. Если вас больше устраивает такой вариант, конечно, им можно пользоваться, тем более, что вам ближе R или Python, чем SQL. Но стоит остановиться на ряде недостатков такого подхода:
1) SQL-решение может быть (возможно, с небольшими доработками) перенесено практически на любой тип базы (Oracle, MS SQL, SAP и т.д.). Возможно ли его так же легко перенести со сторонними библиотеками? Скорее – нет;
2) Производительность – не самая сильная сторона R или Python. Сможет ли ваше решение работать с такой же производительностью, как SQL-запрос? Здесь могут быть сомнения;
3) Установка дополнительных библиотек – не всегда простая задача. Если вам доводилось работать в крупных организациях, то на согласование и установку библиотек уйдут месяцы;
4) По поводу того, что нельзя/сложно апроксимировать периодическую функцию: ряд Фурье считается SQL-ем практически так же, как и другим языком;
5) Какой код легче читать – здесь, как нам кажется, дело вкуса и привычки.
Добрый день! Рассмотренная в статье зависимость (количество Интернет-пользователей от времени) – это всего лишь один из возможных примеров. Предложенный вариант решения носит универсальный характер, то есть подходит под любой пример. По этой причине рассматриваются все варианты аппроксимации, даже если они заведомо плохо описывают конкретный пример (есть вероятность, что другой пример опишет как раз та аппроксимация, которая не дала хорошего согласия в нашем случае). Вариант степенной регрессии записан в виде y=ax^b. Надо понимать, что мало записать функцию произвольного вида, следующим шагом необходимо решить уравнения методом МНК, а это накладывает существенные ограничения. Не каждая система уравнений может быть решена аналитически. Как раз это и мешало добавить дополнительное слагаемое - с в уравнение (добавить можно, но решить нельзя). Для улучшения аппроксимации можно переопределить систему координат, и об этом говорится в статье. График функции 21 - y=b/x – это гипербола.
Здравствуйте, да, можно запустить CMAK из контейнера Docker, однако, такой задачи не стояло.
Если смотреть глубже - да, инструменты заточены под решение разных задач. Но в данном случае рассматривается конкретная задача, которая может быть решена обоими способами. Суть задачи максимально упрощена. Необходимо было показать - что могут предложить эти инструменты.
Уже в дальнейшем, исходя из бизнес-задач, которые могут возникать, мы можем здраво оценить, что будет предпочтительнее выбрать.
Тема данной статьи не связана с обработкой ошибок, настройкой алертинга и т. д. Эти вещи, безусловно, необходимы, но в текущей статье не требуют разработки и упоминания.
Проблема с количеством Flow Files очевидна. Конечно, мы потеряем данные, если их будет меньше четырех штук. Но в данном случае мы принимаем, что источник всегда будет отдавать новые записи.
В данной статье не говориться, что запуск потоков руками - это то, как нужно работать с данными процессорами. Стоило об этом написать, но в текущей статье подразумевается то, что процессоры будут запускаться одновременно с определенной периодичностью, которую мы можем самостоятельно настроить. Это обезопасит нас от повторных запусков и от преждевременного затирания данных.
Использование скриптов объясняется желанием показать, что такая функциональность присутствует, а также показать на простом примере, как эти скрипты могут выглядеть.
По поводу общего потока согласны. Так как в данном случае мы получаем имя таблицы, которую захватываем + имеется возможность добавить атрибут, который более точно определял бы источник, мы могли бы реализовать процесс Truncate'а и записи через один процессор. Но нужно проверить, действительно ли это более оптимальное решение.
Если вместо дискуссий откланяться на непродуктивную критику без конкретики и воображаемую реальность, то вряд ли легко дается работа в команде – а для компании это важный навык.
Если вернуться к аналитику, то кроме анализа, есть задачи синтеза и в целом другие подходы. То есть определение минимум неполное. Если вспомнить, что есть другие специалисты по анализу, то определение неконкретное.
Если действительно интересны обязанности и навыки аналитика, то есть свежий профессиональный стандарт Системного аналитика от 27.4.2023 и немного устаревший стандарт Бизнес аналитика от 2018 г. Рекомендуем с ним ознакомиться, там прописаны в том числе и стандартная работа с изменениями, чтобы не путаться.
Есть еще одно базовое определение: система – это множество элементов, их свойств и связей. Как раз системный анализ рассматривает объекты как системы. Если мы говорим о таких объектах, как процессы, то это система, которая часто зависит от внешних реакций, инструментов и т.д.
Добрый день! Спасибо за комментарии.
Все определения в статье основаны на личном опыте работы автора в разных командах. Автор считает, что у определений есть свой «жизненный цикл»: например баг, курсор или брандмауэры менее ста лет назад значили совсем другое. Было бы интересно подискутировать и, возможно, найти более качественные интерпретации. В нашей компании мы часто это практикуем.
Специалист по анализу – это узкое и неконкретное определение, так как аналитик занимается не только анализом.
Заказчики приходят к нам не с решением, а с проблемой (то есть в процессе существования системы возникает некое изменение, которое его волнует). На начальном этапе аналитики собирают всю вводную и осмысливают эту информацию (при крупных или нетривиальных задачах прорабатываем задачу с архитекторами и разработчиками). Когда находим решение – обязательно согласовываем с заказчиком.
Любое неосмысленное изменение – мина замедленного действия. Если есть требование или характеристика, которую вы не учли, то в будущем это может стать проблемой. Например, десять лет назад начался шквал миграций\изменений хранилищ, потому что не ожидали, что данных будет настолько много. Масштабируемость сейчас – одна из главных характеристик, которую мы определяем на первичном этапе.
Согласимся: можно написать описание или план процесса. Хотя в нашу эпоху «философии эджайла» именно процесс, который уже пережил несколько этапов формирования, практического прохождения, модификаций, ближе к реальному положению дел.
Различия между потоками и процессами – это базовые понятия. Если кратко, потоки – это последовательности (данных, команд и т.д.), часто находящиеся в одной системе, на которую не влияют внешние условия. Процессы – это конкретные действия, часто связанные с внешними инструментами, реакциями и другими процессами.
Поток данных, которые также требуют осмысления. Сейчас работа аналитика кажется бесконечной, так как повсюду много изменений. Если у вас есть возможность и желание работать\развиваться в этой теме – добро пожаловать, в нашей компании есть задачи, которые этому поспособствуют.
Добрый день! Боимся, что это определение уже не в нашей власти: есть несколько крупных систем виртуализации данных, архитекторы виртуализации данных, и если вы захотите узнать об этом подробнее – искать комьюнити придется по этому словосочетанию. Действительно, определения часто запутывают. Хотя есть среди них и устоявшиеся, часто в области данных аналитикам приходится использовать один из принципов DDD и для команды – универсальный язык внутри домена. В начале проекта определяем глоссарий и синхронизируемся «по понятиям».
Добрый день! Действительно, внутренние инструменты Oracle могут закрыть основной функционал DataHub в плане сбора статистики. Однако, DataHub может собирать аналогичную статистику для большинства БД помимо Oracle (например, PostgreSQL, MySQL и т.д.) и хранить в все источники в одном пространстве. Также DataHub очень удобен, если таблиц профилирования очень много и от их количества не увеличивается сложность написания yml-файла – не нужно писать каждую таблицу, достаточно указать схему или regex-выражение, по которому он будет профилировать.
Добрый день! Предложенный вариант был рабочим, но и другие варианты также имеют место быть.
Добрый день! На текущий момент в ручном режиме
Добрый день!
Спасибо за вопрос, в данном случае мы партиционировали по дате + остаток от кода продукта:
PARTITION BY toUInt64(concat(toString(toYYYYMMDD(date)), toString(productCode % 50)))
модуль (деления с остатком) в данном случае никак не влияет на временной ряд - у нас как хранились данные за целые сутки в одной партиции, так и хранятся, от модуля остатка зависит строки с какими кодами продуктов в какую партицию попадут (в одной дате).
50 было получено эмпирическим путём, мы пробовали 5, 10, 25, 50 и даже 100. Чем больше модуль (деления с остатком), тем меньше оперативной памяти требуется для однопоточного перестроения витрины с даты T-N, но начиная с какого-то момента (в нашем случае оказалось при модуле > ~50) эффективность этой пропорции падает, поэтому важно найти золотую середину, как написали в конце статьи.
В целом Вы правы, можно, и решений можно найти несколько, но конкретно под нашу задачу нам показалось проще сделать скриптами, потому что:
Исходная таблица, если вкратце, — это готовая к использованию витрина, которая хранит результат нескольких трансформаций, она не просто пополняется новыми строками, а перестраивается целыми партициями через DROP/REPLACE, а мы, решая свою задачу, за наполнение исходной таблицы можем и не отвечать. Т.к. mat.view забирает новые строки из результата SELECT и вставляет в целевую таблицу, оно бы дублировало данные в целевой SummingMergeTree таблице. Можно было бы сделать другую более подходящую исходную таблицу для mat.view->SummingMergeTree, например, в которую пишется только инкремент изменений. Но для наполнения этой таблицы инкрементов скорее всего также понадобился бы скрипт или непростая цепочка mat.view->table и доп. место в БД.
SummingMergeTree (как и другие подобные "схлопывающие строки" движки таблиц CH) объединяет строки в неопределённый момент времени. А хотелось бы иметь готовую к использованию витрину и в любой момент быть уверенным, что там нет дублей. Из SummingMergeTree-таблицы пришлось бы выбирать данные не простым запросом SELECT/WHERE, а дополнительно еще раз агрегировать, не хотелось нагружать этой агрегацией клиентские приложения, которые забирают данные из витрины, или удлинять цепочку преобразований еще одним mat.view.
Ответ простой, но под этим простым ответом стоят сложные и интересные концепции и личный опыт, которыми хотелось поделиться. Ничего не мешает взять текущий пайплайн и применить для генерации не одно токена (класса), а для целой последовательности. Задача классификации hatespeech была взята в качестве демонстрации.
В целом, дельное замечание, но с LLaMA есть некоторые сложности. На данный момент порог вхождения выше для того, чтобы начать использовать эту модель дома. Во-первых, модель пока не представлена на HuggingFace и официально веса недоступны (да, есть неофициальные способы скачать веса). Во-вторых, квантизованная модель также не представлена, поэтому нужно квантизовать самому для чего требуются ресурсы. В-третьих, как вы и сказали, весов Stanford Alpaca готовых пока нет. GPT-J отличный бейзлайн, точка старта для тех, кто начинает работать с трансформерами. Кроме того, описанный здесь пайплан может быть применен к LLaMA.
С ходу сложно сказать, что получится, но идея интересная, стоит поисследовать! В целом никаких проблем нет, если грамотно составить датасет для дообучения. Более того, предобученная GPT-J тренировалась в том числе на данных с гитхаба, значит, должна уметь работать с кодом.
Хорошо и осмысленно отвечает на вопросы в домене, использованном при дообучении.