Введение в управление данными и визуализацию в JavaScript

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

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

Параметры хранения данных

В последние годы хранение данных стало огромным рынком. Решить, какую технологию вы хотите использовать для своего приложения, может быть непростой задачей. Есть несколько вещей, о которых стоит подумать: производительность, масштабируемость, простота реализации, а также особый набор навыков, которые вы и ваша команда. Этот последний пункт чрезвычайно важен и часто упускается из виду. Если в вашей команде есть команда разработчиков SQL, преимущества перехода на реализацию MongoDB должны быть огромными, чтобы убедить вас пойти по этому пути.

Кроме «придерживайтесь того, что вы знаете», нет простого и быстрого ответа, который вы должны использовать. С плоскими наборами данных может быть относительно легко работать. Они структурированы как одна таблица (например, файлы CSV) и могут быть относительно просты для понимания. Ограничения этих источников проявляются быстро, потому что они плохо работают по мере роста и их сложно поддерживать. Если у вас есть плоский набор данных, вы, скорее всего, захотите разбить его на один из других вариантов хранения.

Реляционные базы данных (MySQL, SQL Server) отлично подходят для хранения данных в отдельных таблицах, которые могут быть объединены с использованием уникальных ключей. Преимущества этого состоят в том, что они уменьшают размер наборов данных, работают лучше и могут быть доступны с помощью хорошо зарекомендовавшего себя языка запросов (SQL). Это решение также требует тщательного планирования, создания уникальных ключей для установления отношений и настройки производительности.

Все большую популярность приобретают документно-ориентированные базы данных (например, MongoDB ), которые позволяют хранить данные в объектах JSON. Это также более эффективно, чем плоские файлы, поскольку данные структурированы для уменьшения избыточности. Существует дополнительное преимущество хранения данных в формате, который является родным для JavaScript, но это может стать все более сложным, если вы пытаетесь объединить несколько наборов данных или суммировать / создавать агрегаты.

Неструктурированные базы данных (например, Hadoop) хороши для чрезвычайно больших наборов данных и выходят за рамки этого обсуждения. Если вы работаете с наборами данных такого размера, вы, вероятно, захотите использовать процесс ETL для нормализации данных перед их переносом в ваше приложение.

Возможность хранения данных на стороне клиента также привлекательна, но не лишена недостатков. Хранение файлов и кэширование данных на клиентском компьютере имеет некоторые преимущества в определенных случаях использования, но требует определенного уровня доверия между вами и пользователем. Если это доверенная служба или пользователь знает, что он будет работать с большими объемами данных, разумно ожидать, что он разрешит доступ к хранилищу файлов. Однако по умолчанию я бы не рекомендовал делать это ожидание в любых, кроме самых сложных случаях использования.

Создание слоев доступа

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

CREATE VIEW population_vw AS
SELECT country, age, year,
sum(total) AS TOTAL
FROM census_data
WHERE year IN ('2010')
AND country IN ('United States')
GROUP BY country, age, year;

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

Гибридный подход также может быть эффективным. Зачастую это может быть достигнуто путем создания более целевого слоя MongoDB для вашего большего набора данных, который хранится в SQL Server. Выгрузка наиболее важных данных в ориентированную на документы базу данных для быстрого доступа и потребления при сохранении всего объема данных в вашей внутренней базе данных SQL. Если вы используете Node, вы можете использовать Express, чтобы управлять созданием этих наборов данных и хранить их на вашем сервере MongoDB.

OLAP также позволяет вам создавать наборы данных, которые можно агрегировать, но при этом вы можете заранее установить измерения и показатели, которые вы хотите использовать для представления ваших данных. OLAP использует многомерные выражения (MDX) для доступа к типам данных, но не очень хорошо поддерживается в веб-приложениях.

Сетевые зависимости

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

 document.getElementById("total").addEventListener('click', function() {
  barGraph.render(d, "total")
});

 render: function(d, m) {
  this._init(d, m);
  this._enter(d);
  this._update(d);
  this._exit();
}

 var chartInstance = new Chart(ctx, {
  type: "bar",
  data: data,
  options: {
    legend: {
      display: true,
      labels: {
        fontColor: "rgb(255, 99, 132)"
      }
    }
  }
});

 d3.queue()
  .defer(d3.json, "data/age.json")
  .defer(d3.json, "data/generation.json")
  .await(function(error, d, g) {

     var grp = d3.nest()
      .key(function(d) {
        return d.generation;
      })
      .rollup(function(v) {
        return d3.sum(v, function(d) {
          return d.total;
        })
      })
      .entries(dg);

 [{
  "females": 1994141,
  "country": "United States",
  "age": 0,
  "males": 2085528,
  "year": 2010,
  "total": 4079669
}, {
  "females": 1997991,
  "country": "United States",
  "age": 1,
  "males": 2087350,
  "year": 2010,
  "total": 4085341
}, {
  "females": 2000746,
  "country": "United States",
  "age": 2,
  "males": 2088549,
  "year": 2010,
  "total": 4089295
}, {
  // ...

 document.getElementById("total").addEventListener('click', function() {
  barGraph.render(d, "total")
});

 document.getElementById("over50").addEventListener('click', function() {
  const td = d.filter(function(a) {
    return a.age >= 50
  });
  barGraph.render(td, "total");
});