Большие данные по определению не умещаются в оперативной памяти сервера, а инструменты для работы с ними — в память инженера. Эти инструменты возникают снова и снова, в разных компаниях и университетах, дополняя, модифицируя и замещая друг друга. Единообразием тут даже не пахнет. Дата-инженеры и дата-сайентисты говорят, пишут и думают на различных языках.
Поэтому при подготовке этой коллекции мы с помощью экспертов из Ростелекома постарались решить несколько задач. Во-первых, дать представление — для чего возникли и используются те или иные инструменты управления большими данными. На примерах показать, как они выглядят и работают. И во-вторых, обязательно найти кейсы их применения в компаниях, которых без Big Data, наверное, просто не было бы.
Поэтому при подготовке этой коллекции мы с помощью экспертов из Ростелекома постарались решить несколько задач. Во-первых, дать представление — для чего возникли и используются те или иные инструменты управления большими данными. На примерах показать, как они выглядят и работают. И во-вторых, обязательно найти кейсы их применения в компаниях, которых без Big Data, наверное, просто не было бы.
Дата-инженер, компаньон дата-сайентиста, отвечает за управление рабочими процессами, конвейерами обработки и ETL-пайплайнами. Статья начинается со своеобразной пирамиды Маслоу, а ещё сюда подходит метафора цирковой пирамиды, в которой дата-инженер — это самый могучий атлет, тот гигант, на плечах которого стоят аналитики данных и специалисты по машинному обучению. Основа его мощи — Hadoop, Spark, Cassandra. Он знает Java, а может быть, даже и Scala. А в облаках ему знакома каждая платформа.
Вопрос:
Может ли дата-сайентист всё-таки обойтись без дата-инженера и, как Мюнхгаузен, поднять себя самого за волосы? В каких масштабах и каких задачах? И надо ли, чтобы пайплайн стал таким прозрачным, что дата-сайентисты забудут о существовании дата-инженеров?
В несложных проектах роли дата-сайентиста и дата-инженера может совмещать один человек. В крупных же компаниях требуется собирать много данных из разных систем и за каждый процесс отвечает отдельный дата-инженер или команда дата-инженеров. Дата-сайентисты же занимаются только функциями моделирования и анализа.
Евгения Гертовская
руководительница направления системной разработки
Да, DS может обойтись без DE, при этом область применения DS будет существенно сужаться, так как знать все системы компании, особенно крупной, невозможно. Кроме того, процесс станет сильно медленнее, ведь будет уходить время на изучение систем вместо работы с моделями и данными.
Михаил Солоницын
архитектор проектов
Архитектура хранилища очень масштабная, чтобы осилить её только одним направлением. Можно, конечно, чтобы DS выполнял и подготовку данных, и анализ архитектуры. Но давайте не забывать хорошую поговорку: «За двумя зайцами погонишься…» Можно попробовать как-то оптимизировать домены, управлять шаблонными действиями, но полностью обеспечить под ключ решение для потребителей, на мой взгляд, не получится.
Илья Тищенко
архитектор проектов
Чтобы дата-сайентист мог начать работу, дата-инженер создаёт инфраструктуру хранения и обработки данных. Современный пайплайн данных состоит из трёх шагов: Extract, Transform и Load, из первых букв этих слов и составлена аббревиатура ETL. Есть десятки фреймворков ETL, какой из них выбрать? Кроме того, ETL могут быть SQL- и JVM-ориентированные. И есть множество моделей данных, позволяющих найти компромисс между лёгкостью создания аналитических запросов и сложностью поддержки. Одна из популярных — схема звезды. Автор делится примером построения пайплайна из опыта Airbnb и приводит пример запроса с использованием Airflow.
Вопрос:
Действительно ли популярна схемы звезды за пределами Airbnb? Какие модели используются сегодня? Хранилище данных — конечная точка ETL, дальше — только модели ML, принятие решений и управление?
Схема звезды — один из паттернов при создании модели в хранилищах данных, «одна из наиболее популярных [схем]» — как сказано в статье. Сейчас используются разные модели и подходы при проектировании ХД — модели «звезда» и «снежинка», якорная модель, Data Vault.
Нельзя сказать, что хранилище данных — конечная точка ETL. Кроме доставки данных до хранилищ ETL-процессы также разрабатывают для трансформаций данных внутри хранилищ — процессы работают между слоями, для расчётов витрин, агрегатов.
Нельзя сказать, что хранилище данных — конечная точка ETL. Кроме доставки данных до хранилищ ETL-процессы также разрабатывают для трансформаций данных внутри хранилищ — процессы работают между слоями, для расчётов витрин, агрегатов.
Евгения Гертовская
руководительница направления системной разработки
Когда нужна пакетная (batch), а когда потоковая обработка (streaming)? Чем аналитика товарных запасов отличается от аналитики веб-портала? Базовый инструментарий для обработки потоков данных — это загрузчик данных, шина обмена и хранилище данных. Загрузить данные помогут Apache Flue, Apache NiFi и StreamSets. Для обмена популярны Kafka и RabbitMQ. Хранить данные можно в HDFS, Kudu, ClickHouse и т. д. В качестве практического примера в статье построен пайплайн для сбора виртуального пользовательского следа (clickstream) — ценных данных для маркетологов. Путешествие данных начинается с захвата их через Divolte, продолжается полётом в «Кафку» и завершается прибытием в ClickHouse.
Вопрос:
Каков сегодня тренд? Можно ли сказать, что пакеты уходят в прошлое и потоки данных преобладают в любом бизнесе? Что является драйвером изменений?
Пакетная загрузка — самый быстрый способ передачи большого объёма данных и в обозримом будущем никуда не исчезнет. Одним из главных двигателей в развитии потоковой обработки сегодня является скорость принятия оперативных управленческих решений: принять решение о выдаче кредита прямо сейчас, показать рекламу на основании 10 последних запросов…
Михаил Солоницын
архитектор проектов
Нет универсальных инструментов. Каждый класс инструментов хорош в одних задачах, но не обеспечивает требования в других. Нельзя сказать, что пакеты уходят в прошлое, основываясь только на появлении новых инструментов. Они лишь только дополняют общий стек, что покрывает больше задач, оптимизируя затраты и повышая производительность. Драйвером изменений всегда является потребитель. Если есть спрос, то появятся и предложения.
Илья Тищенко
архитектор проектов
Big Data начинаются тогда, когда данные становятся так велики, что ни за какие разумные деньги уже нельзя купить достаточную конфигурацию, чтобы все данные поместились в памяти одного сервера. Новые подходы к параллельной обработке попали в центр внимания после того, как был предложен MapReduce. Подсчёт частот слов во входной коллекции файлов, распределённый grep, инвертирование графа Всемирной паутины и поискового индекса — все эти задачи распараллеливаются при помощи известных из функционального программирования map и reduce. Параллельное программирование этих и многих других задач стало доступным широким кругам разработчиков. Приверженцы обязательного чтения классических статей могут обратиться и к статье авторов на английском языке.
Вопрос:
Автор утверждает: «Без MapReduce ты не можешь утверждать, что твоя платформа поддерживает Big Data!». Просто провокационное заявление? Или Big Data без MapReduce — это, возможно, и терабайты, но не настоящая Big Data, а что-то в стороне от сегодняшнего мейнстрима?
Заявление, на мой взгляд, слишком смелое. Можно его сделать про класс подобных средств. Гибкие средства реализации распределённой обработки данных, как MapReduce, и альтернативы (Tez, Spark и т. п.) обеспечивают свойство универсальности, без которого нет современных платформ Big Data.
Роман Генис
архитектор проектов
MapReduce — это один из фреймворков, но он не обязателен для решения задач Big Data.
Автор также это указывает в статье: «Существует множество альтернативных программных моделей, работающих с большими данными, которые могут даже оказаться лучше или гибче, чем MapReduce, но тот однозначно может считаться самым упрощённым, хотя, может быть, и не самым эффективным».
Скорее имеются в виду пользовательские ожидания от платформ для Big Data (где пользователи — это команда, выбирающая платформу для разработки), а не обязательность использования в Big Data.
Автор также это указывает в статье: «Существует множество альтернативных программных моделей, работающих с большими данными, которые могут даже оказаться лучше или гибче, чем MapReduce, но тот однозначно может считаться самым упрощённым, хотя, может быть, и не самым эффективным».
Скорее имеются в виду пользовательские ожидания от платформ для Big Data (где пользователи — это команда, выбирающая платформу для разработки), а не обязательность использования в Big Data.
Евгения Гертовская
руководительница направления системной разработки
Кроме MapReduce существуют и другие варианты обработки больших объёмов данных, но, как правило, все они основаны на разделении одного набора данных на кусочки для параллельной обработки.
Михаил Солоницын
архитектор проектов
Apache Hadoop
Более пятнадцати лет назад инженеры Google описали изобретённую ими распределённую файловую систему GFS и парадигму обработки больших данных MapReduce. Идея всех захватила, и вскоре появился Hadoop — проект с открытым кодом на Java. А чтобы отобразить привычные SQL-запросы в job’ы Hadoop, возникли фреймворки Apache Hive и Apache Pig — движки языков SQL-подобных запросов. Развитием GFS стала файловая система HDFS, а аналогом использующей её проприетарной базы данных BigTable — HBase.
Вопрос:
Благодаря каким ключевым достоинствам экосистема Hadoop до сих пор используется и сохраняет популярность?
Главное ключевое достоинство — это стоимость хранения и обработки массивных данных. Также очень важны для неугасающего распространения широко освещённый опыт применения и распространившаяся экспертиза. Профессиональное сообщество верит в Hadoop благодаря многочисленным удачным применениям (внедрениям) командами тысяч организаций по всему миру, в т. ч. лидерами, на протяжении десятка лет. К тому же крупные вендоры приложили множество усилий, чтобы проложить Hadoop дорогу в индустрии.
Роман Генис
архитектор проектов
Hadoop относительно дешёвая платформа для хранения большого объёма данных. При этом есть хорошие возможности для масштабирования при развитии системы и увеличении объёма данных. Hadoop как набор утилит, библиотек позволяет выбрать те, которые требуются компании для решения её задач.
Евгения Гертовская
руководительница направления системной разработки
Среди достоинств можно выделить: пониженные требования к аппаратному обеспечению, Open-Source-реализация, наличие большого сообщества и де-факто стандарт в хранении большого объёма данных и работе с ним.
Михаил Солоницын
архитектор проектов
Open Source — это одно из достоинств данной системы. Интерес разработчиков в том, чтобы на базе одного продукта реализовать и покрыть большинство решаемых задач.
Илья Тищенко
архитектор проектов
По мере коммерциализации технологий бинарные сборки популярных дистрибутивов, которые раньше были в открытом доступе, уходят в платную подписку. Для тех, кто не хочет переходить на платную версию, но хочет использовать свежие версии компонентов кластера, в статье рассказано про Arenadata Hadoop — новый и пока ещё мало кому известный дистрибутив отечественной разработки.
Hadoop — не монолитный продукт, а множество инструментов вокруг распредёленной файловой системы HDFS. При установке бинарных версий компонентов Hadoop всегда возникает вопрос о совместимости загруженных версий компонентов между собой. Эту проблему помогает решить сборка с помощью Apache Bigtop. Bigtop позволит выполнить сборку из maven-репозиториев Apache, прогнать тесты и собрать пакеты.
Онлайн-конференция Ростелекома DataTalks 2.0
DataTalks 2.0 — конференция по управлению данными, которую организует Ростелеком. Первый день проходит в форме лектория для начинающих специалистов. Второй — в формате разговоров с CDO.
Как эффективно управлять данными? Какие подходы к работе с большими данными сейчас популярны? Какие проблемы находятся в фокусе внимания CDO России? И кто такие CDO, которые на конференции дискутируют на темы построения Data Governance и внедрения data-driven-культуры в корпорациях? Об этом — в видеодокладах конференции.
Вопрос:
Каково главное направление конференции Data Talks 2.0? Что ожидается на этой конференции в 2021 году?
На DataTalks 2.0 мы сосредоточились на вопросах, которые были недораскрыты на первом курсе лекций: архитектура хранилища, качество данных, DataOps и MLOps. Самый важный вопрос, который мы хотели осветить на DataTalks 2.0, — подходы к построению Data Governance. Для внедрения дата-инициатив в компаниях важны не только технологии, но и люди и процессы. Вопросы баланса между ключевыми компонентами Data Governance волнуют каждого, кто работает в этом направлении и задумывается об эффективности.
Мы пока не готовы анонсировать программу DataTalks 3.0. Но мы будем раскрывать темы, о которых не успели поговорить на предыдущих мероприятиях. Это будет интересно и начинающим, и профессионалам.
Мы пока не готовы анонсировать программу DataTalks 3.0. Но мы будем раскрывать темы, о которых не успели поговорить на предыдущих мероприятиях. Это будет интересно и начинающим, и профессионалам.
Марина Кормщикова
директор направления департамента управления справочной информацией
Какие задачи можно распараллелить на большом кластере при помощи Hadoop? Это, к примеру, быстрый и регулярный обход спайдерами URL-ов. Масштаб задачи — 40 миллиардов адресов, ресурс — 170 серверов. Каждый день спайдеры скачивали около миллиарда страниц. Разработчики поиска Mail.ru реализовали патч, который ускорил проходы по таблице HBase. Разработчики переложили формирование очередей, разбор страниц и импорт ссылок на MapReduce, а сам краулер стал выполнять только функцию скачивания.
Вопрос:
Какие ещё крупные задачи можно реализовать на Hadoop?
На Hadoop достаточно широко распространены архивы детальных исторических данных, в т. ч. не структурированных. Дешёвое накопление в одном месте данных за старые периоды из всех бизнес-систем организаций даёт возможность в будущем получать пользу, даже если мы сейчас не представляем, какого рода она будет и на какой обработке будет реализована. Можно сказать, что Hadoop хорош как стратегическое средство накопления данных.
Роман Генис
архитектор проектов
Hadoop может использоваться как основа для Data Lake, кроме того на этой экосистеме можно выполнять множество распределённых задач — обработка научных данных (статистика, химия, генетика, и т. д.).
Михаил Солоницын
архитектор проектов
Доклады «Яндекса»
Парадигма MapReduce развивается и за пределами Hadoop. В «Яндексе» построили систему YT, где есть свои аналоги экосистемы Hadoop: распределённая файловая система, хранилище метаинформации, вычислительный фреймворк, «ключ-значение» и так далее. При помощи подхода MapReduce реализован планировщик заданий («джобов»).
Вопрос:
Много ли у нас компаний, которым недостаточно Hadoop? Каков должен быть масштаб задач, чтобы пришлось строить собственную альтернативу?
На мой взгляд, здесь вопрос скорее в позиционировании компании на IT-рынке. Надо понимать, что «Яндекс» и Mail.ru являются IT-компаниями и рассматривают новые технологии (Big Data, in-memory, key-value СУБД и прочее) как свой потенциальный актив, в котором они могут создавать дополнительную ценность и далее монетизировать её. Для этого в IT-компаниях есть команды архитекторов, аналитиков, разработчиков и тестировщиков решений. Сложно представить, чтобы компании ритейла, банковского или нефтегазового секторов так же активно инвестировали собственные ресурсы в создание новых технологий. За исключением компаний, которые выбрали свою стратегическую цель создания цифровой экосистемы и начали выходить за рамки своей профильной деятельности.
Сергей Семененко
директор департамента технологического развития управления данными
Влияет не только масштаб, но и другие условия, такие как специфика отрасли, задач. У всех больших компаний есть специфика компании, задач, архитектуры, и часто решения, первоначально разработанные для другой специфики, сложно использовать (в том числе и Hadoop).
Евгения Гертовская
руководительница направления системной разработки
У Hadoop, как у любой системы, есть свои сильные и слабые стороны, и если задачи попадают в область слабых сторон Hadoop, например работа, требующая консистентного состояния данных, то это повод искать или делать альтернативу.
Михаил Солоницын
архитектор проектов
Зависит от задачи. Нецелевое использование Hadoop приведёт к тому, что компания откажется от него и пойдёт в сторону другого решения. При выборе нужно сопоставить возможности продукта и задач, которые нужно реализовать.
Илья Тищенко
архитектор проектов
Переводная обзорная статья Радека Островски знакомит со Spark, приводит примеры использования и образцы кода на языке Scala. Рассказано про ядро — движок для крупномасштабной параллельной обработки данных, язык запросов Spark SQL.
Основная цель доклада Александр Борисова — показать, что Java-девелопер может использовать Spark, а изучать Scala, на котором написан Spark, — приятно, но не обязательно. Заодно автор развенчивает ряд мифов. Например, о том, что Spark — это примочка для Hadoop и без неё работать не может, и о том, что Spark несовместим со Spring. Один из многочисленных примеров (на Java) анализирует тексты Pink Floyd и делает вывод, что слова в них — те же самые, что в песнях Кэти Перри и Бритни Спирс.
Вопрос:
Писали, что Spark в десятки раз быстрее Hadoop. Однако экосистема Hadoop живее всех живых. В чём дело? Дата-инженеры не хотят знакомиться со Scala?
Как раз благодаря Spark и многим другим движкам Hadoop и развивается. Дополнительные технологии расширяют возможности применения Hadoop.
Роман Генис
архитектор проектов
Scala — относительно новый язык с достаточно высоким порогом входа, по сравнению с тем же SQL (даже на Hive). Людей, знающих Scala, значительно меньше, чем Java. Кроме того, уже сложился огромный объём legacy. И несмотря на всё это Spark активно развивается и увеличивает свой объём рынка.
Михаил Солоницын
архитектор проектов
Потоковая обработка данных становится основным способом работы с Big Data. Например, при обработке данных сенсоров в IoT. Данные выстраиваются в очередь и передаются в виде сообщений. Два популярных инструмента рассылки сообщений — Apache Kafka и RabbitMQ. Kafka масштабируется на триллионы сообщений в день. В серии статей, переведённой специалистами ITSumma, Джек Ванлайтли, один из разработчиков RabbitMQ, в деталях объясняет и сравнивает устройство, функции и возможности обеих платформ.
Вопрос:
Сохраняется ли окно возможностей для других систем или Kafka уже вытеснила всех? За счёт какого ключевого преимущества? И чего остро не хватает Kafka, если другие системы продолжают завоёвывать популярность?
Окно возможностей сохраняется. Не всем задачам и компаниям требуется масштабируемость, и при этом есть другие требования. В статье автор и приводит те преимущества, которые есть у RabbitMQ. При выборе архитектуры анализируются преимущества разных продуктов и выбираются те решения, преимущества которых важны для требований в конкретном случае.
Евгения Гертовская
руководительница направления системной разработки
Kafka не умеет делать PUSH и Kafka не умеет делать PULL. Соответственно, в каждой реализации надо делать свои методы по размещению данных в очереди и их извлечению. Используя только Kafka — затруднительно сделать систему с гарантированной доставкой.
Михаил Солоницын
архитектор проектов
Другие статьи этой серии:
В этой части акцент делается на Kafka, которая сравнивается с RabbitMQ с точки зрения событийно-ориентированных приложений.
В этой части рассмотрена кластеризация RabbitMQ для обеспечения отказоустойчивости и высокой доступности.
А здесь рассказано как отказоустойчивость и высокая доступность обеспечиваются в Kafka.
Тема завершающей части — устойчивость и надёжность механизмов обмена сообщениями. Автор приходит к выводу, что оба решения предлагают сравнимые гарантии, но не скрывает ряда преимуществ Kafka.
В итоге компания ITSumma прониклась проблемой профессионального, грамотного и качественного перевода настолько, что начала сама издавать книги. И начала, разумеется, с книги про Kafka.
Какую долю рынка занимают реляционные базы данных, а какую отвоевали NoSQL? СУБД с открытым кодом заняли 49,98 % против 50,02 % у коммерческих, каков дальнейший тренд? Останется ли SQL доминирующим языком управления БД? Насколько быстро идёт переход баз данных в облака? Российская тенденция — переход на Open Source, и все СУБД, созданные в России, — ClickHouse, Tarantool и ветки PostgreSQL — с открытым кодом.
Вопрос:
Каковы мотивы предприятий, выбирающих российские СУБД для работы с большими данными? Реален ли процесс импортозамещения IT или крупные компании тайно продолжают приобретать Oracle или MS?
Мотивы разные, но уже сейчас есть требования российских регуляторов, а также большинство российских компаний хочет избежать рисков того, что зарубежным вендорам могут запретить иметь отношения с российскими компаниями. Большинство не хочет, чтобы в один прекрасный день их зарубежное ПО просто отключили или поддержка отказала им в гарантийном техническом обслуживании по форс-мажорным причинам.
Роман Генис
архитектор проектов
Один из основных мотивов — требования по импортозамещению. Также на выбор СУБД влияют требования, которые накладываются на систему, в том числе доступность поддержки, цена владения, возможности регистрации разработанных продуктов в реестре российского ПО. СУБД Oracle продолжает использоваться широко, это не тайна — не все крупные компании относятся к госсектору. СУБД Oracle зарекомендовала себя как очень отказоустойчивая, что является критичным для многих систем (например, в банках).
Евгения Гертовская
руководительница направления системной разработки
В использовании Oracle нет никакой тайны, но Oracle — это огромный комбайн, и если вы не используете и 30 % его возможностей, а при этом платите за всё — есть смысл поискать что-то реализующее необходимые вам функции, возможно найденное решение выполняет достаточный набор функций и при этом будет лучше, чем импортные аналоги.
Михаил Солоницын
архитектор проектов
Мы не можем игнорировать требования регулирующих органов. Российские решения — это Open Source + опыт разработчиков и, как итог, конкурентное решение. Но нельзя сказать, что текущие архитектуры в один момент смогут отказаться от мирового бренда, на котором долгие годы строились процессы и функционал. Процесс замещения если и возможен, то только с позиции долгого и глобального рефакторинга. И конечно, применения в новых решениях.
Илья Тищенко
архитектор проектов
В статье рассказано о видах NoSQL — хранилищах «ключ-значение» (Redis, Memcached и др.), документоориентированных БД (MongoDB, CouchDB, Elasticsearch), колоночные БД (HBase, Cassandra и т. п.), графовые БД (Neo4j), мультимодельные BD (FoundationDB, ArangoDB, OrientDB). Подходы отличаются и способами хранения данных — в памяти, со снапшотами и т. п. Понять разницу в назначении и возможностях БД поможет CAP-теорема, которая утверждает, что из трёх полезных качеств — доступность, согласованность и устойчивость к разрывам сети — обеспечить можно только два. Итак, для каких же задач лучше подходит каждый из инструментов?
Вопрос:
Сообщалось, что Эрик Брюэр отрёкся от CAP-теоремы, но ему не поверили. Итак, что делать, если нужны все три грани философского камня — и доступность, и согласованность и устойчивость к разрывам? Каковы самые успешные новые попытки изобрести «вечный двигатель»?
Также сообщалось, что, по словам Брюэра, он хотел, чтобы сообщество начало дискуссию о компромиссах в распределённых системах. Как ни относиться к CAP-теореме, а вопросы компромиссов стоят перед разработчиками. При разработке системы определяют более критичные аспекты для решения бизнес-задачи и стараются минимизировать риски по 3-му аспекту.
Евгения Гертовская
руководительница направления системной разработки
Начинать знакомиться с NoSQL проще всего с Redis. Это одно из самых популярных и простых хранилищ «ключ-значение». А если что-то забылось, то есть шпаргалка.
Redis Best Practices в трех частях
В серии из трёх статей — коллекция паттернов, которые рекомендует сам разработчик, компании Redis Labs. Это не единственные способы использования Redis, но они могут послужить отправной точкой для решения конкретных проблем.
Пять примеров использования Redis на практике в компании ManyChat — кэширование, очереди, блокировки, ограничение количества запросов к API и pub/sub. А pub/sub — это механизм для отправки сообщения всем подписчикам.
MongoDB — документоориентированная БД с открытым исходным кодом. Оболочка поддерживает JavaScript, а данные хранятся в бинарном JSON (BSON). Согласитесь, что очень удобно, когда в браузере есть JavaScript, на сервере крутится Node. js, а в базе данных — тоже JavaScript! Неудивительно, что MongoDB — одно из самых популярных NoSQL-решений. Как быстро развернуть MongoDB? Когда и как применять? Показывает Иван Ремень, руководитель направления серверной разработки в «Ситимобил».
Сергей Загурский, отвечающий за инфраструктуру бэкенда в Joom, на модели стартапа рассказывает о проблемах, возникающих при росте нагрузки. Стартап запускает фичи, приходят пользователи. На MongoDB сваливается нагрузка, о которой создатели нового сервиса и не мечтали. Как реализовать горизонтальное масштабирование?
Хотя схема в MongoDB необязательна, Фил Фактор считает, что она критически важна. Сохранить документы без схемы можно быстро и просто, зато извлечь будет долго и сложно. Большие документы (больше 16 МБ) — источник проблем с производительностью. Большие массивы — тоже, лучше, чтобы количество их элементов не приближалось к четырёхзначному числу. И ещё двенадцать лайфхаков.
Elastic — вероятно, самая популярная у разработчиков поисковая система. Что главное в Elastic, почему он работает именно так и для чего его стоит использовать, а где лучше выбрать что-то попроще? Автор статьи приводит пример реализации поиска в коллективном блоге по всем материалам и пользователям.
В компании 2ГИС есть проект InfoRussia, с помощью которого операторы звонят и сверяют карточки организаций. В базе хранятся 4 миллиона карточек с данными об организациях России, общий размер которых — более 150 ГБ. В статье рассказано, как компания использует Elasticsearch для организации колл-центра.
Приложения — это чёрные ящики. Их работу нужно постоянно мониторить, и системы логирования — обязательный инструмент, без которого не обойтись в процессе. На рынке много систем логирования, как открытых, так и проприетарных. Как выбрать оптимальную? Компания 1cloud изучила более 50 различных решений и выделила четыре: Fluentd, Graylog, Logalyse и Logstash. И выбрала стек ELK: Elastic — Logstash — Kibana. Каковы аргументы?
Вопрос:
Какие факторы — самые важные при выборе системы логирования?
Как с любым промышленным ПО, важна производительность на требуемых объёмах данных и количестве операций за единицу времени, гибкость, масштабируемость, качество, наличие поддержки и документации, уровень сложности в освоении и получении экспертизы, стоимость покупки и владения.
Роман Генис
архитектор проектов
При помощи Elasticsearch в «Одноклассниках» решили вопрос лог-менеджмента. В четырёх дата-центрах находится 18 тысяч различных источников логов. Пётр Зайцев, системный администратор «Одноклассников», делится опытом — про архитектуру и подводные камни решения. Вместо ELK-стека применяется Graylog, где под капотом работают Kafka и Zookeeper.
В Badoo (в 2018 году) функционировало несколько десятков самописных демонов, которые работали приблизительно на сотне серверов в четырёх дата-центрах. Для решения проблемы сбора и анализа логов компания предпочла закрытому решению от Splunk стек ELK. В статье описаны архитектура и реализация системы, которая собирает логи демонов, реализует поиск, строит визуализацию и присылает уведомления.
Александр Крашенинников из Badoo рассказывает, как обработать 1,6 млн событий в секунду при помощи аналитической платформы ClickHouse, созданной в «Яндексе».
Вопрос:
В чём главные преимущества ClickHouse и почему платформа стала хитом у российских разработчиков?
Идея, архитектура и соотношение производительности и стоимости внедрения выглядят красиво. Похоже, у многих команд, которые искали технологии для своих задач, совпали критерии и свойства ClickHouse. На интерес сообщества сильно повлияло освещение внедрения в самом «Яндексе», а также применение у лидеров отраслей, таких как «Тинькофф». Это важная причина, чтобы попробовать и самим оценить решение.
Роман Генис
архитектор проектов
Евгений Шадрин из Сбербанк Digital Ventures рассказывает про свой кейс использования NoSQL и что выделяет БД Tarantool, разработанную в Mail.ru, среди других решений. Tarantool использует встраиваемый язык Lua (тот же, на котором написаны приложения Roblox!). На нём и написаны примеры.
Badoo хранит временные ряды в Cassandra. Перед разработчиками Badoo встала задача о разработке распределённого хранилища временных рядов. Набор утилит RRDtool перестал справляться с нагрузкой. Список популярных Open-Source-решений на замену включал Graphite, OpenTSDB, InfluxDB, Druid и Elastic. Но выбор был сделан в пользу Cassandra. Как в ней хранить временные ряды? Каких результатов удалось добиться?
Вопрос:
В каких ситуациях Cassandra предпочтительнее HBase?
Cassandra более простой в применении продукт: он монолитен, без сложной модульности. Его проще поставить и настроить — это занимает меньше времени, чем разворачивать Hadoop для HBase. Получается, проверить, работает ли Cassandra, на вашей задаче и объёмах данных быстрее.
Роман Генис
архитектор проектов
В прошлом в «Одноклассниках» около 50 ТБ данных, обрабатываемых в реальном времени, хранились в SQL Server. Обеспечить быстрый, надёжный и при этом устойчивый к отказам доступ этим способом практически невозможно. Компания решила разработать NewSQL-хранилище, сочетающее отказоустойчивость, масштабируемость и быстродействие NoSQL с привычными для реляционных СУБД ACID-гарантиями. И эти гарантии компания сумела реализовать в Cassandra. Так родилась новая СУБД C*One.
Вспомним известную шутку — купите больше оперативной памяти у AWS, и ваши большие данные перестанут быть большими. Нужны ли Hadoop, Spark, Cassandra и Kafka, если ваш проект — не Yahoo!, не Facebook и не LinkedIn?
Вопрос:
Нужны ли описанные инструменты, если ваш проект — не «Одноклассники», Badoo, Yandex или Mail.ru? Тем более что все эти компании в итоге разрабатывают собственные платформы. Кто же — простые пользователи всех этих замечательных инструментов? Кому реально нужны Spark, Cassandra, Kafka?
Обмен сообщениями/событиями между бизнес-приложениями и БД — достаточно распространённая задача в любой, даже небольшой компании. Kafka не суперсложный в применении инструмент. Его можно достаточно дёшево и быстро начать применять, не обладая большими командами разработки и админов.
То же самое можно сказать и про Cassandra. И если вам нужна шустрая БД для большого количества данных «ключ-значение», то вполне достойный кандидат.
То же самое можно сказать и про Cassandra. И если вам нужна шустрая БД для большого количества данных «ключ-значение», то вполне достойный кандидат.
Роман Генис
архитектор проектов
На мой взгляд, необходимость обработки больших данных родилась задолго до появления IT-гигантов, однако ранее не было достаточно эффективных технических средств для выполнения этих ресурсоёмких операций. Задачи обработки больших данных не менее остро стоят сейчас в медицине, в науке (имеющиеся технологии позволяют исследователям обработать всего лишь 0,004 % данных Большого адронного коллайдера), в металлургии (для улучшения существующих технологий используется не более 5 % собираемых данных) и в других отраслях. Полагаю, что текущие технологии найдут себе достойное применение в этих областях, а также будет продолжен поиск новых технологий, отвечающих на новые вызовы современного мира.
Сергей Семененко
директор департамента технологического развития управления данными