Добрый день! Боимся, что это определение уже не в нашей власти: есть несколько крупных систем виртуализации данных, архитекторы виртуализации данных, и если вы захотите узнать об этом подробнее – искать комьюнити придется по этому словосочетанию. Действительно, определения часто запутывают. Хотя есть среди них и устоявшиеся, часто в области данных аналитикам приходится использовать один из принципов 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 тренировалась в том числе на данных с гитхаба, значит, должна уметь работать с кодом.
По поводу того, что алгоритм рассчитан на традиционную архитектуру – тут Джеффри как раз указывает, что алгоритм был бы более эффективен на специализированном компьютере, который он называет «смертным».
Кажется, что идея очень похожая на Хебба, однако, в правилах Хебба нет порога для отделения положительных и негативных образцов, не говоря уже про остальные элементы современных нейросетей, которые перекочевали в алгоритм FF. Кроме того, в самой статье Хебб не упоминается.
Добрый день! Боимся, что это определение уже не в нашей власти: есть несколько крупных систем виртуализации данных, архитекторы виртуализации данных, и если вы захотите узнать об этом подробнее – искать комьюнити придется по этому словосочетанию. Действительно, определения часто запутывают. Хотя есть среди них и устоявшиеся, часто в области данных аналитикам приходится использовать один из принципов 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 тренировалась в том числе на данных с гитхаба, значит, должна уметь работать с кодом.
Хорошо и осмысленно отвечает на вопросы в домене, использованном при дообучении.
Добрый день! Fine-tuning на описанных данных длился 3 эпохи и занял примерно 52 минуты. Все использованные модели являются предобученными.
Добрый день! Ссылки в данный момент кликабельны.
Добрый день! Это опечатка при форматировании статьи, тесты проводились на корректном коде.
Спасибо за развернутое дополнение к статье!
По поводу того, что алгоритм рассчитан на традиционную архитектуру – тут Джеффри как раз указывает, что алгоритм был бы более эффективен на специализированном компьютере, который он называет «смертным».
Кажется, что идея очень похожая на Хебба, однако, в правилах Хебба нет порога для отделения положительных и негативных образцов, не говоря уже про остальные элементы современных нейросетей, которые перекочевали в алгоритм FF. Кроме того, в самой статье Хебб не упоминается.
На Хабр нашими экспертами не были найдены статьи по данной теме.
Отправили пример дашбоарда по указанному адресу
Cпасибо за отзыв! Да, конечно. Пришлите, пожалуйста, ваш мейл - поделимся.
Спасибо, идею поняли, поправили)
Подскажите, пожалуйста, в каком месте и для решения какого вопроса предлагаете использовать ReplicatedMergeTree?"