Big Data Computing
Big Data Computing
Big Data Computing
Day 3
Day 3
Big data modelling and management
1
In this session…
• Data management
• Data modelling
• Components of a data model:
– Data structure
– Data operations
– Constraints
• Kinds of data models:
– Relational data model
– Semi‐structured data model
– Vector space model
– Graph data model
– Array as a data model
• Data Model vs. Data Format
3
S Ortega‐Martorell
Data Management
4
S Ortega‐Martorell
2
What is Data Management?
“Data management is the development and execution of architectures,
policies, practices and procedures in order to manage the information
lifecycle needs of an enterprise in an effective manner.”[*]
• Big data management refers to the organisation, administration and governance of large
volumes of both structured and unstructured data.
• Big data management strategies are used to contend with fast‐growing pools of data, which
typically involve a variety of data types.
[*] http://searchdatamanagement.techtarget.com/definition/data‐management 5
S Ortega‐Martorell
What is Data Management?
• Let's think of some questions that must be asked and answered well if we are to manage a
reasonable amount of data:
How do we ingest the data?
Where and how do we store it?
How can we ensure data quality?
What operations do we perform on the data?
How can these operations be efficient?
How to scale up data volume, variety, velocity and access?
How to keep the data secure?
6
S Ortega‐Martorell
3
Data ingestion
• Ingestion means the process of getting the data into the data system that we are building or
using.
• Simple ways of doing this include:
2.
1. These ways of data ingestion are
valid for some big data systems
Reading the
data from a file Web form
collecting data
Data ingestion
• However, when you think of a large scale system you would like to have more automation in
the data ingestion processes.
• Data ingestion then becomes part of the big data management infrastructure.
• Things to consider when automating data ingestion include:
– How many data sources?
– How large are data items?
– Will the number of data sources grow?
– What is the rate of the data ingestion?
– What to do with bad data?
– What to do when data is too little or too much?
8
S Ortega‐Martorell
4
Data ingestion – example: hospital information system
Medical
Records
• Let's think of a hypothetical hospital information Treatment
Business
system and the answers to the questions: Office
Logs
– How many data sources? ~20
Pharmacy Specialty
– How large are data items? Avg. record size: 5KB, Avg. Databases
Hospital
image size: 2GB, #records: 50 Million Pathology information
Laboratory Admissions
– Will the number of data sources grow? Not much
– What is the rate of the data ingestion? Not huge (often Outpatient
Oncology
Services
proportional to the number of patient activities that takes Clinics
place at the hospital), ~3K per hour Diagnostic
Radiation
Imaging
– What to do with bad data? Warn, flag and ingest (these Oncology
data can never be discarded, even if with errors)
Ingestion Policy
– What to do when data is too little or too much? Not likely
(not included in this example)
9
S Ortega‐Martorell
Data ingestion – example: cloud database of personal info
• Hypothetical database of personal information:
– How many data sources? 2 Million
– How large are data items? Avg. record size: 3KB, Avg. image size: 2MB,
#records: 200 Billion
– Will the number of data sources grow? Now 25M, growing at 15% per year
– What is the rate of the data ingestion? Very fast, ~200K/h at peak time
Cloud database of personal information
– What to do with bad data? Retry once, then discard (primary challenge is
to keep up with the data rate, therefore erroneous data will be discarded
after first retry)
There is an actual policy for
– What to do when data is too little or too much? Keep the excess data in a
handling data overflow.
site store, and ingest them when the data rate becomes slower. But if the
site store starts getting full, start dropping some incoming data at a rate of
0.1% at a time.
This is why data ingestion, together with it’s policies, should be an integral
part of a big data system. Especially when it involves storing fast data.
10
S Ortega‐Martorell
5
Data storage
• The goal of a storage infrastructure, obviously, is to store data.
• There are two storage‐related issues we consider here:
1. Capacity 2. Scalability
How much storage should we allocate? How fast do we need to read/write?
• What should be the size of the memory? • Should the storage devices be attached directly to the
computers?
• How large and how many disk units should we have?
– making direct input/output fast but less scalable.
• Or should the storage be attached to the network that
connects the computers in the cluster?
– making disk access slower but allowing to add
more storage to the system easily.
These questions do not have a simple answer
11
S Ortega‐Martorell
Data storage
• Memory storage hierarchy:
SSDs (Solid State Devices): much faster than spinning hard disks
NVMe (non‐volatile memory express): makes data transfer
between SSDs and memory much faster
65 nanoseconds
This gap has prompted the design of data
per access
structures and algorithms that use a hard disk but
tries to minimize the cost of the IO operations
10 milliseconds between the fast memory and the slower disk
12
S Ortega‐Martorell
6
Data storage
• What all this means in a big data system is that now we have the choice of architecting a
storage infrastructure by choosing how much of each type of storage we need to have.
The components become increasingly
more expensive as we go from the lower
layers of the pyramid to the upper layers.
So ultimately, it becomes an issue of cost‐benefit trade‐off.
13
S Ortega‐Martorell
Data quality
• Now we stored the data efficiently. But is it any good?
• Are there ways of knowing if the data is potentially error‐free and useful for the intended
purpose?
• This is the issue of data quality.
• There are many reasons why any data application, especially larger applications need to be
mindful of data quality.
14
S Ortega‐Martorell
7
Data quality
Better quality means better
analytics and decision making
Quality assurance means needed
for regulatory compliance
Quality leads to better engagement
and interaction with external entities
15
S Ortega‐Martorell
Data quality
Better quality means better analytics and decision making
This emphasizes that big data can give us actionable insight.
16
S Ortega‐Martorell
8
Data quality
Quality Assurance is the framework that ensures that the development and
manufacture of products (such as pharmaceutical, agrochemical and medical
devices) are performed in compliance with regulatory requirements.
Errors in data in regulated industries (e.g. pharma companies or banks)
can violate regulations leading to legal complications. 17
S Ortega‐Martorell
Data quality
Quality leads to better engagement and interaction with external entities
• This 3rd factor is different.
• It says: if your big data should be used by other people, or a
third party software, it is very important that the data has
good quality to gain trust as a leader provider.
E.g. data collected for research to understand
scientific questions, which may be used later on by
other researchers, etc.
18
S Ortega‐Martorell
9
Data operations
• A very significant aspect of data management is to document, define, implement, and test
the set of operations that are required for a specific application.
• Some operations are independent of the type of data and some others would require us to
know the nature of the data because the operations make use of a particular data model.
• There are two broad divisions of operations: subarray
– Those that work on a single object, e.g. cropping an image
– Those that work on collections of data objects, e.g.:
subset
• Operations that select a part of a collection 1 2 3 4 5 4 5
3 merge
• Operations that combine two collections 1 2 2 3
4 1 2
4
• Operations that compute a function on a collection count
A B C D E 5 19
S Ortega‐Martorell
Data operations
• Every operator must be efficient
– i.e. every operator must perform its task as fast as possible by taking up as little memory, or our
disk, as possible.
• The time to perform an operation will depend on the sizes of the input and the output.
– So, if there is an opportunity to parallelise, it should definitely do so.
• Example, select even numbers: In parallel:
5 2 3 4 1
Sequential
subset
1 2 3 4 5 2 4
2 4
20
S Ortega‐Martorell
10
Data scalability and security
• One way of achieving scalability: Scaling up and Scaling Out
Vertical Scaling (Scale‐up): Horizontal Scaling (Scale‐out):
Adding more processors and RAM, buying a Adding more, possibly less‐powerful
more expensive and robust server machines that interconnect over a network
• Many operations perform better with • Parallel operations will possibly be
more memory, more cores. slower
• Maintenance can be difficult, expensive • Easier in practice to add more machines
The Server industry has many solutions for scale‐up/scale‐out decisions
21
S Ortega‐Martorell
Data scalability and security
• Data security – a must for sensitive data
• Increasing the number of machines leads to
more security risks
• Data in transit must be secure
• Encryption and decryption increase security
but make data operations expensive
22
S Ortega‐Martorell
11
Data modelling
23
S Ortega‐Martorell
What is a data model?
• Data models describe data characteristics.
• The data modelling process may involve the definition of three data models defined at
different abstraction levels, namely:
– Conceptual data models
– Logical data models Purpose
– Physical data models
Communication and definition
Conceptual of business terms and rules
Clarification and detail of
business rules and data structure
Logical
Technical implementation
on a physical database
Physical
24
S Ortega‐Martorell
12
Conceptual Data Model
A conceptual data model is used to define, at a very high and platform‐independent level of abstraction, the
entities or concepts, which represent the data of the problem domain, and their relationships.
• It leaves further details about the entities
(such as their attributes, types or primary
keys) for the next steps.
• This model is typically used to explore domain
concepts with the stakeholders
• It can be omitted or used instead of the logical
data model.
E.g. Three entities (Person, Student and Lecturer) and their
main relationships (teach and supervise associations)
25
S Ortega‐Martorell
Logical Data Model
A logical data model is a refinement of the previous conceptual model. It details the domain entities and
their relationships, but standing also at a platform‐independent level.
• It depicts all the attributes that characterise
each entity
– possibly also including its unique identifier, the
primary key.
• It also shows all the relationships between the
entities
– possibly including the keys identifying those
relationships, the foreign keys.
• Despite being independent of any DBMS, this
model can easily be mapped on to a physical
data model thanks to the details it provides.
E.g. Three entities (Person, Student and Lecturer) and their
main relationships (teach and supervise associations)
26
S Ortega‐Martorell
13
Physical Data Model
A physical data model visually represents the structure of the
data as implemented by a given class of DBMS.
• Therefore, entities are represented as tables,
attributes are represented as table columns
and have a given data type that can vary
according to the chosen DBMS, and the
relationships between each table are
identified through foreign keys.
• Unlike the previous models, this model tends
to be platform‐specific, because it reflects the
database schema and, consequently, some
platform‐specific aspects (e.g. database‐
specific data types or query language
extensions). E.g. Three entities (Person, Student and Lecturer) and their
main relationships (teach and supervise associations)
27
S Ortega‐Martorell
Data models
• The complexity and detail increase from a conceptual to a physical data model.
• First, it is important to perceive at a higher level of abstraction, the data entities and their
relationships using a Conceptual Data Model.
• Then, the focus is on detailing those entities without worrying about implementation details
using a Logical Data Model.
• Finally, a Physical Data Model allows to represent how data is supported by a given DBMS.
28
S Ortega‐Martorell
14
Data models in the context of big data
Volume
VALUE
Data Modelling plays a crucial role in big data analytics as a great proportion of the Big Data is unstructured data.
29
S Ortega‐Martorell
Data models in the context of big data
• One way to characterise data variety is to identify the different models of data that are used
in any application.
• I will introduce you to three components of a data model and what they tell us about the
data:
Regardless of whether the data is big or small, we need to know or determine the
characteristics of data to be able to manipulate or analyse it meaningfully.
30
S Ortega‐Martorell
15
Components of a Data model – Data structure
31
S Ortega‐Martorell
Data structure:
• Structured data: • Unstructured data:
Sales transaction data in a relational table:
32
S Ortega‐Martorell
16
Example of structured data
File 1 File 2
(John, Smith, 10‐12‐1989) (John, Smith, 10‐12‐1989, Plumber, 30000)
(Liz, Spencer, 09‐29‐1980) (Liz, Spencer, 09‐29‐1980, Joiner, 35000)
(Marie, Bishop, 11‐07‐1992) (Marie, Bishop, 11‐07‐1992, Driver, )
(Steve, Richards, 04‐16‐1958) (Steve, Richards, 04‐16‐1958, Salesman, 60000)
• The first 2 of these fields are strings • Is this file structured? Yes it is.
and the 3rd one is a date. – the missing value makes the 3rd record incomplete,
but it does not break the structure or the pattern of
• Even if the data grows, the pattern of the data organisation.
the data organisation remains identical.
• Does it have the same structure as file 1?
• This repeatable pattern of data – Apparently not, however they seem to have been
organisation makes the file structured generated by a similar organisational structure, and
hence they have the same data model.
33
S Ortega‐Martorell
Example of structured data
File 1 File 2
(John, Smith, 10‐12‐1989) (John, Smith, 10‐12‐1989, Plumber, 30000)
(Liz, Spencer, 09‐29‐1980) (Liz, Spencer, 09‐29‐1980, Joiner, 35000)
(Marie, Bishop, 11‐07‐1992) (Marie, Bishop, 11‐07‐1992, Driver, )
(Steve, Richards, 04‐16‐1958) (Steve, Richards, 04‐16‐1958, Salesman, 60000)
𝐴 ,𝐴 ,…,𝐴
𝐵 ,𝐵 ,…,𝐵
structure
…
𝑍 ,𝑍 ,…,𝑍
34
S Ortega‐Martorell
17
Example of unstructured data
• Now in contrast, consider this file:
– Just looking at it, it is impossible to figure out how the data is organised and how to identify subparts of the data.
কার কোথায়থাকা
উচিতবোঝাযাচ্ছে
না ইদা#2472;ীং! ঘরে
থাকবে কে,
আরবাইরেই বা কে,
বর্ধমানে কার
থাকা দরকার, কার
চলে যাওয়া দরকার
মালদহ থেকে— সব
কেমন গুলিয়ে
যাচ্ছে। সরকার
যাঁকে ঘরের আসনে
বসিয়ে রাখে,
নির্বাচন কমিশন
We would call this data unstructured
35
S Ortega‐Martorell
Example of unstructured data
• Often, compressed data like JPEG images, MP3 audio files, MPEG3 video files, encrypted data,
are usually unstructured.
JPEG images
18
Components of a Data model – Data operations
37
S Ortega‐Martorell
Data operations ‐ Subsetting
• Example: Given a collection of data, and a condition, find a subset of data from the
collection so that each element in the subset is satisfied
(John, Smith, 10‐12‐1989, Plumber, 30000)
(Liz, Spencer, 09‐29‐1980, Joiner, 35000)
(Marie, Bishop, 11‐07‐1992, Driver, )
(Steve, Richards, 04‐16‐1958, Salesman, 60000)
Field 5 > 50000
(Steve, Richards, 04‐16‐1958, Salesman, 60000)
38
S Ortega‐Martorell
19
Data operations ‐ Substructure extraction
• Given a data collection with some structure, extract from each data item a part of the
structure as specified by a condition
(John, Smith, 10‐12‐1989, Plumber, 30000) (John, Smith)
(Liz, Spencer, 09‐29‐1980, Joiner, 35000) (Liz, Spencer)
(Marie, Bishop, 11‐07‐1992, Driver, ) (Marie, Bishop)
(Steve, Richards, 04‐16‐1958, Salesman, 60000) Field 1, Field 2 (Steve, Richards)
39
S Ortega‐Martorell
Data operations ‐ Union
• Given two data collections, create a new one with elements of the two input collections
• Duplicate elimination
(John, Smith, 10‐12‐1989)
(Liz, Spencer, 09‐29‐1980)
(Marie, Bishop, 11‐07‐1992) (John, Smith, 10‐12‐1989)
(Liz, Spencer, 09‐29‐1980)
(Marie, Bishop, 11‐07‐1992)
union (Lance, Holt, 04‐02‐1976)
(Lance, Holt, 04‐02‐1976)
(Liz, Spencer, 09‐29‐1980)
40
S Ortega‐Martorell
20
Data operations ‐ Join
• Given two data collections, create a new one with elements of the two input collections
• Duplicate elimination
(12, John, Smith, 10‐12‐1989)
(14, Liz, Spencer, 09‐29‐1980)
(18, Marie, Bishop, 11‐07‐1992)
(20, Sue, Daveson, 03‐16‐1986) (12, John, Smith, 10‐12‐1989, Plumber, 30000)
(14, Liz, Spencer, 09‐29‐1980, Joiner, 35000)
(12, Plumber, 30000) (18, Marie, Bishop, 11‐07‐1992, Driver, 45000)
join
(14, Joiner, 35000)
(18, Driver, 45000)
(23, Student, 30000)
This operation is more complex and can be very expensive when the size of the true collections is large.
41
S Ortega‐Martorell
Data operations
• This is a set of operations (subsetting, substructure extraction, union, join) that can be
performed on the data, without considering the bigness aspect.
• Operations specify the methods to manipulate the data.
• Since different data models are typically associated with different structures, the operations
on them will be different.
• But some types of operations are usually performed across all data models.
42
S Ortega‐Martorell
21
Components of a Data model – Constraints
43
S Ortega‐Martorell
Data constraints
• A constraint is a logical statement.
– That means, we can compute and test whether the statement is true or false.
• Constraints are part of the data model because they can specify something about the
semantics, i.e. the meaning of the data.
• Examples:
– A week has seven and only seven days is something that a data system would not know unless
this knowledge is passed on to it in the form of a constraint.
– The number of titles for a movie is restricted to one.
• Different data models have different ways to express constraints.
44
S Ortega‐Martorell
22
Types of constraints
• Value constraint
– E.g. the age is never negative
• Uniqueness constraint
– E.g. a movie can have only one title
• In the words of logic, there should exist no data object that is a movie and has more than one title.
• Enforcing this type of constraint requires counting the number of titles and verifying that it is one.
Generalising: we can count the number of values associated with each object and check
whether it lies between an upper and lower bound. This is called:
• Cardinality constraint
– E.g. A person can take between 0 and 3 blood pressure medications at a time
45
S Ortega‐Martorell
Types of constraints
• Type constraint
– For restricting the type of data allowed in a field.
– E.g. the name of a person cannot be ‐99.
• To ensure that this does not happen, we can enforce the type of the name to be a non‐numeric
alphabetic string.
• E.g. of a logical expression for this constraint: Name:string, not(isNumeric(Name))
A type constraint is a special kind of domain constraint.
• Domain constraint
– The domain of a data property or attribute is the possible set of values that are allowed for that
attribute.
– E.g. the possible values for the day part of the date field can be between 1 and 31
Day in (1 … 31) Month in (1 … 12) or Month in (‘Jan’, ‘Feb’, … ‘Dec’)
46
S Ortega‐Martorell
23
Types of constraints
Month in (1 … 12) or Month in (‘Jan’, ‘Feb’, … ‘Dec’)
A more complex constraint would be:
Month in (1 … 12) or Month in (‘Jan’, ‘Feb’, … ‘Dec’), with
• 1 or ‘Jan’ having 1 to 31 days
• 2 or ‘Feb’ having 1 to 28 days (or 29 depending on the year)
• ...
• However, all these constraints are Value
Uniqueness
value constraints.
Cardinality
– they only state how to restrict the Type
values of some data property Domain
47
S Ortega‐Martorell
Types of constraints
A totally different type of constraints are:
• Structural Constraints
– A structural constraint puts restrictions on the structure of the data rather than the data values
themselves.
– E.g.:
row column
We have a squared data matrix
It will translate as:
If we transform
it into a table “the number of data rows in
the new table will be the
square of the number of
rows of the original table”
and impose the same
squareness constraint
48
S Ortega‐Martorell
24
Kinds of data models
49
S Ortega‐Martorell
Data models
• So far, we have seen that a Data model is characterized by:
– the structure of the data that it admits
– the operations on that structure
– and a way to specify constraints.
• Now we are going to see a more detailed description of a number of common data models.
Relational data models
Semi‐structured data models
Vector Space Model
Graph Data Model
25
Kinds of data models – Relational data models
51
S Ortega‐Martorell
Relational data models
• A relational data model is one of the simplest and most frequently used data models
today.
• It forms the basis of many other traditional database management systems, such as:
52
S Ortega‐Martorell
26
Relational data models – tables
The primary data structure for a relational model is a table.
53
S Ortega‐Martorell
Relational data models – tables
The primary data structure for a relational model is a table.
ID FName LName Depart. Title Salary • A relational tuple implies that, unless
202 John Gonzales IT DB Specialist 104750 otherwise stated, the elements of it
203 Mary Roberts Research Director 175400 (e.g. 203 or 204), are atomic.
– That is, they represent one unit of
204 Janaki Rao HR Financial Analyst 63850
information and cannot be
205 Alex Knight IT Security Specialist 123500 decomposed further.
206 Pamela Ziegler IT Programmer 85600 – Thus, this is a relation of six tuples.
These tables represent a set of tuples.
Relational tuple, represented as a row
There are also relational tables, which represent
the different relationships between tables
54
S Ortega‐Martorell
27
Relational data models – tables
No duplicates are allowed
ID FName LName Depart. Title Salary
202 John Gonzales IT DB Specialist 104750
203 Mary Roberts Research Director 175400
204 Janaki Rao HR Financial Analyst 63850
205 Alex Knight IT Security Specialist 123500
206 Pamela Ziegler IT Programmer 85600
207 Harry Dawson HR Director 115450
207 Harry Dawson HR Director 115450
55
S Ortega‐Martorell
Relational data models – tables
Dissimilar tuples are not allowed either:
ID FName LName Depart. Title Salary
202 John Gonzales IT DB Specialist 104750
203 Mary Roberts Research Director 175400
204 Janaki Rao HR Financial Analyst 63850
205 Alex Knight IT Security Specialist 123500
206 Pamela Ziegler IT Programmer 85600
207 Harry Dawson HR Director 115450
Research
Jane Dow 208 65800 Research
Associate
It has all the right pieces of information,
but they are all in the wrong order
56
S Ortega‐Martorell
28
Relational data models – table schema
Relational schema
Employee
ID: FName: LName: Department: Title: Salary: This row is part of the
Int string string Enum (HR, IT, string int schema of the table
Primary key Not null Not null Research, Business) > 25000
202 John Gonzales IT DB Specialist 104750
203 Mary Roberts Research Director 175400 The schema includes:
204 Janaki Rao HR Financial Analyst 63850 ‐ name of the table
‐ attributes of the relation
205 Alex Knight IT Security Specialist 123500
(columns)
206 Pamela Ziegler IT Programmer 85600 ‐ for each column, the
207 Harry Dawson HR Director 115450 allowed data type
‐ constraints (in yellow)
Jane Dow 208 Research Associate 65800 Research
Given this schema, it should now be clear why
the last red row does not belong to this table.
57
S Ortega‐Martorell
Relational data models – primary key
Employee
Primary key ID: FName: LName: Department: Title: Salary:
(unique) Int string string Enum (HR, IT, string int
Primary key Not null Not null Research, Business) > 25000
202 John Gonzales IT DB Specialist 104750
203 Mary Roberts Research Director 175400
204 Janaki Rao HR Financial Analyst 63850
205 Alex Knight IT Security Specialist 123500
206 Pamela Ziegler IT Programmer 85600
207 Harry Dawson HR Director 115450
• This means it is unique for each employee.
• And for every employee, knowing his/her primary key, will also uniquely know the other attributes.
• A table with a primary key logically implies that the table cannot have a duplicate record, otherwise it
will violate the uniqueness constraint associated with the primary key.
58
S Ortega‐Martorell
29
Relational data models – relational tables and FK
Relational tables represent the different relationships between tables
Example modified to reflect the salary of the employee at different times
EmpSalaries
EmpID Date Salary
202 1/1/2016 104750
203 2/15/1016 175400
204 6/1/2015 63850
205 9/15/2015 123500
206 10/1/2015 85600
207 4/15/2015 115450
202 9/15/2014 101250
204 3/1/2015 48000
207 9/15/2013 106900
Employees.ID references EmpSalaries.EmpID
205 10/1/2014 113400
Primary key (PK) Foreign key (FK)
59
S Ortega‐Martorell
Relational data models – relational join
Employee Output table of the relational join
ID FName LName ID FName LName Date Salary
202 John Gonzales EmpSalaries 202 John Gonzales 1/1/2016 104750
203 Mary Roberts EmpID Date Salary 202 John Gonzales 9/15/2014 101250
204 Janaki Rao 202 1/1/2016 104750 203 Mary Roberts 2/15/1016 175400
205 Alex Knight 203 2/15/1016 175400 204 Janaki Rao 6/1/2015 63850
206 Pamela Ziegler 204 6/1/2015 63850 204 Janaki Rao 3/1/2015 48000
207 Harry Dawson 205 9/15/2015 123500 205 Alex Knight 9/15/2015 123500
206 10/1/2015 85600 205 Alex Knight 10/1/2014 113400
207 4/15/2015 115450 206 Pamela Ziegler 10/1/2015 85600
30
Relational data models – relational join
• Join is one of the most expensive operations, that means
– time consuming and
– space consuming
• As data becomes larger, and tables contain hundreds of millions of tuples, the join
operation can easily become a bottleneck in a larger analytic application.
• So for analytical big data application that needs joins, it is very important to choose
a suitable data management platform that makes this operation efficient.
61
S Ortega‐Martorell
Practicalities
• In many business solutions, people start with CSV files, manipulate
them with the spreadsheet
• Then, they migrate their relational system only as an afterthought,
when the data becomes too large to handle the spreadsheet.
• While the spreadsheet offers many useful features, it does not conform
and enforce many principles of relational data models.
– Consequently, a large amount of time may be spent in cleaning up and
correcting data errors after the migration actually happens.
62
S Ortega‐Martorell
31
Example: terrorism data
• Example: a spreadsheet that has 125,000 rows and over 100 columns.
– It contains a lists terrorist attacks gathered from news media. So each row represents one attack.
• Let us look at it from a relational data modelling viewpoint:
A query like “find all attacks for which
Two weapons used in the attack the property damage is = minor”
separated by a semicolon cannot be answered directly
This makes this column non‐atomic A substring search for minor makes it
more expensive 63
S Ortega‐Martorell
Example: terrorism data
• These are the columns of the spreadsheet:
– So this is part of the schema of the data.
If you observe carefully you will see a recurring pattern.
64
S Ortega‐Martorell
32
Example: terrorism data
The design of the data table determined that there can be at most three types of attacks
within a single encounter and represented with three separate columns.
• In proper relational modelling, one would say that there is a 1‐to‐many relationship between
the attack and the number of attack types.
• In such a case, it would be better to place these attack‐type columns in a separate table and
connect with the parent using a PK‐FK relationship.
65
S Ortega‐Martorell
Example: terrorism data
Similar pattern here, this time this is about the types and subtypes of weapons used.
66
S Ortega‐Martorell
33
Kinds of data models – Semi‐structured data models
67
S Ortega‐Martorell
Semi‐structure data models – HTML
Let's a take a very simple web page:
• Everywhere here a block is nested within a larger block
– li tags within p tags, which are within body tags, etc.
• Unlike a relational structure, there are multiple list items and
multiple paragraphs
– and any single document would have a different number of them.
This means while the data object has some structure, it is more flexible.
This is the hallmark of a semi‐structure data model.
68
S Ortega‐Martorell
34
Semi‐structure data models – XML
• XML stands for eXtensible Markup Language.
• XML is another well‐known standard to
represent data.
• It can be seen as a generalisation of HTML
– where the elements can be any string, and not
only the ones allowed by HTML.
69
S Ortega‐Martorell
Semi‐structure data models – XML
1. There are two ‘sampleattribute’ elements.
– They are structurally different as they have different
number of sub‐elements.
1
2 2. XML allows the querying of both, schema and data.
– E.g. you can query the name of the element that contains
a sub‐element whose content is ‘CellType’?
1
We cannot perform an operation
like 2 in a relational data model
2 E.g. we cannot query: which relation
has a column with a value, say, John
70
S Ortega‐Martorell
35
Semi‐structure data models – JSON Example of JSON:
• The same idea can also be seen in JSON.
• JSON stands for Java Script Object Notation.
• It is a very popular format used for many
different data, e.g. Twitter and Facebook
data.
• It is an open‐standard file format.
71
S Ortega‐Martorell
Semi‐structure data models – JSON
Key‐value pair
• JSON uses human‐readable text to
transmit data objects consisting of
attribute–value pairs and array data types
(or any other serializable value).
• Although the format looks different to
XML, it has a similar nested structure. Tuple
Squared brackets
indicate arrays
Useful link: http://jsonviewer.stack.hu/
72
S Ortega‐Martorell
36
JSON
Semi‐structure data models – tree data structure
• One way to generalise these different forms of
semi structured data is to model them as trees.
XML
73
S Ortega‐Martorell
Semi‐structure data models – tree data structure
XML
Tree data structure
JSON
Useful link: http://countwordsfree.com/xmlviewer 74
S Ortega‐Martorell
37
Semi‐structure data models – Tree operations
• getParent
– parent of Case: Dataset
Tree data structure
• getChildren
– children of Case: Tissue and Spectrum
• getSiblings
– children of Case: other Case nodes
• root‐to‐node‐path
– for ‐1.1 0.79 ‐0.45 would be:
XML/DATASET/Case/Spectrum/Points/‐1.1 0.79 ‐0.45
Queries need tree navigation
75
S Ortega‐Martorell
Hands‐on activity:
1. Exploring the Semi‐structured Data Model of JSON
76
S Ortega‐Martorell
38
Details of the hands‐on activity: Data Model of JSON
• View contents of Twitter JSON
• Exploring JSON schema
• Extract fields from JASON
• Instructions for this activity can be found here:
– “HandsOn 1. JSON Data.docx”
77
S Ortega‐Martorell
Kinds of data models – Vector Space Model
78
S Ortega‐Martorell
39
Vector model
• The Vector Space Model has been successfully used to retrieve data from large collections
of text and images.
Starting with text
• Text is often considered unstructured data.
– It does not have attributes and relationships.
– So we need a different way to find and analyse text data.
• Finding text from a huge collection of text data is different from the data models we have
seen so far.
79
S Ortega‐Martorell
Vector model
• To find text, we not only need the text data itself, but we need a different structure that is
computed from the text data.
• That structure will be provided by the document vector model.
• With this, finding a document won’t be an exact search problem.
– Instead, we will provide a query document and ask the system to find all documents that are
similar to it.
• Search engines use some form of vector models
and similarity search to locate text data
– the same principle can be use for finding similar images
80
S Ortega‐Martorell
40
Vector model – Term Frequency
• Example for describing the concept of a document:
d1: “new york times”
3 documents d2: “new york post”
d3: “los angeles times”
We can create the frequency matrix of the 3 documents,
containing the term frequencies (TF):
81
S Ortega‐Martorell
Vector model – Inverse Document Frequency
• Example for describing the concept of a document:
d1: “new york times”
3 documents d2: “new york post”
d3: “los angeles times”
# docs term count
Also, we can create a new vector called the
Inverse Document Frequency (IDF) for each term:
log2(3/1)=1.584
Term Doc freq. IDF
angeles 1 log2(3/1)=1.584 The use of log to the base 2
los 1 log2(3/1)=1.584 (instead of log10)
is just a convention
new 2 log2(3/2)=0.584
post 1 log2(3/1)=1.584
times 2 log2(3/2)=0.584 What is the intuition
york 2 log2(3/2)=0.584 behind the IDF vector?
82
S Ortega‐Martorell
41
Vector model – understanding why we need IDF
Example:
• Take 100 random newspaper articles
– 10 of them cover election news
– Would you expect to see the term ‘election’ more often than ‘is’?
• Example:
– Doc. frequency of ‘election’ = 50
freq. ‘is’ = 6 x freq. ‘election’
– Doc. frequency of ‘is’ = 300
– Should ‘is’ have more importance than ‘election’?
• ‘is’ is such a common word that it’s prevalence has a negative impact on its
informativeness.
– if you compute the IDF of ‘is’ and ‘election’, the IDF of ‘is’ will be far lower
Using IDF penalises words/terms that are too common in the collection.
83
S Ortega‐Martorell
Vector model – the FT‐IDF matrix
• Obtained by multiplying the TF numbers by the IDF.
Term Doc freq. IDF
angeles 1 log2(3/1)=1.584
angeles los new post times york
los 1 log2(3/1)=1.584
d1 0 0 1 0 1 1
new 2 log2(3/2)=0.584
d2 0 0 1 1 0 1 post 1 log2(3/1)=1.584
d3 1 1 0 0 1 0 times 2 log2(3/2)=0.584
york 2 log2(3/2)=0.584
d1 0 0 0.584 0 0.584 0.584 1.011 Length of d1 0.584 0.584 0.584 1.011
d2 0 0 0.584 1.584 0 0.584 1.786 (The square root of the sum of squares
of the individual term scores)
d3 1.584 1.584 0 0 0.584 0 2.316
84
S Ortega‐Martorell
42
Vector model – the FT‐IDF matrix
angeles los new post times york length
FT‐IDF matrix
• Therefore, for each document, we have a vector represented here as a row.
• So that row represents the relative importance of each term in the vocabulary.
– Vocabulary means the collection of all words that appear in this collection.
– If the vocabulary has 3 million entries, then this vector can get quite long.
– Also, if the number of documents grows, e.g. to 1 billion, it becomes a big data problem.
• The last column represents the length of the document vector.
85
S Ortega‐Martorell
Vector model – searching in the vector space
• To perform a search in the vector space, we write a query just like we type terms in Google:
• Maximum frequency of all terms in the query = 2 (‘new’)
• Create the query vector:
Note: Max. frequency of all terms in the query for each of the documents in the previous example was = 1 (there were no terms repeated). 86
S Ortega‐Martorell
43
Vector model – searching in the vector space
angeles los new post times york length
• Next, we will compute the similarity between the query vector and each document
– measuring how far the query vector is from each document.
• There are many similarity functions defined and used for different things.
• A popular similarity measure is the cosine function:
– It measures the cosine function of the angle between these two vectors:
87
S Ortega‐Martorell
Vector model – searching in the vector space
• The intuition behind using the cosine function as a similarity measure is that:
– If the vectors are identical, then the angle between them is zero. And therefore, the
cosine function evaluates to one.
– As the angle increases, the value of the cosine function decreases to make them more
dissimilar.
• The way to compute the function is:
– For two vectors: 𝑎 𝑎 … 𝑎 and 𝑏 𝑏 … 𝑏 , with document lengths 𝑙 and 𝑙 , respectively:
cosSim 𝑎, b 𝑎 ∗𝑏 𝑎 ∗𝑏 ⋯ 𝑎 𝑏 ⁄ 𝑙 𝑙
• The results of the distance function are:
much more similar to the
𝑐𝑜𝑠𝑆𝑖𝑚 𝑑1, 𝑞 0.584 ∗ 0.584 0.584 ∗ 0.292 ⁄ 1.011 ∗ 0.652 0.776
𝑐𝑜𝑠𝑆𝑖𝑚 𝑑2, 𝑞 0.584 ∗ 0.584 ⁄ 1.786 ∗ 0.652 0.292
query than the other two
𝑐𝑜𝑠𝑆𝑖𝑚 𝑑3, 𝑞 0.584 ∗ 0.292 ⁄ 2.316 ∗ 0.652 0.112
88
S Ortega‐Martorell
44
Vector model – query term weighting
• More often than not, users would like a little more control over the ranking of terms.
• One way of accomplishing this is to put different weights on each query term.
• Example:
Q = york^1 times^2 post^5
𝑤𝑡 𝑦𝑜𝑟𝑘 1/ 1 2 5 1/8 0.125
𝑤𝑡 𝑡𝑖𝑚𝑒𝑠 2/ 1 2 5 2/8 0.25
𝑤𝑡 𝑝𝑜𝑠𝑡 5/ 1 2 5 5/8 0.625
Multiply the query vector with these weights
As a results, “new york post” will rank first.
89
S Ortega‐Martorell
Vector model – image search
• Similarity search is often used for images using a vector space model.
– We can compute features from images.
– One common feature is a scatter histogram.
• Example:
• One can create the histogram of the red, green and
blue channels where histogram is the count of pixels
having a certain density value.
• This picture is mostly bright, so the count of dark
pixels is relatively small.
• Now we can think of histograms like a vector.
90
S Ortega‐Martorell
45
Vector model – image search
• The table shown is a feature vector where the numbers for each row have been normalised with the
size of the image to make the row sum equal to one.
• Similar vectors can be computed of the image texture, shapes of objects and any other properties.
The vector space model is significant for unstructured data.
91
S Ortega‐Martorell
Kinds of data models – Graph Data Model
92
S Ortega‐Martorell
46
Graph Data Model
• What distinguishes a graph from other data models is that it bears two kinds of information:
1. properties and attributes of entities and relationships, and
2. the connectivity structure that constitutes the network itself.
Typical example:
Social networks
93
S Ortega‐Martorell
Graph Data Model
• One way to look at this data model is using the following representation (from Apache Spark)
The graph on the left is represented by the two tables on the right
The vertex (or node) table,
gives IDs to nodes and lists
their properties.
The edge table has two parts:
• The properties of the edge (in orange)
• the direction of the arrows in the network
(source ‐> destination).
Thus, since there is a directed edge going from node 3 to
node 7, there is a tuple 3,7 in that part of the edge table.
This form of the graph model is called the property graph model.
94
S Ortega‐Martorell
47
Graph Data Model
• Representing connectivity information gives graph data a new kind of computing ability that
is different from other data models we have seen so far.
• Even without looking at the properties of the nodes and edges, one can get very interesting
information just by analysing or querying this connectivity structure.
• E.g.: small social network with:
– three types of nodes:
• user (blue nodes)
• city (red node)
• restaurant (green nodes)
– three types of edges:
• friend (blue arrow)
• likes (green arrow)
• lives in (red arrow)
95
S Ortega‐Martorell
Graph Data Model – small social network example
Friend Italian2
Likes
Lives in
• Tom is interested in finding a good Italian
Italian1
Bob restaurant in Liverpool that his friends, or
Tim Jen
Jen their friends, who also live in Liverpool, like.
Tom
Jill • Tom shall possibly choose Italian3 because:
Max – It has the highest number of ‘like’ edges
coming into it from people who have a ‘lives
in’ edge to Liverpool.
Liz Pam
– And can be reached by following the ‘friend’
Italian3 edges going out from Tom.
This shows an important class of operations and ground data, namely traversal,
that involves edge following based on some sort of conditions.
96
S Ortega‐Martorell
48
Graph Data Model – optimal path operations
A number of path operations require some sort of optimisation.
1. The simplest is the well‐known shortest path query
– to find the best route from a source location to a target location.
2. To find an optimal path that must include some user‐specified nodes
– the operation has to determine the order in which the nodes will be visited.
– E.g. a trip planner, where the users specify the cities they wish to visit, and
the operation will optimise the criterion, like the total distance covered.
3. This is a case where the system must find the best possible path, given
two or more optimisation criteria, which cannot be satisfied
simultaneously.
– E.g. if I want to travel from my house to the airport using the shortest
distance, but also minimising the amount of highway travel, the algorithm
must find a best compromise.
– This is called a Pareto‐optimality problem on graphs.
97
S Ortega‐Martorell
Graph Data Model – neighbourhood
• The neighbourhood of a node N in a graph is a set of edges directly connected to it.
– A K neighbourhood of N is a collection of edges between nodes that are, at most, K steps away
from N.
Italian2
• E.g.:
Italian1
Bob
Tim Jen
Jen Bob, Jill, Liz: 1st neighbours of Tom
Liz Pam
Italian3
98
S Ortega‐Martorell
49
Graph Data Model – communities
• An important class of analysis to perform with neighbourhoods is
community finding.
– The graph shown in this figure has four communities.
• We can see that each community has a higher density of edges within the
community and a lower density across two different communities.
• Operations:
– Finding densely connected parts of a graph
• It helps identify neighbourhoods that can be recognised as communities.
– Finding the best possible clusters (communities) in a graph
• So that any other grouping of nodes into communities will be less effective.
• This is a more complex operation
• As graphs become bigger and denser, these methods become harder to compute.
• Thus, neighbourhood‐based optimisation operations present significant scalability challenges.
99
S Ortega‐Martorell
Graph Data Model – anomalous neighbourhoods
Odd because it is almost perfectly star shaped.
• That is, the nodes that the red node is connected to are almost
unconnected amongst themselves.
• That is odd because it does not happen much in reality.
• So it is an anomalous node.
Near clique.
• This shows a neighbourhood to which a significantly large number of
neighbours has connected amongst themselves.
• This makes the graph very cliquish.
– clique refers to a neighbourhood where each node is connected to all
other neighbourhood nodes in the neighbourhood.
100
S Ortega‐Martorell
50
Graph Data Model – anomalous neighbourhoods
Heavy vicinity.
• A neighbourhood where some edges have an unusually heavy
weight compared to the others
Predominant edge.
• A special case of the third (heavy vicinity).
• A neighbourhood where one edge is predominantly high‐rate
compared to all the other edges.
101
S Ortega‐Martorell
Graph Data Model – Connectedness
• Connectedness is a fundamental property of a graph.
– In a connected graph, each node is reachable from every other node through some path.
– If a graph is not connected, but there are subgraphs of it, which are connected, then these
subgraphs are called connected components of the original graph.
• In this figure there are four connected components.
– A search gradient like finding optimal paths should be performed
only within each component and not across them.
For large graphs, there are several new parallelised techniques
for the detection of connected components.
102
S Ortega‐Martorell
51
Kinds of data models – Array as a data model
103
S Ortega‐Martorell
Other Data Models – Array as a Data model
• Arrays can serve as a data model.
• What is an array?
1D array:
3D array: 4
1 2 3 4 5 6
3
4
2 3 2
2D array: 1
1
1 1
1
2
2 2
3
3 3
4
4 1 2 3 4 4
1 2 3 4
1 2 3 4 5 6
104
S Ortega‐Martorell
52
Other Data Models – Arrays of vectors
1 2 3 4 5 6 1 2 3 4 5 6
1 10 77 18 21 4 39 (10, (77, (18, (21, (4, (39,
1 200, 182, 310, 231, 217, 168,
2 23 16 31 19 62 42 68) 83) 56) 78) 75) 90)
3 28 47 37 93 20 54 (23, (16, (31, (19, (62, (42,
2 193, 301, 290, 253, 383, 203,
4 93 99 58 42 47 84 35) 74) 84) 49) 49) 75) E.g. images:
(28, (47, (37, (93, (20, (54, R,G,B channels per pixel
A(row, column) = value 3 174, 168, 341, 236, 386, 326,
56) 90) 57) 83) 50) 53)
A(2, 4) = 19 (93, (99, (58, (42, (47, (84,
4 348, 192, 293, 294, 432, 388,
67) 79) 82) 74) 45) 94)
A(2, 4) = (19,253,49)
A(2, 4)[1] = 19
105
S Ortega‐Martorell
Other Data Models – Operations on arrays of vectors
• dim(A) – number of dimensions of A
• A(i,j) – value of the element at the (i,j)‐th cell
• A(i,j)[k] – value of the k‐th element of the cell at A(i,j)
• length(A(i,j)) – vector‐length of the vector at the (i,j)‐th cell
• etc.
106
S Ortega‐Martorell
53
Data Model vs. Data Format
What is the difference between them?
107
S Ortega‐Martorell
Data Model vs. Data Format
Data Model Data Format
• Example:
husband
Jill
Jack Profession:
Profession: baker
plumber
CSV file
wife Age: 32
Age: 35 Jack, profession, plumber, age, 35, wife, Jill
Jill, profession, baker, age, 32, husband, Jack
Peter Peter, profession, teacher, age, 36, friend, Jack
Profession:
friend teacher
Age: 36
108
S Ortega‐Martorell
54
Hands‐on activity:
2. Exploring the Array Data Model of an Image
109
S Ortega‐Martorell
Details of the hands‐on activity: Array Data Model of an Image
• Display an image file
• Examine the structure of the image
• Extract pixel values from various locations in the image
• Instructions for this activity can be found here:
– “HandsOn 2. Image Data.docx”.
110
S Ortega‐Martorell
55
Hands‐on activity:
3. Exploring Sensor Data
111
S Ortega‐Martorell
Details of the hands‐on activity: Exploring sensor data
• Look at weather station measurements in text file
• Identify the major components in semi‐structured data from a weather station
• Create plots of weather station data
• Instructions for this activity can be found here:
– “HandsOn 3. Sensor Data.docx”.
112
S Ortega‐Martorell
56
Conclusions
113
S Ortega‐Martorell
Summary
We have covered today:
1. The meaning of ‘data management’, and also in the context of Big Data.
2. Structured and unstructured data, basic data operations, types of data constraints, and why
they are useful to specify the semantics of the data.
3. The structural components of a relational data model, the ‘schema’, primary and foreign keys;
and some of the operations.
4. Semi‐structured data models, that most semi‐structured data are tree‐structured, and why
tree navigation operations are important for XML and JSON.
5. What a vector model is, the concepts of similarity function and similarity search; and that
many document and image search engines use these concepts.
6. The graph data model; and described path, neighbourhood, and connectivity operations.
7. How arrays can serve as a data model, and why images can be modelled as vector arrays.
8. The difference between format and data model.
114
S Ortega‐Martorell
57