Технологии BI применяются бизнесом уже не один десяток лет. Однако сегодня с развитием облачных технологий, BigData и машинного обучения BI выходит на новый уровень. К чему это ведет и какими станут практики BI в ближайшие годы — читайте в нашем посте. Под катом — немного истории, актуальные тренды и результаты исследований.

Источник

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

Современные часы имеют невероятные дополнительные функции

UPD: Продолжение статьи по ссылке — habrahabr.ru/company/avito/blog/322510

О чем статья

Незаметно пролетел год, как начались работы по разработке и внедрению хранилища данных на платформе Вертика.
На хабре уже есть статьи про саму СУБД Вертика, особенно рекомендую эту: HP Vertica, первый запущенный проект в РФ, ведь ее автор очень помог нам на начальном этапе. Алексей, спасибо еще раз.
Хотелось бы рассказать о том, какая методология применялась для проектирования физической структуры хранилища, чтобы наиболее полно использовать возможности HP Vertica.
Эту статью хотел бы посветить обоснованию оптимальности выбранной методологии, а в следующей — рассказать о том, какие техники позволяют анализировать данные, содержащие десятки млрд.

Постановка задачи

Рассмотрим высоконагруженный сайт крупной российской интернет-компании (теперь можно — это Авито ;)).
Деятельность компании описывается следующими цифрами: ~ 10 млн. активных пользователей, ~100 млн. просмотров страниц в день, около 1 тыс. новых объектов, размещенных пользователями на сайте в течение 1 минуты, ~10 тыс. поисковых запросов пользователей в минуту.
Грубая оценка количества действий, подлежащих сохранению в хранилище, составляет 100 млн. новых записей в сутки (~100 GB новых данных в сутки).
Т.е. при построении классического хранилища данных с отказом от стирания поступивших ранее данных, объем хранилища через 3 месяца эксплуатации составит 10TB сырых данных. Big Data как она есть.
Нужно построить хранилище, которое хранило бы не меньше 6 месяцев данных, позволяло их анализировать, визуализировать, и отставало бы от реальной жизни настолько мало, насколько это возможно (в худшем случае — отставало бы на день, в лучшем — на минуты).
Вынося сразу за скобки вопрос выбора платформы — хранилище должно работать на HP Vertica, MPP базе колоночного хранения, см. вводную статью в заголовке.

Какое-то время назад я написал статью на Хабре. В ней же пообещал продолжение через пару недель. Но, как известно, обещанного три года ждут  —  и с тех пор действительно прошло три года. Если вы не запомнили со времён той статьи, то напомню  —  я работаю в Avito, строю хранилище на основе Vertica.
Из того, что поменялось — теперь я могу не просто написать статью, а сделать это в блоге компании. И, надеюсь, не один раз. Самопиар окончен, теперь к делу.

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

Первой в списке стояла слепая печать, которую давно откладывал. Теперь считаю её необходимой для каждого, для кого код и конфигурация – профессия. Под катом расскажу как перевернулся мой мир, и поделюсь советами как перевернуть ваш. Заодно приглашаю поделиться своими рецептами и мнениями.

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

Адепты функционального программирования любят завлекать новичков обещаниями идеальной выразительности кода, 100% корректностью, лёгкостью поддержки и простотой рефакторинга, а иногда даже пророчат высочайшую производительность. Однако, опытные разработчики знают, что такого не бывает. Программирование — это тяжёлый труд, а «волшебных таблеток» не существует. 

С другой стороны, элементы функционального стиля программирования уже проникли в промышленные языки программирования, такие как Swift и Kotlin. Разработчики этих языков прекрасно знакомы с функциональным программированием, поэтому смогли применить его «в малом», предусмотрев многие, хотя и не все, необходимые компоненты. Чем дальше — тем больше части ФП внедряются в промышленные ЯП, и тем качественнее и полнее реализуется поддержка.

Уметь программировать в функциональном стиле полезно, чтобы упрощать себе работу, и сейчас мы посмотрим, как этим воспользоваться!


Виталий Брагилевский — преподаватель ФП, теории алгоритмов и вычислений, автор книги «Haskell in Depth» и участник комитетов Haskell 2020 и наблюдательного комитета компилятора GHC.

Мы не первый год работаем на рынке информационной безопасности. Основные наши клиенты – правоохранительные органы разных стран, спецслужбы, а также отделы IT безопасности в крупных компаниях. Иногда наши клиенты делятся с нами интересными историями; о некоторых из них можно прочитать и в средствах массовой информации. Сегодня я хочу рассказать несколько историй о людях, которым было «нечего скрывать» и у которых в результате возникли серьёзные проблемы буквально на ровном месте.

В чём проблема?

Я часто пишу статьи на тему информационной безопасности. Иногда получается понятно для неспециалиста, иногда, вероятно, не очень. «Что-то я вообще не понял посыла статьи […] в чем проблема?», «имхо, проблема с icloud, слегка притянута за уши», ну и бессмертное – «я не стал заморачиваться, мне нечего скрывать». Отлично, давайте посмотрим, стоит ли вам что-либо скрывать.

Celebgate: «проблема с iCloud слегка притянута за уши»

С момента выхода нашего первого продукта для извлечения данных из iCloud прошло более пяти лет. Ключ от продукта Elcomsoft Phone Password Breaker (сейчас у него другое название), который на тот момент мы продавали исключительно правоохранительным органам, был украден и попал в руки хакерской группировки.

How to deploy Python Telegram bot using Webhooks on Google Cloud Platform

Вместо предисловия

— Напиши телеграм-бота. Сейчас даже школьники пишут, — сказала она.
— А почему бы и нет, — подумал я тогда ( — Ну, ну, — сказал бы я сейчас).

Мы сидели в Бине и за чашкой кофе обсуждали возможности тестирования идей с моделями искусственного интеллекта на близком и не очень круге друзей. Лена, моя бывшая коллега, и во всех отношениях не блондинка, только что закончившая магистратуру, рассуждала так. Создав бота, можно сэкономить силы и время на интерфейсе, сосредоточившись на ядре с машинным обучением. Согласитесь, что устоять против такой логики “спортсменки, комсомолки и просто красавицы” в то прекрасное воскресное утро было невозможно. Решено. Телеграм-бот, значит телеграм-бот.

Первым делом я залез в гугл и нашел большое число ссылок “как сделать бот за 30 минут”. Это меня настолько воодушевило, что дальше названий я не пошел и занялся созданием ядра. В самом первом приближении мне предстояло написать систему обработки поисковых запросов с использованием NLP (natural language processing). Написание ядра заняло некоторое, вполне разумное, время (все же опыт кока-колой не пропить). И через несколько дней я был готов к тому, чтобы за пару часов обернуть первую тестовую версию ядра в пару другую команд send-receive, запустив все это в Телеграме на благо моим друзьям. Но не тут-то было.

Неожиданно возник целый клубок проблем. Потратив пару дней на поиски в интернете и общение с коллегами по цеху, я понял, что очевидное не очевидно, и еще одна “инструкция” точно не повредит. Так и появилась эта статья.

При слове «криптография» некоторые вспоминают свой пароль WiFi, зелёный замочек рядом с адресом любимого сайта и то, как трудно залезть в чужую почту. Другие вспоминают череду уязвимостей последних лет с говорящими аббревиатурами (DROWN, FREAK, POODLE...), стильными логотипами и предупреждением срочно обновить браузер.

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

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

Параллельные или распределенные вычисления — вещь сама по себе весьма нетривиальная. И среда разработки должна поддерживать, и DS специалист должен обладать навыками проведения параллельных вычислений, да и задача должна быть приведена к разделяемому на части виду, если таковой существует. Но при грамотном подходе можно весьма ускорить решение задачи однопоточным R, если у вас под руками есть хотя бы многоядерный процессор (а он есть сейчас почти у всех), с поправкой на теоретическую границу ускорения, определяемую законом Амдала. Однако, в ряде случаев даже его можно обойти.

Является продолжением предыдущих публикаций.

Как бы безумно это не звучало, но 2020 год наступит уже очень скоро. «2020 год» — это похоже на фразу из научно-фантастического романа. Но это не фантастика. Нас от этой даты отделяет всего несколько месяцев.



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

Лучший способ предсказать будущее — это создать его.
^{А. Линкольн}

Привет, меня зовут Игорь. Я десять лет работал в офисе, но год назад решился и перешел на удаленную работу. Для начала скажу, что теперь меня палкой не загонишь в офис! Перейти на удаленку было лучшее решение в моей жизни.

Плохо тебе, ненастоящий программист. А я — настоящий.

Нет, я тоже программист. Не 1С, а «на чем скажут»: когда С++, когда джава, когда шарпы, питон, даже на богомерзком джаваскрипте писал.

И да, я работаю на «дядю». Прекрасного дядю: собрал нас всех вместе и зашибает нереальные деньги. А я у него за зарплату работаю.

А еще у нас есть миссия. Громкая, красочная. Даже на бейджах написана.

И при всем этом я — «настоящий».

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


На просторах интернета есть немало статей на эту тему, но, к моему большому удивлению, они не ответили на многие мои вопросы по выбору нужного инструмента и были несколько поверхностны. В рамках 3 недель тестирования мы опробовали 4 инструмента: Tableau, Looker, Periscope/Sisense, Mode analytics. Про эти инструменты в основном и пойдет речь в данной статье. Сразу оговорюсь, что предложенная статья — это личное мнение автора, отражающее потребности небольшой, но очень быстро растущей IT-компании :)

Несколько слов о рынке

Сейчас на рынке BI происходят довольно интересные изменения, идёт консолидация, крупные игроки облачных технологий пытаются укрепить свои позиции путем вертикальной интеграции всех аспектов работы с данными (хранение данных, обработка, визуализация). За последние несколько месяцев произошло 5 крупных поглощений: Google купил Looker, Salesforce купил Tableau, Sisense купил Periscope Data, Logi Analytics' купил Zoomdata, Alteryx купил ClearStory Data. Не будем дальше погружаться в корпоративный мир слияний и поглощений, стоит лишь отметить, что можно ожидать дальнейших изменений как в ценовой, так и в протекционистской политике новых обладателей BI-инструментов (как недавно нас обрадовал инструмент Alooma, вскоре после покупки их компанией Google, они перестают поддерживать все источники данных, кроме Google BigQuery :) ).

Привет, Хабр! На тему архитектуры хранилищ данных написано немало, но так лаконично и емко как в статье, на которую я случайно натолкнулся, еще не встречал.

Предлагаю и вам познакомиться с данной статьей в моем переводе. Комментарии и дополнения только приветствуются!


(Источник картинки)

Свои Pebble Steel Classic я купил в 2014 году, аккурат перед выпуском самых первых Apple Watch (0 серия) (можно почитать мой обзор далекого 2014 года https://habr.com/ru/post/364677/). Я помню как сильно сомневался брать Pebble или подождать выпуска Apple Watch (это же Apple!) и как испытал облегчение когда часы от Apple все таки дошли до прилавков (тормозные, не работающие без смартфона, едва вытягивающий день использования).

После этого я каждый год смотрел на прогресс Apple Watch и каждый год не понимал ради чего стоит потратиться на этот довольно дорогой гаджет и чем он окажется лучше моих текущих Pebble.

В итоге, в 2019 году, получил часы в подарок на День рождения и, как говорится, все сомнения отпали сами собой. Появилась возможность сравнить эти двое часов без оглядки на их стоимость, а просто как два функциональных устройства между которыми 5 лет технологической пропасти.

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

Но в твоём коллективе есть Грустный Игнат. Игнат всегда мрачный, циничный и уставший. Он отличный специалист, давно работает в компании и знает, как всё устроено. Игнату все хотят помочь. Особенно ты, ведь ты его менеджер. Но, поговорив с Игнатом, ты и сам начинаешь чувствовать, как много вокруг несправедливости. И тоже начинаешь грустить. Но особенно страшно, если грустный Игнат — это ты.

Что же делать? Как работать с Игнатом? Добро пожаловать под кат!

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

Сегодня мы поделимся ссылками на первые публичные датасеты и расскажем о том, как они собирались. А ещё подскажем, где же правильно ставить ударение в названии нашей платформы.

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

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

Сейчас у нас около 6 миллиардов продуктовых событий в сутки, в ближайшее время дойдём до 20–25 миллиардов. А дальше — не такими быстрыми темпами поднимемся до 40–50 миллиардов к концу года, когда опишем все интересующие нас продуктовые события.

1 rows in set. Elapsed: 0.287 sec. Processed 59.85 billion rows, 59.85 GB (208.16 billion rows/s., 208.16 GB/s.)

Подробности под катом.