Эдвард Тафти икает и курит в сторонке.
Круговые диаграммы — зло, не важно в каком виде. Автор заметки советует нам отображать одномерную величину при помощи двумерной фигуры. Пожалейте краску в принтере.
Нельзя соединять дискретные значения прямыми линиями. Возьмем пример с продажами, в феврале продали 100 букетов, в марте — 1000. Соединение двух значений прямой линией означает, что продажи росли линейно в течение марта. Но это вранье. Большинство букетов было продано за 7 и 8 марта. Правильный график позволит лучше понять, что происходило на самом деле.
«Используйте один вид диаграммы для однотипных данных.» Плохой совет, дело не в типе данных, а в том, что они могут объяснить.
А с чем связана такая сложность? Вы пробовали переложить фотки в кассандру / hbase, которые предоставляют их коробки:
— избыточность данных (фактор репликации)
— доступ по ключу
— репликацию данных между датацентрами
— кэширование
— прекрасно работает на бытовом железе.
— горизонтально масштабируется
Супер, отличная статья. Я пытаюсь сделать предикт в другой предметной области, есть общие вопросы, можете рассказать:
1. Сколько у вас было независимых переменных в датасете для decision tree?
2. Как вы измеряли ценность вклада независимых переменных в значение?
3. Как вы оценивали качество дерева?
4. Как вы делили численные переменные на классы? Я пробовал руками, автоматическим дискретизатором, outcome = shit.
5. Использовали ли вы prunning для дерева?
6. Где можно почитать про «сначала факторы и корреляции (Байес), потом их влияние на итог (дерево решений).» не понял, о чем речь :)
Прямо сейчас у меня два исхода: либо чудовищно сложное дерево на сотни листов от 8 независимых переменных, либо десяток узлов с включенным prunning.
Отличительной чертой Cloudera также является стремление первыми предоставлять на рынке новые фичи
Вранье. HDP пушит самый свежаок, клоудера крайне консервативна. Я >2 лет сижу на клоудере. Единственное, что сделала нового клоудера, так это втащила спарк, который ставится при помощи человеко-машинного комплекса. Позже, эта проблема была устранена.
Hive — самая первая и до сих пор одна из самых популярных СУБД на этой платформе. В качестве языка запросов использует HiveQL — урезанный диалект SQL,
Бред, это не СУБД. Это транслятор SQL в каскад MR job. Про диалект так же спорно, он не ANSI compliant, это да. По сути, это клиентская тула. Просто посмотрите код, как он устроен. Где-то год назад в джире читал, что девелоперы озаботились о том, чтобы распилить хайв на модули. Потому что вместе с артефактом-jdbc хайва, вы еще получаете метастор и кучу всего, не относящегося к «дровам». Почитайте Programming hive, он по версии 0.8, но даст вам понять, почему это не СУБД.
HBase — это распределённая версионированная нереляционная СУБД
это не бд, это hashmap of hashmaps с рядом интересных свойств. Почитайте HBase definitive guide. Даже это вам даст понимание того, насколько hbase далек от СУБД.
Oozie
одно из самых вменяемых решений. Для отладки есть dryrun и e2e тесты. Для hive/impala и т.д. есть java action. Что у вас там за проблемы с либами, я вообще не понял. Что за пользовательские библиотеки? Делайте бандл и все что нужно коориднатору, воркфле кладите в lib каталог «приложения». Ози сам зацепит ресурсы в classpath. Не превращайте окружение в помойку джарников, и все будет хорошо.
Hue — Работает плохо, с ошибками и по настроению.
По настроению, ок, исчерпывающее описание.
Sqoop — на практике Sqoop 1 оказался, по сути, однопоточным и медленным
Бред, до 3-5 млн строк в минуту без каких-либо ухищрений/костылей, терадат и экзадат. Обычное загруженное хранилище оралка.
JDBC интерфейс в виде HiveServer2 работает откровенно плохо, а бросаемые ошибки мало связаны с настоящей причиной проблемы.
cool story. Откровенно плохо, это как, как это проявляется? Бросаемые ошибки связаны со спецификой инструмента. попробуйте beeswax интерфейс, тогда поймете, что значит плохо — DoS зукиперов и т.д.
Складывается ощущение, что автор нахватался чего-то по верхам и сделал поверхностный обзор на основе своего небольшого опыта.
Про flume, sqoop, oozie написан бред.
Основные преимущества TEZ, которые можно использовать прямо сейчас, это checkpointing и MRR jobs, когда reduce-фаза пишет локально, а не в HDFS, экономя кучу времени. Можно изменять алгоритм сортировки. Судя по диз. доку, TEZ всего лишь устраняет ограничения MR фреймфорка, в которые уперлись разработчики спустя годы после первого релиза. Все таки в 2007 году сложно было представить, что захотят юзеры в 2012
Хорошая оценочка пигу.
Но, честно говоря, я ни разу не слышал, чтобы её использовали на практике.
Чуваки типа по фану срелизили 0.13.0 версию, другие чуваки от безделия добавили pig-action в oozie, а третьи лежебоки добавили интерактивную веб-консоль в hue.
На каких фактах вы строите свои предположения и делаете выводы?
Напрямую писали? Я не видел фичи поиска online, понял, что вам надо быстро искать по накопленным данным. Пробовали копить данные час-два-сутки и делать BulkLoad в HBase в обход WAL?
Не стабильно — а как это проявлялось?
MemSQL’s distributed in-memory data management platform
С таким же детскими ограничениями. Потому ее тоже можно считать нашлепкой по сравнению с рыночными MPP, как и Impala. Я предлагаю не читать рекламные проспекты, а реально смотреть на жизнь. Ограничение по памяти, это серьезный стоппер. Суммарный терабайт памяти, это очень-очень мало. И, вам на заметку, сервера с 126-256 ГБ памяти стоят не дешево, это уже не low end и не commodity hardware.
стоимость самых дешевых узлов терадаты можно узнать?
Дорого, очень дорого :)
. А за стоимость Терадата/Экзадата можно поднять кластер не с одним десятком терабайт памяти
Встает вопрос о ToC. Что дешевле, обслуживать коробку Терадаты из 5-7 узлов, которые работают и каши не просят + имеют офф. саппорт, или стадо дешевого железа средней паршивости? Вы пробовали сделать DWH, хотя бы для хранения на базе хадупа? ToC, в итоге, выйдет в стоимость терадаты, которую нужно просто поставить и уже лить данные. С хадупом такой трюк не пройдет. Очень сложно, криво, косо, мало людей на рынке и у всех раздутые зарплаты по понятным причинам.
именно поэтому сейчас у многих в моде spark
У спарка нет ограничений по памяти. При желании, RDD можно хранить на диске. Потому у него прямо сейчас больше шансов на серьезный пром, чем у Импалы и прочих ин-мемори аналогов. И, как я понял со слов разработчиков Махута, в основном Спарк рассматривается как тул для реализации итеративных алгоритмов поверх HDFS. Объективно говоря, MR не подходит для итеративных алгоритмов. Он подходит для других задач.
чтобы собрать карту, где и что сейчас валяется
Не понял, как поверхностное описание работы НеймНоды помогает решать инженерную задачу по обновлению локаций блоков в режиме реального времени.
Мы ушли от темы, мой месседж в том, что продукты, называющие себя Database, MPP, и не способное решать задачи контекста, это не Database, MPP, а нашлепки. SQLite в контексте тестов Ruby On Rails, это база данных. В проме берут MySQL, Postgre. Потому что решаются пром задачи, для которых SQLite — неразумное ограничение и костыль.
MPP система, не способная выполнить Two-pass multi way merge sort любого объема данных при достаточном дисковом пространстве не может называться MPP. Это нашлепка, потому что рынок знает, эта проблема решена многими вендорами много лет назад. Память давно не ограничение, все извращаются, чтобы результат поскорее отправить пользователю.
Ну и зачем эта биг-дата, если есть ограничение на объем? Что с ней потом делать? Не отвечает требованиям и ожиданиям. Только многочасовые джобы через Хайв.
работа с MR в свое время показала, что чем меньше диска мы трогаем, тем спокойней на душе
Не понял мысль. Все MPP системы работают через диск. Например, самые дешевые узлы терадаты комплектуются десятками (40 и более) 15-тысячниками.
никто не говорит что они не база данных Это они говорят, что они База данных. Есть суть, есть контекст. В контексте Хадупа нет ни одной БД, либо нашлепки в виде Импалы, либо трансляторы SQL в граф MR джобов в виде Хайва. Про транзакции, ACID я вообще не говорю.
www.memsql.com издали напоминает закос под лямбда архитектуру. Только вот лямбда архитектура не предусматривает каких либо ограничений по памяти или диску.
Cloudera Impala is the industry’s leading massively parallel processing (MPP) SQL query engine that runs natively in Apache Hadoop.
MPP системы, это Терадата, Экзадата, Вертика и т.д. Если MPP система ограничена оперативной памятью, то это не MPP система, потому что есть рыночные стандарты де-факто и ожидания к MPP системе.
REFRESH, как по мне, является временным решением
костыль, проще говоря.
сделать доп слушателя к namenode и чекать любые изменения в положении блоков,
Неймнода не хранит информацию о блоках. ДатаНоды шлют блок-репорты о том, какие у них есть блоки. На основании репортов НеймНода получает знание о расположении блоков. Почему не сделали? Потому что ДатаНод сотни. Это сложная инженерная задача. Мы же не будем рассматривать БигДату на трех тестовых виртуалках :)
Оки, я вас понял.
Разница между нашлепкой и БД в ожиданиях. Лично я ожидаю, что БД может делать джоин через диск. А очень дорогая БД может делать распеределнный джоин на десятках дисков и десятков узлов. Кроме того, хотелось бы чтобы БД не нуждалась в ручном напоминании (REFRESH TABLE_NAME) о том, что блоки на блочном устройстве поменяли своё расположение на дисках и узлах.
Под нашлепкой я понимаю то, что ожидания не сосуществуют действительности.
Преимущества паркета:
1. Схема
2. Читальщики для Pig, hive, MR. Очень-очень удобные, с версии 1.4.3 В ранних версиях (до 1.2.5 включительно) есть куча проблем с чтением паркета из MR
3. Компрессия
По факту: avro+snappy и parquet+snappy. При раздутых размерах страниц и блоков паркета, можно добиться до +30% к сжатию по сравнению с avro+snappy. Из минусов — жрет память, если у вас на ноде менее 32 ГБ, можно допрыгаться до OOM и хард ресета узла.
4. Стр-ра файла представляет собой своеобразную сетку. Есть возможность селективного чтения, для того, чтобы вытащить значение из колонки, не обязательно читать весь ряд.
ORC обладает неоспоримым преимуществом — встроенным индексом. Если хранить сортированные файлы, то можно добиться устрашающего прироста производительности при джоинах и фулл-сканах.
Паркетчики грозятся вклеить индекс, и, тем не менее, его все еще нет, а в ORC он есть.
Как сомнительный плюс, Teradata приблуды для хадупа умеют работать с ORC.
Я пишу UDF для пига на jython (короткие функции фильтрации со счетчиками, например), Java (когда нужен перфоманс), Groovy (когда нужно написать прототип). Посмотрите документацию. pig.apache.org/docs/r0.10.1/udf.html
Java, Jython. JavaScript, Ruby добавлены в качестве эксперимента.
Импала даже HDFS толком-то не использует. Импаловые демоны кэшируют расположение блоков для того, чтобы при запросе locality factor был наивысшим. Если у вас периодически запускается HDFS balancer, то нужно делать REFRESH для таблиц, чтобы сбросить кэш локаций блоков, т.к. балансер перемещает блоки между датанодами. В отличие от MR, у Импалы нет слотов, она обеспечивает колоссальную экономию межузлового трафика. Можно добиться 100% data locality, если высаживать Демон импалы возле каждой ДатаНоды. И да, у импалы есть много-много недостатков. Это не база данных, а сёвая (язык Си ) нашлепка поверх файловой системы, где хранятся блоки HDFS.
Круговые диаграммы — зло, не важно в каком виде. Автор заметки советует нам отображать одномерную величину при помощи двумерной фигуры. Пожалейте краску в принтере.
Нельзя соединять дискретные значения прямыми линиями. Возьмем пример с продажами, в феврале продали 100 букетов, в марте — 1000. Соединение двух значений прямой линией означает, что продажи росли линейно в течение марта. Но это вранье. Большинство букетов было продано за 7 и 8 марта. Правильный график позволит лучше понять, что происходило на самом деле.
«Используйте один вид диаграммы для однотипных данных.» Плохой совет, дело не в типе данных, а в том, что они могут объяснить.
www.data-vis.ru/8-issledovaniya/20-rules 149 рублей.
— избыточность данных (фактор репликации)
— доступ по ключу
— репликацию данных между датацентрами
— кэширование
— прекрасно работает на бытовом железе.
— горизонтально масштабируется
projectlombok.org/features/Builder.html
projectlombok.org/features/Builder.html#singular
?
1. Сколько у вас было независимых переменных в датасете для decision tree?
2. Как вы измеряли ценность вклада независимых переменных в значение?
3. Как вы оценивали качество дерева?
4. Как вы делили численные переменные на классы? Я пробовал руками, автоматическим дискретизатором, outcome = shit.
5. Использовали ли вы prunning для дерева?
6. Где можно почитать про «сначала факторы и корреляции (Байес), потом их влияние на итог (дерево решений).» не понял, о чем речь :)
Прямо сейчас у меня два исхода: либо чудовищно сложное дерево на сотни листов от 8 независимых переменных, либо десяток узлов с включенным prunning.
www.youtube.com/watch?v=l9ivnxx_EoE
have a nice weekend :)
Вранье. HDP пушит самый свежаок, клоудера крайне консервативна. Я >2 лет сижу на клоудере. Единственное, что сделала нового клоудера, так это втащила спарк, который ставится при помощи человеко-машинного комплекса. Позже, эта проблема была устранена.
Бред, это не СУБД. Это транслятор SQL в каскад MR job. Про диалект так же спорно, он не ANSI compliant, это да. По сути, это клиентская тула. Просто посмотрите код, как он устроен. Где-то год назад в джире читал, что девелоперы озаботились о том, чтобы распилить хайв на модули. Потому что вместе с артефактом-jdbc хайва, вы еще получаете метастор и кучу всего, не относящегося к «дровам». Почитайте Programming hive, он по версии 0.8, но даст вам понять, почему это не СУБД.
это не бд, это hashmap of hashmaps с рядом интересных свойств. Почитайте HBase definitive guide. Даже это вам даст понимание того, насколько hbase далек от СУБД.
одно из самых вменяемых решений. Для отладки есть dryrun и e2e тесты. Для hive/impala и т.д. есть java action. Что у вас там за проблемы с либами, я вообще не понял. Что за пользовательские библиотеки? Делайте бандл и все что нужно коориднатору, воркфле кладите в lib каталог «приложения». Ози сам зацепит ресурсы в classpath. Не превращайте окружение в помойку джарников, и все будет хорошо.
По настроению, ок, исчерпывающее описание.
Бред, до 3-5 млн строк в минуту без каких-либо ухищрений/костылей, терадат и экзадат. Обычное загруженное хранилище оралка.
cool story. Откровенно плохо, это как, как это проявляется? Бросаемые ошибки связаны со спецификой инструмента. попробуйте beeswax интерфейс, тогда поймете, что значит плохо — DoS зукиперов и т.д.
Про flume, sqoop, oozie написан бред.
Основные преимущества TEZ, которые можно использовать прямо сейчас, это checkpointing и MRR jobs, когда reduce-фаза пишет локально, а не в HDFS, экономя кучу времени. Можно изменять алгоритм сортировки. Судя по диз. доку, TEZ всего лишь устраняет ограничения MR фреймфорка, в которые уперлись разработчики спустя годы после первого релиза. Все таки в 2007 году сложно было представить, что захотят юзеры в 2012
Хорошая оценочка пигу.
Чуваки типа по фану срелизили 0.13.0 версию, другие чуваки от безделия добавили pig-action в oozie, а третьи лежебоки добавили интерактивную веб-консоль в hue.
На каких фактах вы строите свои предположения и делаете выводы?
Не стабильно — а как это проявлялось?
еще одна уникальная возможность выстрелить себе в ногу, включив слабоуправляемый cluster-wide cache.
С таким же детскими ограничениями. Потому ее тоже можно считать нашлепкой по сравнению с рыночными MPP, как и Impala. Я предлагаю не читать рекламные проспекты, а реально смотреть на жизнь. Ограничение по памяти, это серьезный стоппер. Суммарный терабайт памяти, это очень-очень мало. И, вам на заметку, сервера с 126-256 ГБ памяти стоят не дешево, это уже не low end и не commodity hardware.
Дорого, очень дорого :)
Встает вопрос о ToC. Что дешевле, обслуживать коробку Терадаты из 5-7 узлов, которые работают и каши не просят + имеют офф. саппорт, или стадо дешевого железа средней паршивости? Вы пробовали сделать DWH, хотя бы для хранения на базе хадупа? ToC, в итоге, выйдет в стоимость терадаты, которую нужно просто поставить и уже лить данные. С хадупом такой трюк не пройдет. Очень сложно, криво, косо, мало людей на рынке и у всех раздутые зарплаты по понятным причинам.
У спарка нет ограничений по памяти. При желании, RDD можно хранить на диске. Потому у него прямо сейчас больше шансов на серьезный пром, чем у Импалы и прочих ин-мемори аналогов. И, как я понял со слов разработчиков Махута, в основном Спарк рассматривается как тул для реализации итеративных алгоритмов поверх HDFS. Объективно говоря, MR не подходит для итеративных алгоритмов. Он подходит для других задач.
Не понял, как поверхностное описание работы НеймНоды помогает решать инженерную задачу по обновлению локаций блоков в режиме реального времени.
Мы ушли от темы, мой месседж в том, что продукты, называющие себя Database, MPP, и не способное решать задачи контекста, это не Database, MPP, а нашлепки. SQLite в контексте тестов Ruby On Rails, это база данных. В проме берут MySQL, Postgre. Потому что решаются пром задачи, для которых SQLite — неразумное ограничение и костыль.
MPP система, не способная выполнить Two-pass multi way merge sort любого объема данных при достаточном дисковом пространстве не может называться MPP. Это нашлепка, потому что рынок знает, эта проблема решена многими вендорами много лет назад. Память давно не ограничение, все извращаются, чтобы результат поскорее отправить пользователю.
Было приятно с вами пообщаться, спасибо!
Ну и зачем эта биг-дата, если есть ограничение на объем? Что с ней потом делать? Не отвечает требованиям и ожиданиям. Только многочасовые джобы через Хайв.
Не понял мысль. Все MPP системы работают через диск. Например, самые дешевые узлы терадаты комплектуются десятками (40 и более) 15-тысячниками.
никто не говорит что они не база данныхЭто они говорят, что они База данных. Есть суть, есть контекст. В контексте Хадупа нет ни одной БД, либо нашлепки в виде Импалы, либо трансляторы SQL в граф MR джобов в виде Хайва. Про транзакции, ACID я вообще не говорю.www.memsql.com издали напоминает закос под лямбда архитектуру. Только вот лямбда архитектура не предусматривает каких либо ограничений по памяти или диску.
Пока что не понимаю идею сравнивать in-memory DB и MMP систему Импала (по словам её авторов)
www.cloudera.com/content/cloudera/en/products-and-services/cdh/impala.html
MPP системы, это Терадата, Экзадата, Вертика и т.д. Если MPP система ограничена оперативной памятью, то это не MPP система, потому что есть рыночные стандарты де-факто и ожидания к MPP системе.
костыль, проще говоря.
Неймнода не хранит информацию о блоках. ДатаНоды шлют блок-репорты о том, какие у них есть блоки. На основании репортов НеймНода получает знание о расположении блоков. Почему не сделали? Потому что ДатаНод сотни. Это сложная инженерная задача. Мы же не будем рассматривать БигДату на трех тестовых виртуалках :)
Веточкой промахнулся :)
Спасибо, пишу.
Разница между нашлепкой и БД в ожиданиях. Лично я ожидаю, что БД может делать джоин через диск. А очень дорогая БД может делать распеределнный джоин на десятках дисков и десятков узлов. Кроме того, хотелось бы чтобы БД не нуждалась в ручном напоминании (REFRESH TABLE_NAME) о том, что блоки на блочном устройстве поменяли своё расположение на дисках и узлах.
Под нашлепкой я понимаю то, что ожидания не сосуществуют действительности.
1. Схема
2. Читальщики для Pig, hive, MR. Очень-очень удобные, с версии 1.4.3 В ранних версиях (до 1.2.5 включительно) есть куча проблем с чтением паркета из MR
3. Компрессия
По факту: avro+snappy и parquet+snappy. При раздутых размерах страниц и блоков паркета, можно добиться до +30% к сжатию по сравнению с avro+snappy. Из минусов — жрет память, если у вас на ноде менее 32 ГБ, можно допрыгаться до OOM и хард ресета узла.
4. Стр-ра файла представляет собой своеобразную сетку. Есть возможность селективного чтения, для того, чтобы вытащить значение из колонки, не обязательно читать весь ряд.
ORC обладает неоспоримым преимуществом — встроенным индексом. Если хранить сортированные файлы, то можно добиться устрашающего прироста производительности при джоинах и фулл-сканах.
Паркетчики грозятся вклеить индекс, и, тем не менее, его все еще нет, а в ORC он есть.
Как сомнительный плюс, Teradata приблуды для хадупа умеют работать с ORC.
Java, Jython. JavaScript, Ruby добавлены в качестве эксперимента.