Рубрика «big data» - 132

Конференция по большим данным и искусственному интеллекту AI&BigData Lab

Проект GeeksLab приглашает всех 5 марта в Одессу на конференцию «AI&BigData Lab», которая будет посвящена одной из самых популярных и обсуждаемых IT-тем – большим данным и искусственному интеллекту.

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

В выходные, 18-19 января, в Перми прошел чемпионат по программированию Capsidea Hackathon #1. Соорганизатором выступила компания Xsolla – платежная платформа для онлайн-игр. В событии приняли участие 19 команд, но только 10 вышли в финал и представили свои работы.

В течении 24 часов программисты работали над функциональным web-приложением на основе аналитической платформы Capsidea. Судьи не смогли выделить одного победителя, поэтому первое место разделили сразу три команды – Aardvarks, Kilo и Zillion Data. Финалисты получили приставки Sony PlayStation 4, признание авторитетных представителей индустрии и возможность развить свой стартап в успешный бизнес.

Хакатон от Xsolla и Capsidea: как за 24 часа создать 10 стартаповЧитать полностью »

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

Командная работа над интерфейсами

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

В результате мы стали жить в мире зацикленных исследований как в фильме «День сурка», задавая одни и те же вопросы и редко используя то, что мы уже знаем.

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

А началось все с личного кризиса.

Читать полностью »

Предыдущий пост: Что такое Teradata?

Как Teradata распределяет строки?

  • Teradata использует алгоритм хэширования для рандомного распределения строк таблицы между AMP-ами (преимущества: распределение одинаково, независимо от объема данных, и зависит от содержания строки, а не демографии данных)
  • Primary Index определяет, будут ли строки таблицы распределены равномерно или неравномерно между AMP-ами
  • Равномерное распределение строк таблицы ведет к равномерному распределению нагрузки
  • Каждый AMP отвечает только за свое подмножество строк каждой таблицы
  • Строки размещаются неупорядоченно (преимущества: не требуется поддержка сохранения порядка, порядок не зависит от любого представленного запроса)
Primary Key (PK) vs. Primary Index (PI)

Primary Key (первичный ключ) – это условность реляционной модели, которая однозначно определяет каждую строку.
Primary Index – это условность Teradata, которая определяет распределение строк и доступ.
Хорошо спроектированная база данных содержит таблицы, в которых PI такой же как и PK, а также таблицы, в которых PI определен в столбцах, отличных от PK, и может влиять на пути доступа.
Читать полностью »

в 16:11, , рубрики: big data, teradata, СУБД, метки: , ,

Предисловие: По работе мне пришлось изучать устройство базы данных Teradata, и оказалось, что в интернете почти нет информации, особенно на русском языке. Поэтому я решила собрать в кучу всю доступную информацию.

Стремительное увеличение объемов носителей информации и удешевление стоимости хранения данных привело к появлению методов, способных обеспечить более быстрый доступ к необходимым данным – индексы, хранение данных в отсортированном виде и т.п. Эти методы вполне успешно справляются со своей задачей, однако возрастающая конкуренция в мире заставляет искать новые, более быстрые, способы доступа к информации. «Кто владеет информацией, тот владеет миром». Основной интерес вызывают базы данных с традиционной реляционной моделью данных, отвечающие требованиям ACID (Atomicity, Consistency, Isolation, Durability — атомарность, согласованность, изолированность, надежность) и предназначенные для аналитики Больших Данных (Big Data).

Teradata – это параллельная реляционная СУБД, которая работает на операционных системах:

  • MP-RAS UNIX
  • Microsoft Windows 2000/2003 Server
  • SuSE Linux

Разнообразие поддерживаемых ОС — одна из причин, почему Teradata имеет открытую архитектуру.
Читать полностью »

Photon – масштабируемая, отказоустойчивая и географически распределенная система обработки потоковых данных в режиме реального времени. Система является внутренним продуктом Google и используется в Google Advertising System. Research paper [5], описывающие базовые принципы и архитектуру Photon, был представлен на научной конференции ACM SIGMOD в 2013 году.

В paper [5] заявлено, что пиковая нагрузка на систему может составлять миллионы событий в минуту со средней end-to-end задержкой менее 10 секунд.
* 'Скорость света' в заголовке — наглая ложь гипербола.

Google Photon. Обработка данных со скоростью света*
Читать полностью »

Dremelмасштабируемая система обработки запросов в режиме близком к режиму реального времени (near-real-time), предназначенная для анализа неизменяемых данных [4].

Авторы research paper [4] (среди которых, судя по всему, и наши соотечественники — Сергей Мельник и Андрей Губарев), в котором описываются базовые принципы и архитектура Dremel, заявляют, что система в силах:

  • выполнять агрегирующие запросы над боле чем над триллионом строк за секунды;
  • масштабируется на тысячи CPU;
  • предназначена для работы с петабайтами данных;
  • имеет тысячи пользователей внутри Google (дословно «at Google» [4]).

Dremel. Как Google считает в real time?
Читать полностью »

Spannerгеографически распределенная высокомасштабируемая мультиверсионная база данных с поддержкой распределенных транзакций. Хранилище было разработана инженерами Google для внутренних сервисов корпорации. Research paper [8], описывающий базовые принципы и архитектуру Spanner, был представлен на научной конференции 10th USENIX Symposium on Operating Systems Design and Implementation в 2012 году.

Spanner является эволюционным развитием NoSQL-предшественника – Google Bigtable. Сам же c Spanner относят к семейству NewSQL-решений. В research paper [8] заявляется, что дизайн Spanner позволяет системе масштабироваться на миллионы вычислительных узлов через сотни дата-центров и работать с триллионами строк данных.

Spanner. NewSQL хранилище от Google
Читать полностью »

Colossus (или GFS2) – это проприетарная распределенная файловая система от Google, запущенная на production-серверах в 2009 году. Colossus является эволюционным развитием GFS. Как и ее предшественник GFS, Colossus оптимизирована для работы с большими наборами данных, прекрасно масштабируется, является высокодоступной и отказоустойчивой системой, а также позволяет надежно хранить данные.

В то же время, Colossus решает часть задач, с которыми GFS не справлялась, и устраняет некоторые узкие места предшественника.
Colossus. Распределенная файловая система от Google
Читать полностью »

Задача выбора случайных строчек из таблицы довольно часто возникает перед разработчиками.
В случае, если используется СУБД MySQL, обычно она решается примерно следующим способом:

SELECT *
FROM users
WHERE role_id=5
ORDER BY rand()
LIMIT 10

Такой код работает крайне медленно для больших таблиц и когда задается условие WHERE, без WHERE или таблица небольшая, есть эффективные решения, например habrahabr.ru/post/54176/ или habrahabr.ru/post/55864/.
Но решений для случая большой таблицы и необходимости фильтровать по условию, получая при каждом запросе новые значения в сети я не нашел, поэтому описание моего способа под катом.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js