Оценивая последствия своего решения (особенно неудачного), в приступе самокопания мы не должны забывать, что принимали решение в условиях неопределенности.
• Если данных относительно немного и нет таблиц с миллиардами строк, то проще использовать обычную реляционную базу.
• Если данных больше миллиарда строк или требуется хорошая скорость для аналитических запросов (агрегация и выборки) — то лучше всего использовать колоночную базу данных.
• Если требуется хранить очень большой объем с сотнями миллиардов строк, вы готовы мириться с медленной скоростью или хотите иметь архив исходных данных — то Hadoop.
проект на старте лучше сильно урезать по «хотелкам», чтобы получить на выходе работающую версию как можно быстрее. На то есть несколько причин. Во-первых, после того как вы, заказчик, вживую поработаете с ней, вам гораздо легче будет сформулировать, что вы действительно хотите. Это тяжело делать абстрактно на бумаге, конструируя сферического коня в вакууме. Вторая причина — драйв, лично для меня это очень важно. Когда время течет медленно, у команды, да и у заказчиков, постепенно угасает интерес. И на выходе мы уже получаем вымученный проект, которым уже не так сильно хочется заниматься
«Маленькая грязная тайна продолжающегося бума data science в том, что то, что обычно подразумевается под этим на самом деле, не нужно бизнесу. Бизнесу нужна точная и полезная информация для принятия решений: как тратить время и ресурсы компании. Очень небольшое подмножество задач в бизнесе может быть лучшим образом решено машинным обучением; большинство же из них нуждается в хороших данных и понимании их смысла, что может быть достигнуто простыми методами»
