Big Data – термин, который вы можете часто встретить на просторах интернета. Вы можете найти множество статей, докладов и прочих материалов по этому термину, но давайте попробуем разобраться в нём, потому что он не так страшен, как о нём говорят.

Привет, Хабр! Это Саша Бардаш, главный архитектор интеграционных платформ в МТС Диджитал. В прошлый раз я рассказывал о пяти книгах, которые стоит почитать начинающему ИТ-архитектору. Большое спасибо всем, кто читал. Были интересные комментарии на тему, какие еще книги почитать — кое-что из этого я добавил в свою новую подборку. Итак, под катом пять книг, которые будут интересны уже более опытным ИТ-архитекторам. Что ж, поехали!

Каждый РП рано или поздно меняет работу. Вы уходите со старого места, где вы уже хорошо ориентируетесь, и приходите в неизвестность:

- неизвестный проект с неизвестными рисками;

- непонятный руководитель (при первом знакомстве он душка, но какой будет в реале?);

- непонятные коллеги;

- непонятный заказчик.

Причем, как правило, проект, который вам отдают, уже несется на всех парах: команда пашет, заказчик чего-то хочет, у нового руководителя какие-то ожидания. И хорошо, если все так просто. А часто случается, что проект уже летит в бездну, бюджет израсходован, заказчик всех ненавидит, а руководство ждет от вас сдачи на следующей неделе (да, такие случаи тоже бывали 😊).

Это очередная статья о том, чего не рассказывают на курсах РП: о тех самых софт-скиллах, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

Выглядит так, что РП, выходящий на новую работу, как пассажир, который пытается запрыгнуть в поезд на ходу, чтобы потом добраться до головы состава и начать им управлять. И чем быстрее летит поезд – тем сложнее в него запрыгнуть. Ну и на все про все у вас примерно 2 недели. 4 от силы, если место ванильное, и поезд еще не разогнался.

Как не свернуть шею и не попасть под колеса на этом славном пути – по пунктам ниже

В 2014-м я начал жарить кофе кустарно. Тогда я несколько дней работал на кухне, чтобы отправить в Абхазию тонну зерен без договора и предоплаты. Сегодня мое производство обжаривает порядка 20 тонн зерна в месяц и продает на 200 млн рублей в год.

Привет, Хабр!

Меня зовут Петр. Я работаю инженером по данным в Okko и обожаю ClickHouse. 

Примерно в середине прошлого года мы начали переезжать с PostgreSQL на ClickHouse. Одной из главных причин переезда была низкая производительность: среднее время аналитического запроса составляло около минуты. Сейчас, после переезда, среднее время запроса в аналитическом кластере — около 2 с. И это не предел.

Я расскажу, как мы пришли к текущему состоянию хранилища данных, какие ошибки совершили, какие шишки набили, и о каких фишках кликхауса предпочли бы знать заранее.

Статья в основном для тех, кто только начинает свой путь работы с кликхаусом: мы посмотрим, как делать не надо, и как можно сделать лучше.

В этой статье не будет объяснений почему для переезда мы выбрали именно этот инструмент. Не будет и глубокой теории о его внутреннем устройстве. Отметим лишь: в правильных руках ClickHouse — одна из самых быстрых колоночных СУБД для OLAP запросов.

В новом материале я хочу поговорить об истории визуализации данных. Речь не только о всяческих диаграммах (о чем недавно в нашем блоге была отдельная большая статья), но в принципе — как вообще появилась идея, что данные можно как-то кодировать и визуализировать? Как давно это началось? Через какие этапы развития прошла сама идея представления данных в наглядном виде? Есть ли еще куда развиваться, или мы уперлись в некий технический потолок? Обо всем этом — и не только.

Apache Airflow — это один из самых популярных ETL-шедулеров. ETL-процессы — это когда мы выбираем интересующие нас данные, приводим их к агрегированному виду и сохраняем для дальнейшего использования. И это присутствует везде, где есть необходимость анализа данных. Соответственно, Airflow предназначен для того, чтобы запускать пайплайны обработки данных.

Я написал эту статью для себя, но подумал, что она будет полезна и начинающим айтишникам, и тем, кому необходимо освежить знания или быстро вспомнить основные вещи, не открывая полное руководство.

Ещё раз подчеркну, статья задумывалась как базовая памятка и помощь для начинающих, а никак не исчерпывающая документация. Многое я опускаю ввиду избыточности или неактульности, по крайней мере в моей работе.

В жизни многих программистов наступает момент, когда хочется понять как же работает процессор на самом деле, а не в абстрактных схемах высокоуровневых компонентов. У меня возник такой вопрос некоторое время назад, но все материалы которые я находил по этой теме либо были очень специализированными, требующими хорошего понимания электротехники и опыта работы со схемами дискретной логики, либо общие описания, пропускающие многие этапы, и оставляющие лишь смутное представление о том как же всё-таки тысячи транзисторов должны превратиться в работающий процессор.

Для этого я решил написать статью собирающую мой опыт попыток разобраться в этом вопросе, понятным языком, в то же время не пропуская ничего, чтобы после прочтения читатель мог воссоздать процессор из простейших элементов.

В данной статьей мы пройдем путь создания процессора от единичного транзистора до работающего 8-битного процессора, и напишем свой ассемблер для него.

Наверняка, многие уже слышали, что новый правообладатель GreenPlum — компания Broadcom — перевела репозитории с открытым исходным кодом на GitHub в архивный статус.

Новые версии оригинального ядра, вероятнее всего, уже не будут выкладываться в публичный доступ, а начнут появляться только в коммерческой версии продукта. Это касается и 6-й, и 7-й версии.

Версии ядра, которые были выложены в open source на момент закрытия репозитория, остались под лицензией Apache 2.0, и их можно легально использовать. Но в оригинальном репозитории не осталось веток, тегов и дистрибутивов.

Мы — ГК «ГлоуБайт» — уже больше двух лет развиваем инструменты над open source GreenPlum 6 и выкладываем их в открытый доступ под лицензией Apache 2.0. Об это мы писали статью, в которой прикладывали ссылки на все наши open source репозитории.

Для сборки исходных кодов GreenPlum и дополнительных утилит мы использовали свои пайплайны и зеркала оригинального репозитория GreenPlum.

Сегодня мы решили перевести эти репозитории в открытый доступ на нашем GitLab. 

Мы в компании «Магнит» много лет строим и эксплуатируем корпоративное хранилище данных и занимаемся различными задачами, связанными с этим. В частности, разрабатываем инструмент для конечного пользователя — систему отчётности и BI.

В статье рассмотрим вопросы оптимизации производительности системы.

Хабр, привет!

Меня расстраивает несправедливость в мире IT: для новичков-разработчиков есть куча пошаговых инструкций, о там, как разработать API или мобильное приложение. Хочу немного уровнять баланс вселенной, поэтому я написал небольшой гайд для аналитиков для составления документации.

В прошлой статье я представил шаблон, а теперь заполнил его для фичи «Экспресс-доставка товара в маркетплейсе». Моя цель – показать, как можно вести документацию и как правильно заполнять этот шаблон.

Всем привет. Меня зовут Кирилл, я маркетинговый аналитик в Uzum. В этой статье я хочу поделиться с вами практическими примерами, которые демонстрируют реальную ценность методов причинно-следственного анализа. Отдельно расскажу, как библиотека CausalImpact помогает в решении бизнес-задач.

«Усложнять просто, упрощать сложно»

Закон Мейера

Часто ли вы задумываетесь о том, как вы воспринимаете ту или иную информацию? Почему одни статьи или книги идут легче, а другие - тяжелее? Бывало ли у вас такое, что вы раз за разом скользили взглядом по абзацу текста и не могли понять, что вы только что прочитали?

Визуальное представление данных - очень большая часть нашей жизни, и это влияет на разные ее сферы: обучение, работу, развлечения.

Что если мы скажем, что на практически любой вопрос можно дать ответ таким образом, что скорость восприятия получаемой информации возрастёт, а понимание будет гарантированным?

В современном бизнесе обратная связь от сотрудников, покидающих компанию, играет критически важную роль. Такие данные предоставляют уникальную возможность для руководства понять причины ухода, выявить слабые места в управлении и корпоративной культуре, а также улучшить условия работы для текущих и будущих сотрудников. Эти ценные инсайты могут помочь компании снизить текучесть кадров, улучшить внутренние процессы и создать более привлекательную рабочую среду.

Эта статья предназначена для менеджеров по персоналу, руководителей отделов, HR-специалистов и владельцев бизнеса, заинтересованных в развитии и улучшении своей компании. Статья будет полезна всем, кто стремится понять, как эффективно использовать обратную связь от уходящих сотрудников для повышения общего уровня удовлетворенности сотрудников и уменьшения текучести кадров.

Год назад я планировал выпустить серию статей по мотивам бесед с моими коллегами, но дальше одной статьи не пошло, хотя материала накопилось достаточно. Большинство моих товарищей остались на прошлых местах работ и считаю необходимым в знак уважения перед этими неординарными и талантливыми личностями продолжить свои рассказы охотника до талантов.

Сегодня — это руководитель и senior fullstack Марк Локшин. В этой беседе мы обсуждаем о заходе в тему разработки собственного инструмента Business Intelligence. Тема недвусмысленно намекает на то, что данная тема уже не раз была описана на соответствующих ресурсах, а российский рынок даже после ухода с него западных вендоров обладает собственным набором вполне зрелых и рабочих решений.

Собственно, откуда у нас появилась такая задача? Конечно же от заказчиков. А заказчики у нас чаще специфические: государственные и около организации, администрации субъектов регионов. У этих «ребят» чаще всего основная задача показать большому начальнику на совещании красивый график и отчитаться, как же все классно поработали, у особенных из этих заказчиков предъявлены жесткие требования к инструментам разработки.

Команда и мудрость (оно же знания, помноженные на опыт) – две основные составляющие и результата в проектах и эффективности работы структурных подразделений. Я руководитель и у меня есть своя команда и каждый ее член обладает навыками и скиллами, поделившись которыми с коллегами, усилит всю структуру. Лучшая атмосфера для того, чтобы поделиться друг с другом наработками, - это что-нибудь спокойное и располагающее к беседе, лучше с кальяном. Такие посиделки стали хорошим инструментом для усиления меня и моих людей.  Первым пилотом был Евгений В., руководителем дизайна, с которым мы провели несколько приятных моментов в беседе об информационном дизайне, Я сразу себе ставил цель, чтобы эта беседа стала доступна для каждого сотрудника, а для лучшего усвоения информации использовали несколько каналов его донесения – это статья в корпоративном пространстве,  запись самой беседы и интересные выдержки в корпоративном канале. Сейчас мы готовы делиться своей мудростью ? с более широким кругом читателей. Я надеюсь, что принципы, изложенные в этой статье, придутся вам по душе и сделают ваш дизайн лучше.

В статье расскажу о практических аспектах использования Apache NiFi, опишу преимущества и проблемы, с которыми я столкнулся.

Для наглядности собрал "песочницу" в контейнере Docker, в которой представлены упрощенные примеры пайплайнов, аналогичные тем, которые были использованы в реальном проекте.

Привет, Хабр! Мне, наконец, есть чем поделиться с вами. И это результаты практически годового процесса выбора BI-системы из числа российских разработок на замену одной из западных платформ. За это время мне стало очевидно, что примерно 50% действий, которые мы сделали, можно было и не делать, а 20% не стоило делать вовсе. В итоге получилась практически инструкция “как не надо” выбирать себе BI-систему, если вы хотите, чтобы она действительно начала приносить вам пользу ASAP. Под катом — также мои мысли о том, как надо было бы. Желающих обсудить, прошу присоединяться.