Doc: Replaced Markdown links to HTML [#METR-2944].

doc/reference_en.html

@@ -352,7 +352,7 @@ At this time (May 2016), there aren't any available open-source and free sys
 <h3 class="not-for-contents">1. Why not to use systems like map-reduce?</h3>
 
 Systems like map-reduce are distributed computing systems, where the reduce phase is performed using distributed sorting.
-Regading this aspect, map-reduce is similar to other systems like YAMR, [Hadoop](http://hadoop.apache.org/), [YT](https://yandexdataschool.ru/about/conference/program/babenko).
+Regading this aspect, map-reduce is similar to other systems like YAMR, <a href="http://hadoop.apache.org/">Hadoop</a>, <a href="https://yandexdataschool.ru/about/conference/program/babenko">YT</a>.
 
 These systems are not suitable for online queries because of latency, So they can't be used in backend-level for web interface.
 Systems like this also are not suitable for realtime updates.
@@ -360,7 +360,7 @@ Distributed sorting is not optimal solution for reduce operations, if the result
 In this case the optimal way to perform reduce operations is by using a hash-table. A common optimization method for map-reduce tasks is combine operation (partial reduce) which uses hash-tables in memory. This optimization is done by the user manually.
 Distributed sorting is the main reason for long latencies of simple map-reduce jobs.
 
-Systems similar to map-reduce enable running any code on the cluster. But for OLAP use-cases declerative query languages are better suited as they allow to carry out investigations faster. For example, for Hadoop there are [Hive](https://hive.apache.org/) and [Pig](https://pig.apache.org/). There are others: [Cloudera Impala](http://impala.io/), [Shark(depricated)](http://shark.cs.berkeley.edu/) and [Spark SQL](http://spark.apache.org/sql/) for [Spark](http://spark.apache.org/), [Presto](https://prestodb.io/), [Apache Drill](https://drill.apache.org/).
+Systems similar to map-reduce enable running any code on the cluster. But for OLAP use-cases declerative query languages are better suited as they allow to carry out investigations faster. For example, for Hadoop there are <a href="https://hive.apache.org/">Hive</a> and <a href="https://pig.apache.org/">Pig</a>. There are others: <a href="http://impala.io/">Cloudera Impala</a>, <a href="http://shark.cs.berkeley.edu/">Shark(depricated)</a> and <a href="http://spark.apache.org/sql/">Spark SQL</a> for <a href="http://spark.apache.org/">Spark</a>, <a href="https://prestodb.io/">Presto</a>, <a href="https://drill.apache.org/">Apache Drill</a>.
 However, performance of such tasks is highly sub-optimal compared to the performance of specialized systems and relatively high latency does not allow the use of these systems as a backend for the web interface.
 YT allows you to store separate groups of columns. But YT is not a truly columnar storage system, as the system has no fixed length data types (so you can efficiently store a number without "garbage"), and there is no vector engine. Tasks in YT are performed by arbitrary code in streaming mode, so can not be suficiently optimized (up to hundreds of millions of lines per second per server). In 2014-2016 YT is to develop "dynamic table sorting" functionality  using Merge Tree, strongly typed values ​​and SQL-like language support. Dynamicly sorted tables are not suited for OLAP tasks, since the data is stored in rows. Query language development in YT is still in incubating phase, which does not allow it to focus on this functionality. YT developers are considering dynamicly sorted tables for use in OLTP and Key-Value scenarios.
 

doc/reference_ru.html

@@ -359,14 +359,14 @@ ClickHouse имеет более десятка инсталляций в дру
 
 <h3 class="not-for-contents">1. Почему бы не использовать системы типа map-reduce?</h3>
 
-Системами типа map-reduce будем называть системы распределённых вычислений, в которых операция reduce сделана на основе распределённой сортировки. Таким образом, к ним относятся YAMR, [Hadoop](http://hadoop.apache.org/), [YT](https://yandexdataschool.ru/about/conference/program/babenko).
+Системами типа map-reduce будем называть системы распределённых вычислений, в которых операция reduce сделана на основе распределённой сортировки. Таким образом, к ним относятся YAMR, <a href="http://hadoop.apache.org/">Hadoop</a>, <a href="https://yandexdataschool.ru/about/conference/program/babenko">YT</a>.
 
 Такие системы не подходят для онлайн запросов в силу слишком большой latency. То есть, не могут быть использованы в качестве бэкенда для веб интерфейса.
 Такие системы не подходят для обновления данных в реальном времени.
 Распределённая сортировка не является оптимальным способом выполнения операции reduce, если результат выполнения операции и все промежуточные результаты, при их наличии, помещаются в оперативку на одном сервере, как обычно бывает в запросах, выполняющихся в режиме онлайн. В таком случае, оптимальным способом выполнения операции reduce является хэш-таблица. Частым способом оптимизации map-reduce задач является предагрегация (частичный reduce) с использованием хэш-таблицы в оперативке. Эта оптимизация делается пользователем в ручном режиме.
 Распределённая сортировка является основной причиной тормозов при выполнении несложных map-reduce задач.
 
-Системы типа map-reduce позволяют выполнять произвольный код на кластере. Но для OLAP задач лучше подходит декларативный язык запросов, который позволяет быстро проводить исследования. Для примера, для Hadoop существует [Hive](https://hive.apache.org/) и [Pig](https://pig.apache.org/). Также смотрите [Cloudera Impala](http://impala.io/), [Shark(устаревший)](http://shark.cs.berkeley.edu/) для [Spark](http://spark.apache.org/) а также [Spark SQL](http://spark.apache.org/sql/), [Presto](https://prestodb.io/), [Apache Drill](https://drill.apache.org/). Впрочем, производительность при выполнении таких задач является сильно неоптимальной по сравнению со специализированными системами, а сравнительно высокая latency не позволяет использовать эти системы в качестве бэкенда для веб-интерфейса.
+Системы типа map-reduce позволяют выполнять произвольный код на кластере. Но для OLAP задач лучше подходит декларативный язык запросов, который позволяет быстро проводить исследования. Для примера, для Hadoop существует <a href="https://hive.apache.org/">Hive</a> и <a href="https://pig.apache.org/">Pig</a>. Также смотрите <a href="http://impala.io/">Cloudera Impala</a>, <a href="http://shark.cs.berkeley.edu/">Shark(устаревший)</a> для <a href="http://spark.apache.org/">Spark</a> а также <a href="http://spark.apache.org/sql/">Spark SQL</a>, <a href="https://prestodb.io/">Presto</a>, <a href="https://drill.apache.org/">Apache Drill</a>. Впрочем, производительность при выполнении таких задач является сильно неоптимальной по сравнению со специализированными системами, а сравнительно высокая latency не позволяет использовать эти системы в качестве бэкенда для веб-интерфейса.
 
 YT позволяет хранить группы столбцов по отдельности. Но YT нельзя назвать по-настоящему столбцовой системой, так как в системе отсутствуют типы данных постоянной длины (чтобы можно было эффективно хранить числа без "мусора"), а также за счёт отсутствия векторного движка. Задачи в YT выполняются с помощью произвольного кода в режиме streaming, то есть, не могут быть достаточно оптимизированы (до сотен миллионов строк в секунду на один сервер). В YT в 2014-2016 годах находится в разработке функциональность "динамических сортированных таблиц" с использованием Merge Tree, строгой типизацией значений и языком запросов типа SQL. Динамические сортированные таблицы не подходят для OLAP задач, так как данные в них хранятся по строкам. Разработка языка запросов в YT всё ещё находится в зачаточной стадии, что не позволяет ориентироваться на эту функциональность. Разработчики YT рассматривают динамические сортированные таблицы для применения в OLTP и Key-Value сценариях работы.