Вы абсолютно правы, что в сфере 1С действительно существует проблема с отсутствием глоссария и единой терминологии, и что роль аналитика зачастую очень размыта.
Что касается «котопса». Мы хотели донести, что существует два подхода: внедрение типовой коробки и собственная разработка. В первом случае аналитик 1С больше похож на бизнес‑аналитика‑консультанта, которому важно знание отраслевой конфигурации, а не глубокое понимание объектов платформы 1С. Во втором же случае ключевыми являются знания платформы и ее объектов, работа с требованиями на разработку.
Сейчас мы активно развиваем внутренний центр экспертизы системного анализа, одной из целей которого является определение границ роли системного аналитика с точными критериями DOR (Definition of Ready) и DOD (Definition of Done).
Это действительно актуальная тема, границы бизнес/системного анализа зачастую бывают очень размытыми и это касается не только 1С. Этот вопрос заслуживает отдельной статьи.
Привет! Вы правы, что язык запросов 1С имеет свои особенности и отличия от стандартного SQL. Однако есть и схожие моменты, о которых стоит упомянуть.
Действительно, в языке запросов 1С основное внимание уделено оператору выбора данных (SELECT), и многие привычные для SQL операторы, такие как INSERT и DELETE, отсутствуют в привычном формате. Это связано с тем, что в 1С управление данными осуществляется через объекты системы (ORM), а не через прямые запросы к базе данных.
Тем не менее, оба языка поддерживают следующие общие возможности:
Соединения таблиц (JOIN): можно объединять данные из нескольких таблиц.
Условия фильтрации (WHERE): позволяют задавать критерии отбора данных.
Алиасы: используются для упрощения ссылок на таблицы и столбцы.
Временные таблицы: используются для хранения промежуточных результатов запросов.
Мы привели аналогию с SQL для того, чтобы читателям, не знакомым с 1С, было легче понять принципы работы с этим языком запросов. Основная идея заключается в том, что оба языка предназначены для работы с данными и имеют схожие синтаксические структуры, что упрощает их восприятие для пользователей, имеющих опыт работы с SQL. На этом уровне суждение о том, что языки запросов очень похожи вполне справедливо.
BI‑решение как интерфейс для пользователя — Microsoft Power BI. Он был в стеке компании и, по крайней мере пока, решение об изменении софта в этой части не принималось. Переезд на другую BI‑систему само по себе очень сложное и долгое мероприятие, поэтому пока что оставили то, что есть и сосредоточились на данных.
Miner, Cleaner, Validator — самописные модули на Python. Решили именно так, потому что требуется точечное управление различными элементами и настройками этих модулей, нет привязок к вендорам (в т.ч. иностранным), и в команде есть экспертиза и наработки по такого рода решениям. Такая же история с ETL/ELT: используем Apache Airflow и пишем самостоятельно «даги» на Python.
Теперь про архитектуру:
Сначала пишете, что у вас MS SQL и Clickhouse — да, это описание того, что есть
Внезапно PostgreSQL с расширением Citus — это описание того, что решили ставить для DWH
Почему не Clickhouse например — потому что Clickhouse, при всех его плюсах не подходит для построения якорной архитектуры, из‑за ограниченности его SQL и не лучшей работы джоинов, а в якорной модели их очень и очень много. Clickhouse оставили для хранения сырых данных и, возможно, в перспективе, будем его использовать для размещения витрин данных (вопрос требует некоего исследования, поэтому точного ответа пока нет)
Почему так сильно разнесли данные — для их сохранности. Сырые данные находятся на одном сервере в Clickhouse, очищенные и обработанные на другом в PostgreSQL, а подготовленные витрины на третьем. В архитектуру изначально заложен максимум с точки зрения безопасности, целостности и сохранности данных, но если в процессе что‑то окажется избыточным, можно будет принять решение об отказе от этой части. В любом случае, отказаться от чего‑то легче, чем встраивать то, что изначально не запланировано. Об этом будут другие публикации
Merge кода автоматизирован. При коллизии ответственный за этот merge разработчик получает уведомление об ошибке и самостоятельно его устраняет. В нашей практике на ручной ручной мёрж приходится менее 10% случаев.
Целью статьи не было подробное описание всех деталей реализации. Мы лишь описали основные принципы и эффект от внедрения. Такая, больше статья - знакомство. Позднее уже будем писать подробные технические тексты с разборами и так далее. Stay tuned, как говорится.
Тут мы идём путём декомпозиции задач, она происходит всегда. Задач более чем на 3-4 дня у нас не бывает. Крайне редко случается, что задачи, которые разбить не выходит, мы выносим в отдельную ветку, которую мёржат по окончанию работ.
Вы абсолютно правы, что в сфере 1С действительно существует проблема с отсутствием глоссария и единой терминологии, и что роль аналитика зачастую очень размыта.
Что касается «котопса». Мы хотели донести, что существует два подхода: внедрение типовой коробки и собственная разработка. В первом случае аналитик 1С больше похож на бизнес‑аналитика‑консультанта, которому важно знание отраслевой конфигурации, а не глубокое понимание объектов платформы 1С. Во втором же случае ключевыми являются знания платформы и ее объектов, работа с требованиями на разработку.
Сейчас мы активно развиваем внутренний центр экспертизы системного анализа, одной из целей которого является определение границ роли системного аналитика с точными критериями DOR (Definition of Ready) и DOD (Definition of Done).
Это действительно актуальная тема, границы бизнес/системного анализа зачастую бывают очень размытыми и это касается не только 1С. Этот вопрос заслуживает отдельной статьи.
Привет! Вы правы, что язык запросов 1С имеет свои особенности и отличия от стандартного SQL. Однако есть и схожие моменты, о которых стоит упомянуть.
Действительно, в языке запросов 1С основное внимание уделено оператору выбора данных (SELECT), и многие привычные для SQL операторы, такие как INSERT и DELETE, отсутствуют в привычном формате. Это связано с тем, что в 1С управление данными осуществляется через объекты системы (ORM), а не через прямые запросы к базе данных.
Тем не менее, оба языка поддерживают следующие общие возможности:
Соединения таблиц (JOIN): можно объединять данные из нескольких таблиц.
Условия фильтрации (WHERE): позволяют задавать критерии отбора данных.
Алиасы: используются для упрощения ссылок на таблицы и столбцы.
Временные таблицы: используются для хранения промежуточных результатов запросов.
Мы привели аналогию с SQL для того, чтобы читателям, не знакомым с 1С, было легче понять принципы работы с этим языком запросов. Основная идея заключается в том, что оба языка предназначены для работы с данными и имеют схожие синтаксические структуры, что упрощает их восприятие для пользователей, имеющих опыт работы с SQL. На этом уровне суждение о том, что языки запросов очень похожи вполне справедливо.
Спасибо за ваш интерес и внимание к деталям!
BI‑решение как интерфейс для пользователя — Microsoft Power BI. Он был в стеке компании и, по крайней мере пока, решение об изменении софта в этой части не принималось. Переезд на другую BI‑систему само по себе очень сложное и долгое мероприятие, поэтому пока что оставили то, что есть и сосредоточились на данных.
Miner, Cleaner, Validator — самописные модули на Python. Решили именно так, потому что требуется точечное управление различными элементами и настройками этих модулей, нет привязок к вендорам (в т.ч. иностранным), и в команде есть экспертиза и наработки по такого рода решениям. Такая же история с ETL/ELT: используем Apache Airflow и пишем самостоятельно «даги» на Python.
Теперь про архитектуру:
Сначала пишете, что у вас MS SQL и Clickhouse — да, это описание того, что есть
Внезапно PostgreSQL с расширением Citus — это описание того, что решили ставить для DWH
Почему не Clickhouse например — потому что Clickhouse, при всех его плюсах не подходит для построения якорной архитектуры, из‑за ограниченности его SQL и не лучшей работы джоинов, а в якорной модели их очень и очень много. Clickhouse оставили для хранения сырых данных и, возможно, в перспективе, будем его использовать для размещения витрин данных (вопрос требует некоего исследования, поэтому точного ответа пока нет)
Почему так сильно разнесли данные — для их сохранности. Сырые данные находятся на одном сервере в Clickhouse, очищенные и обработанные на другом в PostgreSQL, а подготовленные витрины на третьем. В архитектуру изначально заложен максимум с точки зрения безопасности, целостности и сохранности данных, но если в процессе что‑то окажется избыточным, можно будет принять решение об отказе от этой части. В любом случае, отказаться от чего‑то легче, чем встраивать то, что изначально не запланировано. Об этом будут другие публикации
Пофиксили. Спасибо
Приходите к нам работать ;) Всё расскажем, все покажем )
Merge кода автоматизирован. При коллизии ответственный за этот merge разработчик получает уведомление об ошибке и самостоятельно его устраняет. В нашей практике на ручной ручной мёрж приходится менее 10% случаев.
Целью статьи не было подробное описание всех деталей реализации. Мы лишь описали основные принципы и эффект от внедрения. Такая, больше статья - знакомство. Позднее уже будем писать подробные технические тексты с разборами и так далее. Stay tuned, как говорится.
Тут мы идём путём декомпозиции задач, она происходит всегда. Задач более чем на 3-4 дня у нас не бывает. Крайне редко случается, что задачи, которые разбить не выходит, мы выносим в отдельную ветку, которую мёржат по окончанию работ.