Sergey Khristolyubov @tomleto
Wikibot.pro — AI-agents for support and sales.
Information
- Rating
- Does not participate
- Location
- Пермь, Пермский край, Россия
- Date of birth
- Registered
- Activity
Specialization
Data Engineer, ML Engineer
Wikibot.pro — AI-agents for support and sales.
Эксперты считают что WikiBot открывает новую веху сразу в двух областях: конструкторы чат-ботов и техподдержка
WikiBot - сервис по созданию чат-бота с искусственным интеллектом для общения с клиентами
WikiBot индексирует вашу документацию или сайт по продукту и затем отвечает на вопросы пользователей как человек. Под капотом ChatGPT или другая большая языковая модель.
Цель WikiBot - сделать простое решение которое позволяет компаниям сократить расходы на ФОТ технической поддержки и уменьшить среднее время ожидания ответа.
Пример, как это работает https://t.me/Excel_WikiBot (Помощник по Excel)
Сайт https://wikibot.tomleto.pro/
спасибо ))
По data engineering курсов очень много, но именно по теме моделироования DWH нормальных курсов и книг на русском я не нашёл.
Можно начать с книги Building a Scalable Data Warehouse with Data Vault 2.0.
Как мне кажется когда сам изучаешь методологии Data Vault и Anchor modeling, то возникает куча вопросов. Как лучше смоделировать на своих данных? И спросить не у кого.
Поэтому чтобы научиться использовать эти методологии в бою, лучше поработать в большой компании где это всё описано и стандартизировано. Например, я работал в X5 и там очень круто сделана академия EDW где на рельных примерах разбирают все сущности Data Vault и расказывают о 100500 нюансах. Такой информации не найти в книгах.
Спасибо за развернутое мнение.
Я согласен что есть плюсы и минусы у обоих подходов.
Т.к. я писал рекомендации для маленьких проектов то, рекомендовал начать с sql.
На больших нужно считать деньги и риски, и энетрпрайс решение типа SAS DIS может быть предпочтительней т.к. там есть best bractice, много внедрений и меньше возможностей сделать всё очень плохо.
У нас расписание всегда запускается с method='increment'
А когда DE разрабатывает джобу ему доступны ещё "full" (полная перезагрузка) и "recreate" (пересоздание таргета).
А алгоритм загрузки определяется в теле джобы и зависит от основных двух параметров.
В примере:
"target_table_type": job_module.JobTargetTableType.MART,
"target_load_type": job_module.JobTargetTableLoadType.UPSERT_ROWS_BY_PK
Например при одном и том же алгоритме UPSERT_ROWS_BY_PK, аналитики для одних типов таблиц просят удалять данные удаленные из источника, а для других помечать как удаленные.
Т.е. как я предполагаю наши опции target_table_type и target_load_type играют ту же роль что у вас метод. И они также определяются в джобе.
Понятно ответил или я не очень понял вопрос?
Спасибо!
Я пытался описать принципы на основе которых мы создаем DWH.
Спасибо!
Просто джобы состоят из тасков. И в кругах дата инженеров это самое популярное слова для обозначения законченного ETL/ELT процесса
Я просто недавно прочитал «Google BigQuery. Всё о хранилищах данных, аналитике и машинном обучении», и там на мой взгляд, эти моменты были не раскрыты.
Я сам работаю на Greenpllum. Получается BigQuery радикально отличается от Greenpllum.
Расскажите подробнее как в BQ соотносятся вычислительные ресурсы и внешняя память:
1. Можно контролировать число слотов для моего ХД, например 5?
2. У каждого слота свой SSD и пользователь видит заполненность или для пользователя все данные одинаково доступны всем слотам в регионе?
3. Таблицы которые не входят на диск автоматически шардятся или пользователь должен сам задать настройки?
4. Когда при джойне больших таблиц данные пересылаются между слотами как пользователь может повлиять на оптимизацию запрос?
4.
Две хорошие статьи на эту тему: ссылка 1, ссылка 2
2. Согласен, Р. Кимбол хорош, просто я сослался на более современную книгу Modeling the Agile Data Warehouse with Data Vault by Hans Hultgren.
пора поменять!
Что касается качества, вы правы, иногда бывают проблемы.
Зато клиенты могут быстро получить работающее приложение.
Поэтому мы предлагаем ТЗ + прототип.
Кстати мы часто отговариваем заказчика от разработки и рекомендуем готовые сервисы.
Да, пока сильно не взлетело, но прогресс есть!
Пробуя разные гипотезы, мы ищем ту которая взлетит — методология CusDev.
у нас есть серверный и клиентский JavaScript, можно писать библиотеки на C#/Java, есть REST API.
Каждая строка GetReport может иметь набор состояний. Возможные состояния строк таблицы задаются справочником. Состояние строки называется — Статусом. Для каждой роли можно определить доступные переходы между статусами, права на правку ячеек и добавление строк в определенном статусе.
Таким образом, Статусы позволяют определить бизнес-процесс. На каждом шаге бизнес-процесса определённые роли должны заполнять определенные поля, а затем переводить процесс на следующий шаг, изменяя статус объекта.
Следующим шагом развития будет добавление к нашему конструктору BPM нотации,
Любопытно, что с другого конца к нам двигаются BPM системы, которые реализуют у себя конструкторы таблиц и форм, Есть интересная статья, где сравниваются BPM система Appian и конструкторы баз данных: Zoho Creator., Salesforce Lightning, Microsoft PowerApps.
Добавим информацию об окончании лицензии в письмо.
Спасибо за предложение, шаблоны сейчас делаем.