• Что помешало экипажу Crew Dragon выйти из корабля?
    0
    если перелогинюсь факты как-то изменятся?
  • Что помешало экипажу Crew Dragon выйти из корабля?
    –15
    Не всегда получается задуманное, например пока ракеты с ножками смогли снизить стоимость запуска спутников в космос только в два раза, хотя Маск надеялся в десять.


    стоимость пуска, если и снизилась то исключительно от того, что НАСА покрывает убытки от пусков частных спутников. каждый пуск транспортника уже в $280 млн обходится, в то время как древний и одноразовый прогресс те же 2.6 тонн к мкс доставляет за $60 млн.
  • Запускаем Apache Spark на Kubernetes
    0
    ну так из спарк шела то на других узлах запустятся экзекьютеры, там данных с прошлого пуска нет. нужен какой-то общий сторидж.
  • Запускаем Apache Spark на Kubernetes
    +1
    прочитал, но так и не понял главного. куда спарк экзекьюторы писать будут? каждый на свою машину?
    еще в тренде на k8s интересно чем конечный результат от спарка предполагается смотреть? что-то типа hive или impala ведь понадобится.
  • Топ 10 заблуждений о переносе Hadoop в облако
    0
    я такое видел, когда от многих тысяч баз данных hive metastore поплохело (GC + out of memory). но все легко решилось выделением ему побольше памяти.
    в этом плане врядли, есть реальные проблемы. просто 30+ узлов уже на дефолтных настройках не поедут.
  • Погружение в Delta Lake: принудительное применение и эволюция схемы
    0
    Эти ребята многое делают для развития спарка, я как-то априори склонен им скорее доверять.

    делают, но паркет со схемой и эволюцей схемы появился до них и до их настройки над паркетом.

    Ну, мне кажется что это скорее не бонус, а наоборот, фундамент. Все-таки, как вы себе представляете update, если транзакций нет?

    да легко. как у них работает — у них при апдейте пары срок в фолдере паркетов ищутся паркетники, где нужно заменить строки. найденные файлы целиком копируются, с модификациями. после этого в папочке лога добавится json. вот появление этого json и означает фиксацию транзакции. мягко говоря не самая захватывающая фишка. DWH мир уже давненько не пишет терабайты в единой транзакции, а давно заливают в параллель и делают что-то типа exchange partition.
  • Погружение в Delta Lake: принудительное применение и эволюция схемы
    0
    del
  • Погружение в Delta Lake: принудительное применение и эволюция схемы
    0
    по моему и статья бредовая. схема — она у паркетов, что под низом у delta lake, а то что delta lake тоже имеет схему и schema evolution, так это скорее следствие того, что delta lake надстройка над паркетом.
    а по транзакциям, транзакции тут вторичны. главная фишка delta lake то что он дает возможность делать update/delete/merge на файлки лежащие на hdfs. транзакции идут как бонус к невероятному к update на hdfs.
  • Facebook изменила концепцию Libra и отказалась от выпуска единой монеты
    0
    у дурова просто блокчейн, транзакции никто не контролирует. у цукенберга ноды контролирует консорциум. спецслужбы в теории смогут просить консорциум банить и откатывать транзакции.
  • Facebook изменила концепцию Libra и отказалась от выпуска единой монеты
    0
    тем что либра это консорциум жадных капиталистов. т.е. фсб или цру придется убедить консорциум банить транзакции. а там уже не только американцы, а те что американцы бабло зарабатывают далеко не только в сша.
  • Facebook изменила концепцию Libra и отказалась от выпуска единой монеты
    0
    у тебя там мелочь, которой «банк», если у него в тот день хорошее расположение духа, может позволит попользоваться. серьезную сумму за бугор российский «банк» не позволит перевести.
  • Переход от монолитного Data Lake к распределённой Data Mesh
    +1
    не понятно как такое может масштабироваться. имхо основная сложность больших энтерпрайзов не в размере, а то что данные идут с разных систем, разработанных или полученных вместе покупками конкурентов, которые одни и те же понятия по разному оформляют. если каждый источник сгружает данные так как ему удобно то потом каждый потребитель должен будет изобретать какие-то свои мапинги из источника в свои понятия, что бы получить что-то осмысленное. на большом кол-ве источников это быстро превратится в ад. опять же, у источника бизнес процессы меняются. источник добавил колонку is_deleted, теперь тучи потребителей должны переколбашивать свои etl. а что если они не готовы сейчас этим заняться?
    то что data owner должен сам рисовать выгрузки я согласен, но без каких-то централизованных структур в крупной организации никак. data owner должен интегрировать свои данные во что-то централизованное, корректно замапив свои понятие на некие общие.
  • Британские пользователи Azure жалуются на проблемы с доступом к сервису и отказ в создании новых VM в облаке Microsoft
    +1
    угу, а в рекламе втирали то что облака круты потом у что когда не надо ресурсы можно освобождать и не платить. а теперь вот оказывается, что облако круто, но есть нюанс :)
  • Тюнинг Firebird и Linux для БД размером 691 Гб с 1000+ пользователей
    0
    Тогда от PostgreSQL вы вообще бежите как черт от ладана?

    да. убер хорошо расписал как все хреново там где нет полноценного undo. собственно enterprisedb — основной вкладчик в постгрес, признает преимущество undo и уже года 3 пилит undo для постгрес

    1) это не значит, что другие базы сразу в датафайлы не пишут. Пишут. Может не прям сразу

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

    б) некоторые озвученные применения подразумевают немаленький rps, а огнептах при этом справляется. Странно да?

    пару лет назад Таблойд с sql.ru гонял тесты с 256 параллельными тредами. ФБ просто вставал колом. он отрепортил с десяток чудовищных проблем и наглядно показал, что такие нагрузки никто на ФБ не практикует

    Лог транзакций не является ценностью сам по себе. Это всего лишь инструмент решения задач. Если ОгнеПтах нашел другой инструмент, то что в этом плохого?

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

  • Impala vs Hive vs Spark SQL: Выбор правильного SQL движка для правильной работы в Cloudera Data Warehouse
    +1
    Impala быстро, но не надежно. чуть больше польpователей и привед out of memory. чуть крупней датасет и привед out of memory. зато да, заметно быстрее spark sql
  • [обновлено на 15:00 мск] Произошел масштабный сбой в работе почтового сервиса Mail.ru
    +1
    точно. хабро-карма вытеснила уже и средней руки ийтишников…
  • Нужно ли нам озеро данных? А что делать с хранилищем данных?
    0
    у вас странный опыт и более напоминает компиляцию предрассудков из эпохи map reduce.
    если хотите дельный совет — почитайте книжку Била Инмона Data Lake Architecture: Designing the Data Lake and Avoiding the Garbage Dump
    у него там описывается лейк — четкая противоположность вашим представлениям. особливо вокруг applications pond.
  • Нужно ли нам озеро данных? А что делать с хранилищем данных?
    0
    по большому счету сплошная ерунда в тексте. реально озера вполне себе конкурируют с DWH и все больше задач отгрызают у классики. у нас вот DWH уже просто зеркало реляционных табличек из озера и живо лишь потому что Impala жрет много памяти при большим кол-вое параллельных пользователей. при этом пресловутый GDPR именно облако делает. при этом писать в parquet вполе получается с avro схемой. а еще в последних версиях parquet (delta lake надстройка поверх parquet от датабриксов) и orc вполне и DELETE говорят что работают.
  • Тюнинг Firebird и Linux для БД размером 691 Гб с 1000+ пользователей
    0
    имхо там все не так. начиная с отсутствия базовых вещей, типа партиций и лога транзакций, заканчивая мутноватый бизнес на горемычных пользователях. с тем самым «нам довольно постоянно присылают БД на починку». по мне это некрасиво не сделать полноценный лог, но устроить бизнес на починках.
    кроме этого у фб мусор в датафайла, файлы распухают, все вокруг вынуждены делать много больше чтений, чем необходимо. требуется сборка мусора, что влечет тормоза и совершенно лишние приключения. без лога транзакций фб вынуждена сразу писать в датафайлы, тогда как все конкуренты могут считать транзакцию подтвержденной после записи дельты в лог транзакций.
  • Закат эпохи Big Data
    0
    за ценами на лицензии не следил и про express не слышал. вроде не было такой редакции. у них еще можно скачать их сборку (полный дистрибутив) бесплатно, но с февраля они это закроют. скачать дистрибутив смогут лишь обладатели подписки. цены что-то около $6k за ноду в год. странновастая стратегия мягко говоря, учитывая рост облаков и возможность в пару кликов поднимать хадуп кластеры в облаках.
  • Закат эпохи Big Data
    0
    аффтор путает платформу хадупа с канторами-дистроклепателями. место малоизвестного mapr просто займет майкростофт с его mssql2019. в mssql2019 тот самый hadoop+spark пойдет в комплекте.
    а клаудера вероятно тоже загнется с такими закидонами. они для проформы выкладывают в опенсорс свои продукты, а на деле позванивают клиентов и вымагают деньги на супорт. заявляют что хрен вы там бесплатно что-то без нас соберете.
  • Встречайте Big Data Tools: поддержка Spark и Zeppelin-ноутбуков в IntelliJ IDEA
    0
    у нас на кластере cloudera 5.x, там по дефолту спарк еще из первой ветки. на узлах кластера стоит parcel c 2.x веткой, а на машинках что имеют доступ к узлам кластера похоже не по ставили. т.е. надо или с админами договариваться или самому собирать ванильный, который тоже так просто не собрался.
    и локально че-то не работает, зепелин коверкает похоже логи и даже не понять что у него не так

    2019-10-17 08:48:30 INFO Client:54 - Setting up container launch context for our AM
    2019-10-17 08:48:30 INFO Client:54 - Setting up the launch environment for our AM container
    2019-10-17 08:48:30 INFO Client:54 - Preparing resources for our AM container
    2019-10-17 08:48:32 WARN Client:66 - Neither spark.yarn.jars nor spark.yarn.archive is set, falling back to uploading libraries under SPARK_HOME.
    2019-10-17 08:48:44 INFO Client:54 - Uploading resource file:/tmp/spark-e2b2fd0e-955d-43b7-a203-d86e7680b38a/__spark_libs__8513377897181943277.zip -> hdfs://censoredfs/user/censored/.sparkStaging/application_1570322815840_17054/__spark_libs__8513377897181943277.zip

    at org.apache.zeppelin.interpreter.remote.RemoteInterpreterManagedProcess.start(RemoteInterpreterManagedProcess.java:205)
    at org.apache.zeppelin.interpreter.ManagedInterpreterGroup.getOrCreateInterpreterProcess(ManagedInterpreterGroup.java:64)
    at org.apache.zeppelin.interpreter.remote.RemoteInterpreter.getOrCreateInterpreterProcess(RemoteInterpreter.java:111)
    at org.apache.zeppelin.interpreter.remote.RemoteInterpreter.internal_create(RemoteInterpreter.java:164)
    at org.apache.zeppelin.interpreter.remote.RemoteInterpreter.open(RemoteInterpreter.java:132)
    at org.apache.zeppelin.interpreter.remote.RemoteInterpreter.getFormType(RemoteInterpreter.java:299)
    at org.apache.zeppelin.notebook.Paragraph.jobRun(Paragraph.java:407)
    at org.apache.zeppelin.scheduler.Job.run(Job.java:188)
    at org.apache.zeppelin.scheduler.RemoteScheduler$JobRunner.run(RemoteScheduler.java:315)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

    INFO [2019-10-17 08:49:25,755] ({pool-2-thread-2} VFSNotebookRepo.java[save]:196) - Saving note:2ERC9JRNE
    INFO [2019-10-17 08:49:25,769] ({pool-2-thread-2} SchedulerFactory.java[jobFinished]:120) - Job 20191017-083503_1590331634 finished by scheduler org.apache.zeppelin.interpreter.remote.RemoteInterpreter-spark:shared_process-shared_session
    INFO [2019-10-17 08:55:06,098] ({Exec Default Executor} RemoteInterpreterManagedProcess.java[onProcessComplete]:243) - Interpreter process exited 0


    удобно наверно было бы запускать из идеи в режиме yarn-cluster, т.е. драйвер программа где-то там на кластере жить будет.
  • Встречайте Big Data Tools: поддержка Spark и Zeppelin-ноутбуков в IntelliJ IDEA
    0
    а нам бы пригодилось. по данным с кластера красивые отчетики прямо в родной среде вывести.
    зепелин что бы поставить надо админов привлекать, ставить stb, открывать порты. сложно…
  • Первый в России прототип квантового компьютера заработал в НИТУ «МИСиС»
    0
    1) пока никто не знает
    2) может и впереди на десятилетия, а может и позади. вся фишка в том что те кто собрал десятки кубитов экспериментируют на системах менее атома, где требуется по сути абсолютный ноль и полная изоляция квантовой системы от внешнего мира. вполне может быть они уже не смогут собрать стабильную систему более 100 кубитов. а вот «огромные» российские кубиты в 300 микрон позволят выйти на тысячи. а может и не позволят.
    3) пока проверенных идей как изолировать квантовую систему от внешнего мира нет. потому все существующие системы работающие на экстремально низких температурах могут запросто быть тупиком.
  • Huawei будет устанавливать российский Astra Linux на новые модели своих серверов
    0
    а есть разница? и то и то арм проектировал, какая разница кто лейбл подклеил? тем более что печатает одна и далеко не китайская фабрика.
  • Почему не 1С?
    0
    To guarantee true serializability PostgreSQL uses predicate locking, which means that it keeps locks which allow it to determine when a write would have had an impact on the result of a previous read from a concurrent transaction, had it run first. In PostgreSQL these locks do not cause any blocking and therefore can not play any part in causing a deadlock. They are used to identify and flag dependencies among concurrent Serializable transactions which in certain combinations can lead to serialization anomalies.
  • Почему не 1С?
    +1
    ну так и неверно написано. все версионники кинут ошибку сериализации. исключение оракл, который не стал приносить в жертву здравый смысл и реализовал свой serializable, который не совсем честный, но подходит для того что бы считать деньги.
  • Почему не 1С?
    +1
    в теоретическом версионнике конечно. но не апдейт конфликт, а ошибка сеариализации. в оракле честного serializable нет, зато у постгреса вроде есть честный serializable, который обязан рубить все, что попробует выдать результат отличный от того что должен был бы получится от сериализованных транзакций.
    но это все не столь важно. толку от честного и блокировочного serializable ноль, в реально жизни это просто не взлетает, а реально весь фин сектор сидит на оракле с его не совсем честным но полноценно работающим serializable, где нужно выставлять select for update на подобные чтения. практика показала, что это работает.
  • Почему не 1С?
    +2
    чувак прав. учи уровни изолированности. если используешь RC то чего ты вдруг от него требуешь согласованности? на IL serializable будет ошибка сериализации. блокировочник же на RC в принципе ничего не гарантирует, нет даже гарантии того что остаток счета не считается несколько раз.
  • Европейская навигационная система Galileo вышла из строя
    +1
    сделали так, потому как ссср по сути не имел опыта в цифре и задачу выполнить не смог. спутники советского дизайна отработали пару лет не достигнув и близко необходимой точности. пришлось делать глонас-м, там 75-80% импортных комплектующих
    www.vestifinance.ru/articles/121277

    моя предвзятость тут не причем. 75-80% суровый факт, следовательно от советских разработок ничего не оставили. так что не надо сюда притягивать советские достижения. их там попросту нет.
  • Европейская навигационная система Galileo вышла из строя
    –3
    хлам собранный при ссср выбросили и развернули КА практически полностью на импортной комплектующих. ничего советского уже в спутниках первого поколения не было. там до сих пор добрая половина электроники — штаты.
  • План вернулся в экономику
    0
    ерунда. французские двигатели локализовали, производил завод в риге. в 1915 этот завод перевезли в мск и обозвали салютом.
    ну а по закупкам — да, были. но на порядок два меньше чем ссср при сталине закупал. при сталине простите почти все двигатели или импорт или клон. я уж не говорю про сами объекты промышленности, которые целиком сталину иностранцы строили. начиная с днепрогэса, заканчивая азлк и магниткой.
    все познается в сравнении.
  • План вернулся в экономику
    0
    не нужны демки, нужны реальные кейсы, где продукт был создан ИИ. байки и мутные демки мы и сами лепим заказчикам на тему наших скоркардов.

    я смотрю формулу1, что-то не смотря на сотни млн вложений в ИТ не могут даже небольшие детали просчитать толком. и никакое ИИ им не помогает объяснить почему утром машина ехала отлично, а в обед не может прогреть резину. всю аэродинамику в «считают» в аэродинамической трубе. т.е. у них с их возможностями не получается не то что идеи сгенерить, не выходит даже простые физические процессы просчитать с необходимой точностью.
  • План вернулся в экономику
    0
    зато я не быдло…
  • План вернулся в экономику
    0
    аграрная РИ имела 10 автозаводов, строила крупнейшие на планете самолеты, имела крупнейшую жд сеть, строила линкоры и подлодки. у этих аграриев Лодыгин изобрел лампочку накаливания, Попов радио, а Циолковский просчитал первую космическую.
    в 1941 Москву от немецких танков отбивали пушками времен крымской войны. аграрии РИ делали пушки, которыми можно было попасть в подвижную мишень…
  • План вернулся в экономику
    –1
    ерунда. народ выбрал капитализм, страна тудой и идет. через все стадии. по хорошему стоило бы ради будущих поколений все население заставшее ссср прорядить, т.к. по другому похоже это ожидание всего и вся от гос-ва не вытравить. но видимо не судьба и еще пара поколений обречены.
    посмотрите тв — там люди торчат в деревянных трущобах и ругают власть, при этом ни одному не приходит в голову взять молоток и починить свою крышу. пока не произойдет смена поколений ничего не выйдет.

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

    зы. комуняки той трубы не строили, трубы для ссср делали в ФРГ, т.к. у передового ссср не было технологий даже трубы…
    и кстати тоже трубы отгружали в счет будущих нефтегазовых доходов.
  • План вернулся в экономику
    0
    детальный расклад с тракторами руководству давало ЦСУ ссср, причем очень красиво — в сравнении с сша давало. весь абсурд экономики ссср хорошо был виден в цифрах ЦСУ без бигдаты.
  • План вернулся в экономику
    0
    рентная экономика как раз была в ссср, где экспорт нефтегаза обеспечивал критический импорт. как только цены на нефть обвалились начался голод и вся экономика ссср сложилась. нефтегазовое оборудование, точные станки, зерно обеспечивал нефтегаз. пропали нефтегазовые доходы в скв и ссср пошел на дно. современная РФ много меньше зависит. как минимум накормить население и без нефтегаза сможет. кончится нефть, продадут топливные сборки для аэс. там тоже абсолютные лидеры. плюс не последние по термоядерным исследованиям, добрую треть итеэр «ленивые» русские построили.
    так что граждане окраины вам не повезло, РФ это надолго.
  • План вернулся в экономику
    0
    бигдата может помочь лишь с оптимизацией, но не с идеей. свободный предприниматель, не имея никаких данных, может рискнуть и построить электрокар с мотор-колесом, без всяких распредвалов, коробок передач и прочего. бигдата же может лишь помочь оптимизировать цепочки поставок, но не с идеями, что перевернут отрасль.

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