В статье описаны основные архитектуры хранилищ данных, рассмотрены некоторые общие принципы их построения. Подробно описаны способы представления иерархий в реляционной структуре данных.

Введение

В начале восьмидесятых годов прошлого века, в период бурного развития регистрирующих информационных систем, возникло понимание ограниченности возможности их применения для целей анализа данных и построения на их основе систем поддержки и принятия решений. Регистрирующие системы создавались для автоматизации рутинных операций по ведению бизнеса – выписка счетов, оформление договоров, проверка состояния склада и т.д., и основными пользователями таких систем был линейный персонал. Основными требованиями к таким системам были обеспечение транзакционности вносимых изменений и максимизация скорости их выполнения. Именно эти требования определили выбор реляционных СУБД и модели представления данных "сущность-связь" в качестве основных используемых технических решений при построении регистрирующих систем.

Для менеджеров и аналитиков в свою очередь требовались системы, которые бы позволяли:

Очевидно, что регистрирующие системы не удовлетворяли ни одному из вышеуказанных требований. В регистрирующей системе информация актуальна только на момент обращения к базе данных, в следующий момент времени по тому же запросу Вы можете получить совершенно другой результат. Интерфейс регистрирующих систем рассчитан на проведение жестко определенных операций и возможности получения результатов на нерегламентированный (ad-hoc) запрос сильно ограничены. Возможность обработки больших массивов данных также мала из-за настройки СУБД на выполнение коротких транзакций и неизбежного замедления работы остальных пользователей.

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

Определение и типовые архитектуры ХД

В основе концепции хранилища данных лежат две основные идеи - интеграция разъединенных детализированных данных (детализированных в том смысле, что они описывают некоторые конкретные факты, свойства, события и т.д.) в едином хранилище и разделение наборов данных и приложений, используемых для оперативной обработки и применяемых для решения задач анализа. Определение понятия "хранилище данных" первым дал Уильям Г. Инмон в своей монографии . В ней он определил хранилище данных как "предметно-ориентированную, интегрированную, содержащую исторические данные, не разрушаемую совокупность данных, предназначенную для поддержки принятия управленческих решений".

Концептуально модель хранилища данных можно представить в виде схемы , показанной на рисунке 1. Данные из различных источников помещаются в ХД, а описания этих данных в репозиторий метаданных. Конечный пользователь, используя различные инструменты (средства визуализации, построения отчетов, статистической обработки и т.д.) и содержимое репозитория, анализирует данные в хранилище. Результатом его деятельности является информация в виде готовых отчетов, найденных скрытых закономерностей, каких-либо прогнозов. Так как средства работы конечного пользователя с хранилищем данных могут быть самыми разнообразными, то теоретически их выбор не должен влиять на его структуру и функции его поддержания в актуальном состоянии.

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

Виртуальное хранилище данных – это система, представляющая интерфейсы и методы доступа к регистрирующей системе, которые эмулируют работу с данными в этой системе, как с хранилищем данных. Виртуальное хранилище данных можно организовать, создав ряд представлений (view) в базе данных, либо применив специальные средства доступа, например продукты класса Desktop OLAP, к которым относится, например, BusinessObjects, Brio Enterprise и другие .

Главными достоинствами такого подхода являются:

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

Производительности;

Трансформации данных;

Интеграции данных с другими источниками;

Отсутствия истории;

Чистоты данных;

Зависимость от доступности основной БД;

Зависимость от структуры основной БД.

Двухуровневая архитектура хранилища данных подразумевает построение витрин данных (data mart) без создания центрального хранилища, при этом информация поступает из небольшого количества регистрирующих систем и ограничена конкретной предметной областью. При построении витрин данных используются основные принципы построения хранилищ данных, о которых пойдет речь ниже, поэтому их можно считать хранилищами данных в миниатюре. Плюсами витрин данных являются:

Построение полноценного корпоративного хранилища данных обычно выполняется в трехуровневой архитектуре (следует отметить, что здесь под трехуровневой архитектурой понимается не структура "БД – Сервер приложений – клиент"). На первом уровне расположены разнообразные источники данных – внутренние регистрирующие системы, справочные системы, внешние источники (данные информационных агентств, макроэкономические показатели). Второй уровень содержит центральное хранилище данных, куда стекается информация от всех источников с первого уровня, и, возможно, оперативный склад данных (ОСД). Оперативный склад не содержит исторических данных и выполняет две основные функции. Во-первых, он является источником аналитической информации для оперативного управления и, во-вторых, здесь подготавливаются данные для последующей загрузки в центральное хранилище. Под подготовкой данных понимают их преобразование и осуществление определенных проверок. Наличие ОСД просто необходимо при различном регламенте поступления информации из источников. Третий уровень в описываемой архитектуре представляет собой набор предметно-ориентированных витрин данных, источником информации для которых является центральное хранилище данных. Именно с витринами данных и работает большинство конечных пользователей.

Проектирование структуры реляционного хранилища данных

ХД строятся на основе многомерной модели данных. Многомерная модель данных подразумевает выделение отдельных измерений (время, география, клиент, счет) и фактов (объем продаж, доход, количество товара), которые анализируются по выбранным измерениям. Многомерная модель данных физически может быть реализована как в многомерных СУБД, так и в реляционных. В последнем случае она выполняется по схеме "звезда" или "снежинка". Данные схемы предполагают выделение таблиц фактов и таблиц измерений. Каждая таблица фактов содержит детальные данные и внешние ключи на таблицы измерений. Теория построения многомерной модели данных и ее воплощение в реляционной структуре широко освещена как в зарубежной , так и в отечественной литературе .

К числу мало освещенных тем можно отнести проблему представления иерархий. В качестве примера измерения, широко применяющегося при анализе деятельности предприятия и имеющего иерархическую структуру, можно привести справочник статей затрат. Рассмотрим модель мест возникновения затрат (МВЗ), представленную на рис 2.

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

Parent ID

1

Предприятие
2

Управление
3

Инфраструктура
4

Производство
5
6

Сервисные услуги
7

Месторождение A
8

Месторождение B

Таблица 1.

Однако в простоте этого решения скрывается и основной его недостаток. К сожалению, стандартный SQL не поддерживает рекурсивные указатели, поэтому для представления деревьев в ХД используют другие методы.

Метод, предложенный Джо Селко (Joe Celko) , основан на теории множеств. В этом методе все узлы дерева проходятся в прямом порядке обхода и для каждого узла заполняются два значения - левая и правая границы, причем для каждого узла ветви дерева сначала заполняется левая граница и лишь затем правая - при движении обратно от потомков к родителям. Так в нашем примере нумерация узлов будет следующая:

При такой нумерации узлов каждый родитель содержит потомков, левая и правая граница которых лежит в интервале между левой и правой границей родителя. Аналогично все родители потомка имеют левую границу, которая меньше левой границы потомка и правую, большую правой границы потомка. Следовательно, сумму затрат для конкретного МВЗ и всех его составляющих можно получить одним запросом. Например, для получения затрат по инфраструктуре можно выполнить следующий SQL-запрос:

select sum(fact_table.cost)
from fact_table, dimension_table D1, dimension_table D2
where fact_table.dimension_id = D2.id
and D2.left >= D1.left
and D2.right
echo "1000" >
Образец файла скрипта

#!/system/bin/sh
echo "500" > /proc/sys/vm/dirty_expire_centisecs
echo "1000" > /proc/sys/vm/dirty_writeback_centisecs


Каждый твик оформляется отдельным файлом! Все твики в один файл не кладем!

Файл скрипта называем по-любому, но так чтобы сами могли распознать их, например, Battery_tweak - твик аккумулятора.

Твики:
1)Твики скорости интернет-соединения

echo "0" > /proc/sys/net/ipv4/tcp_timestamps;
echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse;
echo "1" > /proc/sys/net/ipv4/tcp_sack;
echo "1" > /proc/sys/net/ipv4/tcp_tw_recycle;
echo "1" > /proc/sys/net/ipv4/tcp_window_scaling;
echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes;
echo "30" > /proc/sys/net/ipv4/tcp_keepalive_intvl;
echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout;
echo "404480" > /proc/sys/net/core/wmem_max;
echo "404480" > /proc/sys/net/core/rmem_max;
echo "256960" > /proc/sys/net/core/rmem_default;
echo "256960" > /proc/sys/net/core/wmem_default;
echo "4096, 16384, 404480" > /proc/sys/net/ipv4/tcp_wmem;
echo "4096, 87380, 404480" > /proc/sys/net/ipv4/tcp_rmem;

2)Твики управления памятью виртуальной машины

echo "4096" > /proc/sys/vm/min_free_kbytes
echo "0" > /proc/sys/vm/oom_kill_allocating_task;
echo "0" > /proc/sys/vm/panic_on_oom;
echo "0" > /proc/sys/vm/laptop_mode;
echo "0" > /proc/sys/vm/swappiness
echo "50" > /proc/sys/vm/vfs_cache_pressure
echo "90" > /proc/sys/vm/dirty_ratio
echo "70" > /proc/sys/vm/dirty_background_ratio

3)Твики ядра

echo "8" > /proc/sys/vm/page-cluster;
echo "64000" > /proc/sys/kernel/msgmni;
echo "64000" > /proc/sys/kernel/msgmax;
echo "10" > /proc/sys/fs/lease-break-time;
echo "500, 512000, 64, 2048" > /proc/sys/kernel/sem;

4)Увеличиваем время жизни аккумулятора

echo "500" > /proc/sys/vm/dirty_expire_centisecs
echo "1000" > /proc/sys/vm/dirty_writeback_centisecs

5)Твик скорости чтения sd-карты(увеличение кеша карты)

echo "2048" > /sys/devices/virtual/bdi/179:0/read_ahead_kb;

6)Дефрагментация файлов баз данных?

for i in \
`find /data -iname "*.db"`
do \
sqlite3 $i "VACUUM;";
done

7)Отключаем логгеры(не будут записываться лог-файлы)

rm /dev/log/main

8)Настраиваем пороги, при которых будет происходить выгрузка приложений при нехватке памяти

echo "2048, 3072, 6144, 15360, 17920, 20480" > /sys/module/lowmemorykiller/parameters/minfree

9)Твики управления кэша

LOOP=`ls -d /sys/block/loop*`;
RAM=`ls -d /sys/block/ram*`;
MMC=`ls -d /sys/block/mmc*`;
for j in $LOOP $RAM
do
echo "0" > $j/queue/rotational;
echo "2048" > $j/queue/read_ahead_kb;
done

10)Твики процессора?

SAMPLING_RATE=$(busybox expr `cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency` \* 750 / 1000)
echo 95 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo $SAMPLING_RATE > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate

11)Перенос dalvik-кеша в раздел cache, чтобы разгрузить раздел data

CACHESIZE=$(df -k /cache | tail -n1 | tr -s " " | cut -d " " -f2)
if [ $CACHESIZE -gt 80000 ]
then
echo "Large cache detected, moving dalvik-cache to /cache"
if [ ! -d /cache/dalvik-cache ]
then
busybox rm -rf /cache/dalvik-cache /data/dalvik-cache
mkdir /cache/dalvik-cache /data/dalvik-cache
fi

Busybox chown 1000:1000 /cache/dalvik-cache
busybox chmod 0771 /cache/dalvik-cache

# bind mount dalvik-cache so we can still boot without the sdcard
busybox mount -o bind /cache/dalvik-cache /data/dalvik-cache
busybox chown 1000:1000 /data/dalvik-cache
busybox chmod 0771 /data/dalvik-cache
else
echo "Small cache detected, dalvik-cache will remain on /data"
fi

12)Удаление кэша, tmp-файлов и прочего мусора

#remove cache, tmp, and unused files
rm -f /cache/*.apk
rm -f /cache/*.tmp
rm -f /data/dalvik-cache/*.apk
rm -f /data/dalvik-cache/*.tmp

if [ -e /data/system/userbehavior.db ]
then
rm -f /data/system/userbehavior.db
fi

if [ -d /data/system/usagestats ]
then
chmod 400 /data/system/usagestats
fi

if [ -d /data/system/appusagestats ]
then
chmod 400 /data/system/appusagestats
fi

#remove main log
if [ -e /dev/log/main ]
then
rm -f /dev/log/main
fi

13)Изменение приоритета процессов-только стандартных. Желательно перед использованием проверить название процессов на вашем аппарате. Призвано увеличить плавность работы аппарата и сделать отклик более приятным)

renice -20 "pidof com.android.phone"
renice -19 "pidof com.android.inputmethod.latin"
renice -19 "pidof com.swype.android.inputmethod"
renice -17 "pidof com.android.systemui"
renice -9 "pidof com.android.settings"
renice -9 "pidof com.android.vending"
renice -6 "pidof com.sec.android.app.camera"
renice -6 "pidof com.sec.android.app.fm"
renice -6 "pidof com.google.android.apps.maps"
renice -4 "pidof com.google.android.apps.googlevoice"
renice -3 "pidof android.process.media"



Назначение скриптов, помеченных вопросительным знаком, точно не знаю или их работа под вопросом!
В прикрепленном архиве лежат готовые скрипты-твики, которые осталось только закинуть в папку init.d. Нумерация скриптов сохранена!

p.s. Повторяюсь, все манипуляции над вашим аппаратом лежат на вашей совести! При использовании программ-твикеров типа mcTweaker удаляйте свои пользовательские скрипты да бы избежать неприятныз ситуаций и всегда делайте бэкап!
p.p.s. Статья будет пополняться новой информацией по мере возможности! Вопросы задаем в комментариях!

Прикрепленный файл #1:

Внимание! У вас нет прав, для просмотра скрытого текста.