Sherlock by ThatsWhatSheSayd

Чтобы стать великим сыщиком, Шерлоку Холмсу было достаточно замечать то, чего не видели остальные, в вещах, которые находились у всех на виду. Мне кажется, что этим качеством должен обладать и каждый специалист по машинному обучению. Но тема Feature Engineering’а зачастую изучается в курсах по машинному обучению и анализу данных вскользь. В этом материале я хочу поделиться своим опытом обработки признаков с начинающими датасаентистами. Надеюсь, это поможет им быстрее достичь успеха в решении первых задач. Оговорюсь сразу, что в рамках этой части будут рассмотрены концептуальные методы обработки. Практическую часть по этому материалу совсем скоро опубликует моя коллега Osina_Anya.

Один из популярных источников данных для машинного обучения — логи. Практически в любой строчке лога есть время, а если это web-сервис, то там будут IP и UserAgent. Рассмотрим, какие признаки можно извлечь из этих данных.

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

Уроки после первых пилотных проектов с блокчейн

Автор: Владимир Алексеев, ведущий системный архитектор, IBM Россия и СНГ


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

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

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

Наверно, в мире данных нет подобного феномена настолько неоднозначного понимания того, что же такое Hadoop. Ни один подобный продукт не окутан таким большим количеством мифов, легенд, а главное непонимания со стороны пользователей. Не менее загадочным и противоречивым является термин "Big Data", который иногда хочется писать желтым шрифтом(спасибо маркетологам), а произносить с особым пафосом. Об этих двух понятиях — Hadoop и Big Data я бы хотел поделиться с сообществом, а возможно и развести небольшой холивар.
Возможно статья кого-то обидит, кого-то улыбнет, но я надеюсь, что не оставит никого равнодушным.

Демонстрация Hadoop пользователям

Количество данных растет с каждым днем огромными рывками. Ежедневно в сеть заливается 2,3 триллиона гигабайт данных. К 2017 году ожидается, что количество данных вырастет на 800%. Чем больше данных, тем выше спрос на специалистов по их обработке.

Наука о данных настолько динамично развивается, что у каждого специалиста есть своя узкая зона ответственности. Мартин Джонс (Martin Jones), CEO и co-founder в Cambriano Energy предлагает выделить 14 основных ролей в работе с большими данными.

В этой статье я хочу рассказать про важную задачу, о которой нужно думать и нужно уметь решать, если в аналитической платформе для работы с данными появляется такой важный компонент как Hadoop — задача интеграции данных Hadoop и данных корпоративного DWH. В Data Lake в Тинькофф Банке мы научились эффективно решать эту задачу и дальше в статье я расскажу, как мы это сделали.



Данная статья является продолжением цикла статей про Data Lake в Тинькофф Банке (предыдущая статья Data Lake – от теории к практике. Сказ про то, как мы строим ETL на Hadoop).

Привет, Хабр! Наконец-то долгожданная четвёртая статья нашего цикла о больших данных. В этой статье мы поговорим про такой замечательный инструмент как Hbase, который в последнее время завоевал большую популярность: например Facebook использует его в качестве основы своей системы обмена сообщений, а мы в data-centric alliance используем hbase в качестве основного хранилища сырых данных для нашей платформы управления данными Facetz.DCA

В статье будет рассказано про концепцию Big Table и её свободную реализацию, особенности работы и отличие как от классических реляционных баз данных (таких как MySQL и Oracle), так и key-value хранилищ, таких как Redis, Aerospike и memcached.
Заинтересовало? Добро пожаловать под кат.

Здравствуйте, уважаемые читатели!

Мы наконец-то приступаем к переводу серьезной книги о фреймворке Spark:



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

На наш взгляд, объектный язык ограничений (Object Constraint Language, OCL) должен знать каждый, кто занимается моделированием или кому интересна модельно-ориентированная разработка. Однако, он незаслуженно обделен вниманием в сети вообще, а, уж, в русскоязычном сегменте информации просто мизер. Что это за язык и зачем он нужен, описано в этой статье. Статья не претендует на фундаментальность, полноту охвата, точность определений и т.п. Её задача: 1) на простых примерах познакомить с OCL тех, кто никогда не слышал об этом языке, 2) а для тех, кто о нём слышал, возможно, открыть новые способы его применения.

Дано: собственные и аутсорс-проекты, некоторые участники работают удаленно.

Требуется: необходимо быстро назначать задачи исполнителям, планировать спринты, трекать выполнение и статусы, визуализировать процессы и делиться результатами с заказчиками.

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

Изначально сервисов было более 100, но постепенно список сокращался, и мы остановили наш выбор на трех, удовлетворяющих вместе наши нужды лучше всего: Jira, Slack и GanttPro. Но, если вдруг эти сервисы не помогут вам в планировании задач и работы с командой, делюсь с вами полным списком:

Процесс поиска очень часто усложняется тем, что все сервисы, как один, пишут «Лучший сервис, помогающий превратить ваши идеи в реальность и реализовать ваши проекты. Сегодня.». Так, а что вы делаете-то? Поэтому в этом списке без лишних эпитетов, только что какой сервис умеет. :)

Всем привет!

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

Привет, Хабр! Мы, Wrike, ежедневно сталкиваемся с потоком данных от сотен тысяч пользователей. Все эти сведения необходимо сохранять, обрабатывать и извлекать из них ценность. Справиться с этим колоссальным объёмом данных нам помогает Apache Spark.

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

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



Но обработка данных — это не проблема. Проблема в том, как и в каком виде сохранять результаты обработки, чтобы с ними можно было удобно работать. В процессе разработки нам приходилось несколько раз полностью менять подход к организации хранения данных. Мы начинали с таблиц MyISAM, использовали LSM-деревья и в конце концов пришли к column-oriented базе данных. В этой статье я хочу рассказать, что нас вынуждало это делать.

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

В конце октября вышла новая версия HP Vertica. Команда разработчиков продолжила славные традиции выпуска строительной техники BigData и дала кодовое имя новой версии Excavator.

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

Ознакомиться с полным списком нововведений можно в этом документе: http://my.vertica.com/docs/7.2.x/PDF/HP_Vertica_7.2.x_New_Features.pdf

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

Изменена политика лицензирования

В новой версии были изменены алгоритмы подсчета занимаемого размера данных в лицензии:

• Для табличных данных теперь при подсчете не учитывается 1 байт разделителя для числовых и дата-время полей;
• Для данных в зоне flex при подсчете размер лицензии считается, как 1/10 от размера загруженных JSON.

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

Добавлена официальная поддержка RHEL 7 и CentOS 7

Теперь можно будет разворачивать кластер Vertica на более современных ОС Linux, что думаю должно обрадовать системных администраторов.

Оптимизировано хранение каталога базы данных

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

В этой статье я хочу рассказать, как можно решать задачу impact анализа или анализа влияния в сложной, многоуровневой инфраструктуре корпоративного хранилища данных на примере нашего DWH в Тинькофф Банке.



Работая с DWH все наверняка задавались хоть раз вопросами:

• «Что будет, если поменять поле в таблице?»
• «На каких ETL процессах это скажется?»
• «Какие отчеты будут затронуты?»
• «Какие бизнес процессы могут пострадать?»

Ответить на этот вопрос как правило непросто, т.к. нужно просмотреть дюжину ETL процессов, потом залезть в BI инструмент, найти нужные отчеты, что-то держать в голове, помнить о том, что что-то там строится ручным кодом и всё это выливается в большую головную боль.
Даже самое порой безобидное изменение может сказаться, например, на отчете, который каждое утро приходит на почту к председателю правления банка. Немного утрирую, конечно:)

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

JetBrains приближается к релизу новой IDE для работы с SQL и базами данных. Мы запустили EAP программу год назад и благодарим всех её участников. Как всегда, ваши мнения и пожелания сделали наш продукт лучше.

Мы рады представить вам 0xDBE 1.0 Preview. Это отличный шанс попробовать нашу новую IDE и поделиться впечатлениями, что поможет нам сделать 0xDBE ещё лучше к моменту релиза.



Нам нравится название 0xDBE, но оно всё же рабочее, и к релизу мы выберем другое — более читаемое.

Ещё мы хотим лучше узнать наших пользователей и понять, как вы работаете с базами данных, поэтому составили небольшой опрос. Просим пройти его, на это уйдёт 5-8 минут. Среди тех, кто принял в нём участие, мы разыграем десять годовых лицензий на 0xDBE.

Итак, вот что мы добавили с момента запуска EAP:

Быстрая и точная интроспекция

В первую очередь, мы переработали алгоритм получения мета-информации о базе данных и расширили стандартную JDBC-интроспекцию для большинства поддерживаемых СУБД. Помимо увеличения скорости это привело к улучшениям в графическом интерфейсе — теперь объекты базы данных сгруппированы по типам:



Управление объектами БД

При нажатии Ctrl+F6 (Cmd-F6 для OS X) на имени таблицы в текстовом редакторе или в окне Database view открывается окно Modify Table, в котором можно добавлять и удалять столбцы, менять их свойства, добавлять и удалять ключи и индексы. В реальном времени генерируется DDL-скрипт, который будет выполнен для этих изменений:



Текстовый поиск

Теперь доступен текстовый поиск по результату запроса. Например, вам нужно найти данные, а столбец забыли. Есть поддержка регулярных выражений:

В этой статье я хочу рассказать про следующий этап развития DWH в Тинькофф Банке и о переходе от парадигмы классического DWH к парадигме Data Lake.

Свой рассказ я хочу начать с такой вот веселой картинки:



Да, ещё несколько лет назад картинка была актуальной. Но сейчас, с развитием технологий, входящих в эко-систему Hadoop и развитием ETL платформ правомерно утверждать то, что ETL на Hadoop не просто существует но и то, что ETL на Hadoop ждет большое будущее. Далее в статье расскажу про то, как мы строим ETL на Hadoop в Тинькофф Банке.

Интерес к технологиям Big Data постоянно растет, а сам термин приобретает все большую популярность, многие люди хотят поговорить об этом, обсудить перспективы и возможности в этой области. Однако немногие конкретизируют — какие компании представлены на этом рынке, не описывают решения этих компаний, а также не рассказывают про методы, лежащие в основе решений Big Data. Область информационных технологий, относящихся к хранению и обработке данных, претерпела существенные изменения к настоящему моменту и представляет собой стремительно растущий рынок, а значит лакомый кусок для многих всемирно известных и небольших, только начинающих, компаний в этой сфере. У типичной крупной компании имеется несколько десятков оперативных баз данных, хранящих данные об оперативной деятельности компании (о сделках, запасах, остатках и т.п.), которые необходимы аналитикам для бизнес-анализа. Так как сложные, непредвиденные запросы могут привести к непредсказуемой нагрузке на оперативные базы данных, то запросы аналитиков к таким базам данных стараются ограничить. Кроме того, аналитикам необходимы исторические данные, а также данные из нескольких источников. Для того чтобы обеспечить аналитикам доступ к данным, компании создают и поддерживают так называемые хранилища данных, представляющие собой информационные корпоративные базы данных, предназначенные для подготовки отчетов, анализа бизнес-процессов и поддержки системы принятия решений. Хранилища данных служат также источником для оценки эффективности маркетинговых кампаний, прогнозированию, поиску новых возможных рынков и аудиторий для продажи, всевозможному анализу предыдущих периодов деятельности компаний. Как правило, хранилище данных – это предметно-ориентированная БД, строящаяся на временной основе, т.е. все изменения данных отслеживаются и регистрируются по времени, что позволяет проследить динамику событий. Также хранилища данных хранят долговременные данные — это означает, что они никогда не удаляются и не переписываются – вносятся только новые данные, это необходимо для изучения динамики изменения данных во времени. И последнее, хранилища данных, в большинстве случае, консолидированы с несколькими источниками, т.е. данные попадают в хранилище данных из нескольких источников, причем, прежде чем попасть в хранилище данных, эти данные проходят проверку на непротиворечивость и достоверность.

Продолжаем цикл статей о технологиях, использующихся в работе хранилища данных (Data Warehouse, DWH) нашего банка. В этой статье я постараюсь кратко и немного поверхностно рассказать о Greenplum — СУБД, основанной на postgreSQL, и являющейся ядром нашего DWH. В статье не будут приводиться логи установки, конфиги и прочее — и без этого заметка получилась достаточно объёмной. Вместо этого я расскажу про общую архитектуру СУБД, способы хранения и заливки данных, бекапы, а также перечислю несколько проблем, с которыми мы столкнулись в ходе эксплуатации.



Немного о наших инсталляциях:

• проект живёт у нас чуть больше двух лет;
• 4 контура от 10 до 26 машин;
• размер БД около 30 Тб;
• в БД около 10000 таблиц;
• до 700 queries per second.

За тем, как оно работает, прошу под кат!