круто, для активных пользователей телеграма, кто и так там зависает и читает каналы, это классный бот.
сам я пользуюсь другим подходом, т.к. перспектива считать копейки и каждый расход наводит тоску от траты времени.
Я просто выставляю себе дневной/недельный/месячный лимит на расходы которые я трачу как захочу, а также список обязательных расходов по заключенным договорам — типа аренды квартиры, платежа по кредиту и т.д.
все что не по договору, и все что выходит за пределы лимита — это так называемые «спонтанные» траты которые нужно пресекать и планировать чтобы не превышать определенную сумму в месяц.
итого, я может быть и не знаю детально по каждой транзакции, сколько я трачу на пельмени и огурцы, но точно знаю, что определенный % от заработка всегда сохраняется и доступен для инвестирования вдолгую
так можно переехать туда уже в возрасте с опытом и наслаждаться ценностями когда ты опытный и с построенной карьерой.
Вы же понимаете, что у молодого профессионала есть только один исчерпаемый ресурс — это время. Поэтому выгодно продавать свое время наибольшему покупателю, иначе вы просто своим тяжелым трудом будете поддерживать других дармоедов
в SSIS в любом компоненте есть Success Flow и Error Flow.
Т.е. уже архитектура ETL обязывает заранее планировать какие ошибки следует ожидать и как их следует обрабатывать.
по моему опыту:
если ваш ETL записыват в таблицу TableName, то весь Error Flow всегда надо записывать в отдельную TableName_Error таблицу и любое BI решение визуализирует в реалтайме возникающие ошибки в каждом выполненном пакете (batch).
1. сначала ищем все таблицы с названием _Error
2. считаем статистику — сколько строк в каждой таблице ошибок, какие типы ошибки самые частый (топ-3)
3. визуализируем циферки в тренд-графике, смотрим на outliers — случаи когда количество ошибок выходит за установленные пределы (либо в процентах к успешно загруженным данным, либо к статистике предыдущих месяцев)
4. точечно фокусируемся на зафейленных ETLах
5. с течением времени улучшаем качество данных и понижаем допускаемые пределы ошибок, чтобы повысить качество данных
в США и западной европе такая же ситуация, говорю по собственному опыту.
Мне кажется Израиль по менталитету очень близок к прогрессивному западу, отсюда и такой прогресс в окружении средневековых арабских стран ведомых нефтяными диктаторами
хотелось бы почитать про опыт деплоя микросервисов на immutable контейнерах. Т.е. если какой-то патч или изменения в конфигурации — то изменяем и тестим золотой образ и через зелено-голубой деплой создаем контейнеры на новой версии и вырубаем старые
надо подключить айфон к компьютеру и запустить айтюнс, чтобы он сделал бекап телефона на компьютер.
скорее всего перед бекапом, айфон чистит свои кишки, чтобы не бекапить кеш
очень круто, R как скриптовый инструмент для data-intensive операций выглядит интересно, код точно изящнее и выразительнее, чем на других скриптовых языках.
можете написать статью для новичков в R про концепцию tidyr?
интересно, можете раскрыть тему безопасности тогда?
у вас внедренные безопасники в каждую команду или централизованная система?
как выполняется сканирование на уязвимости, накатывание патчей, endpoint защита, всякие правила фаероволов, доступы, аккакунты и т.д. — как вы защищаете инфраструктуру от внешних угроз, но еще и внутрених угроз
мое понимание, что это больше относится к ITIL и ITSM.
неважно микросервисы у вас или монолиты, но должен быть золотой источник данных для всех ИТ активов и элементов конфигурации (особенно в продакшене). А любые изменения в этом источнике данных проходят через бизнес-процесс, который можно выразить в виде направленного ациклического графа действий (ручных или автоматизированных/роботизированных).
Также есть варианты дополнять золотой источник данных через сканирование/autodiscovery
я изложу тут свою пару мыслей, как менеджера по анализу данных в кровавом ентерпрайзе:
1. Как раз в вашем случае, когда разные базисы и полный зоопарк технологий и следует использовать Data Warehouse, как единый источник для аналитики. Именно в этом warehouse данные из сотен разных систем причесываются и приводятся к одному базису и проставляются внешние ключи к общим справочникам по всему ентерпрайзу (например бухгалтерия, учет кадров, производство, продажи и т.д.)
2. Почитайте любую книгу Ralph Kimball, это он патриарх и идейный лидер такого понятия как DWH и BI, там он затрагивает вопросы архитектуры — как в типичной огромной американской корпорации поставить на поток процесс анализа данных из зоопарка разных систем. Также он затрагивает вопросы контроля качества данных, когда данные нужно отбрасывать и возвращать отвественным людям на исправление, когда пропускать с пометкой, и т.д. — потому что любой анализ хорошо настолько, насколько точны и качественны данные. И тут важен не сам факт, что справились ли вы как аналитик с анализом и соединили точки воедино, а то, что должен быть выстроен процесс по контролю качества данных и улучшени. бизнес-процессов которые генерируют эти данные.
3. В ентерпрайзе обычно стоимость софта особого значения не имеет, и опенсорс не имеет преимуществ перед коммерческим софтом, зачастую наоборот. Потому, что в ентерпрайзе важно чтобы решение работало сразу из коробки, и сразу был доступ на основе Active Directory и интеграция с ITSM системой. Я например использую большой кластер Tableau Server, который стоит миллионы долларов, но зато там авторизация на основе Active Directory, движок данных Hyper который разработали PhD-шники из Стенфорда, готовый экспорт данных в PNG для презентации большим боссам и работу из iPad-а который у шефа который везде летает на корпоративном самолете и нету времени на встречу — вся коммуникация через комплекс дешбордов и мониторинг выставленных ключевых метрик по организации с 60+ тыс человек.
>> P.S. Кстати, а что значит «на любых размерах»? И сколько это стоит? И сколько будет исполняться.
бекенд обычный SQL Server 2008 на обычном сервере. Можно обойтись postgres при желании.
Под любыми размерами я имел в виду то, что терабайтные массивы данных аггрегируются в мегабайты аггрегаций.
Базовый принцип — давать человеку, принимающему решения, ровно столько данных, сколько нужно для принятия решения. Размер данных аггрегаций достаточных чтобы построить график изчисляется мегабайтами, и тут больше вопрос в качестве данных, нежели в технологии. Лучше потратить неделю на общение с бизнесом и с человеком, который будет смотреть на аналитику и принимать решения, чтобы итеративно построить то, что ему нужно — чем лопатить терабайты данных и забросать данными пользователя, чтобы у того голова вообще перестала работать от информационного шума.
ETL в R выглядит очень сурово, как забивание гвоздей электронным микроскопом. не умаляя ни разу вашу проделнанную работу, мне кажется вы используете не тот инструмент для задачи.
Как мне кажется простой data warehouse, 1 простой ETL и пара SQL запросов могли бы резво и надежно подсчитать все это (на любых размерах данных).
алгоритм примерно такой:
1. вытаскиваем 1 день данных из OLTP базы в OLAP staging table в DWH используя SSIS
2. проставляем transaction_id согласно установленным правилам -> сначала для строк с законченной транзакцией, затем для выпавших на шаге N-1 и проставляем сразу статус транзакции
3. считаем аггрегации по измерениям и кладем их в куб
4. визуализируем куб в Qlik/PowerBI/Tableau
какие выгоды от этого процесса для компании:
1. ETL работает как часы по установленному графику и работает быстро т.к. использует ресурсы сервера
2. сам процесс может быть разбит на несколько частей (etl, sql, visualization) и распределен на нескольких людей для командной работы/масштабирования процесса
3. используются более старые и проверенные в ентерпрайзе технологии SQL, SSIS, DWH которые изобрел еще дядюшка Кимбалл в мохнатые 80-ые
4. специалисты по SQL дешевле чем спецы в R
сам я пользуюсь другим подходом, т.к. перспектива считать копейки и каждый расход наводит тоску от траты времени.
Я просто выставляю себе дневной/недельный/месячный лимит на расходы которые я трачу как захочу, а также список обязательных расходов по заключенным договорам — типа аренды квартиры, платежа по кредиту и т.д.
все что не по договору, и все что выходит за пределы лимита — это так называемые «спонтанные» траты которые нужно пресекать и планировать чтобы не превышать определенную сумму в месяц.
итого, я может быть и не знаю детально по каждой транзакции, сколько я трачу на пельмени и огурцы, но точно знаю, что определенный % от заработка всегда сохраняется и доступен для инвестирования вдолгую
Вы же понимаете, что у молодого профессионала есть только один исчерпаемый ресурс — это время. Поэтому выгодно продавать свое время наибольшему покупателю, иначе вы просто своим тяжелым трудом будете поддерживать других дармоедов
Т.е. уже архитектура ETL обязывает заранее планировать какие ошибки следует ожидать и как их следует обрабатывать.
по моему опыту:
если ваш ETL записыват в таблицу TableName, то весь Error Flow всегда надо записывать в отдельную TableName_Error таблицу и любое BI решение визуализирует в реалтайме возникающие ошибки в каждом выполненном пакете (batch).
1. сначала ищем все таблицы с названием _Error
2. считаем статистику — сколько строк в каждой таблице ошибок, какие типы ошибки самые частый (топ-3)
3. визуализируем циферки в тренд-графике, смотрим на outliers — случаи когда количество ошибок выходит за установленные пределы (либо в процентах к успешно загруженным данным, либо к статистике предыдущих месяцев)
4. точечно фокусируемся на зафейленных ETLах
5. с течением времени улучшаем качество данных и понижаем допускаемые пределы ошибок, чтобы повысить качество данных
devblogs.microsoft.com/ssdt/sqldb-cicd-intro
Мне кажется Израиль по менталитету очень близок к прогрессивному западу, отсюда и такой прогресс в окружении средневековых арабских стран ведомых нефтяными диктаторами
скорее всего перед бекапом, айфон чистит свои кишки, чтобы не бекапить кеш
можете написать статью для новичков в R про концепцию tidyr?
у вас внедренные безопасники в каждую команду или централизованная система?
как выполняется сканирование на уязвимости, накатывание патчей, endpoint защита, всякие правила фаероволов, доступы, аккакунты и т.д. — как вы защищаете инфраструктуру от внешних угроз, но еще и внутрених угроз
неважно микросервисы у вас или монолиты, но должен быть золотой источник данных для всех ИТ активов и элементов конфигурации (особенно в продакшене). А любые изменения в этом источнике данных проходят через бизнес-процесс, который можно выразить в виде направленного ациклического графа действий (ручных или автоматизированных/роботизированных).
Также есть варианты дополнять золотой источник данных через сканирование/autodiscovery
1. Как раз в вашем случае, когда разные базисы и полный зоопарк технологий и следует использовать Data Warehouse, как единый источник для аналитики. Именно в этом warehouse данные из сотен разных систем причесываются и приводятся к одному базису и проставляются внешние ключи к общим справочникам по всему ентерпрайзу (например бухгалтерия, учет кадров, производство, продажи и т.д.)
2. Почитайте любую книгу Ralph Kimball, это он патриарх и идейный лидер такого понятия как DWH и BI, там он затрагивает вопросы архитектуры — как в типичной огромной американской корпорации поставить на поток процесс анализа данных из зоопарка разных систем. Также он затрагивает вопросы контроля качества данных, когда данные нужно отбрасывать и возвращать отвественным людям на исправление, когда пропускать с пометкой, и т.д. — потому что любой анализ хорошо настолько, насколько точны и качественны данные. И тут важен не сам факт, что справились ли вы как аналитик с анализом и соединили точки воедино, а то, что должен быть выстроен процесс по контролю качества данных и улучшени. бизнес-процессов которые генерируют эти данные.
3. В ентерпрайзе обычно стоимость софта особого значения не имеет, и опенсорс не имеет преимуществ перед коммерческим софтом, зачастую наоборот. Потому, что в ентерпрайзе важно чтобы решение работало сразу из коробки, и сразу был доступ на основе Active Directory и интеграция с ITSM системой. Я например использую большой кластер Tableau Server, который стоит миллионы долларов, но зато там авторизация на основе Active Directory, движок данных Hyper который разработали PhD-шники из Стенфорда, готовый экспорт данных в PNG для презентации большим боссам и работу из iPad-а который у шефа который везде летает на корпоративном самолете и нету времени на встречу — вся коммуникация через комплекс дешбордов и мониторинг выставленных ключевых метрик по организации с 60+ тыс человек.
>> P.S. Кстати, а что значит «на любых размерах»? И сколько это стоит? И сколько будет исполняться.
бекенд обычный SQL Server 2008 на обычном сервере. Можно обойтись postgres при желании.
Под любыми размерами я имел в виду то, что терабайтные массивы данных аггрегируются в мегабайты аггрегаций.
Базовый принцип — давать человеку, принимающему решения, ровно столько данных, сколько нужно для принятия решения. Размер данных аггрегаций достаточных чтобы построить график изчисляется мегабайтами, и тут больше вопрос в качестве данных, нежели в технологии. Лучше потратить неделю на общение с бизнесом и с человеком, который будет смотреть на аналитику и принимать решения, чтобы итеративно построить то, что ему нужно — чем лопатить терабайты данных и забросать данными пользователя, чтобы у того голова вообще перестала работать от информационного шума.
Как мне кажется простой data warehouse, 1 простой ETL и пара SQL запросов могли бы резво и надежно подсчитать все это (на любых размерах данных).
алгоритм примерно такой:
1. вытаскиваем 1 день данных из OLTP базы в OLAP staging table в DWH используя SSIS
2. проставляем transaction_id согласно установленным правилам -> сначала для строк с законченной транзакцией, затем для выпавших на шаге N-1 и проставляем сразу статус транзакции
3. считаем аггрегации по измерениям и кладем их в куб
4. визуализируем куб в Qlik/PowerBI/Tableau
какие выгоды от этого процесса для компании:
1. ETL работает как часы по установленному графику и работает быстро т.к. использует ресурсы сервера
2. сам процесс может быть разбит на несколько частей (etl, sql, visualization) и распределен на нескольких людей для командной работы/масштабирования процесса
3. используются более старые и проверенные в ентерпрайзе технологии SQL, SSIS, DWH которые изобрел еще дядюшка Кимбалл в мохнатые 80-ые
4. специалисты по SQL дешевле чем спецы в R