0% found this document useful (0 votes)
263 views106 pages

Introduction To HANA - Deep Dive

Uploaded by

Jithu Zithendra
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
263 views106 pages

Introduction To HANA - Deep Dive

Uploaded by

Jithu Zithendra
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 106

Introduction To HANA - Deep Dive

1
Need of today data basefeatures

➢ Real time data reporting forAnalysis

➢ High speed processing

➢ Ability to process structed and unstructured data

➢ Ability to connect Bigdata

➢ Ability connect IOTand process real time data

➢ Ability to process Spacial data

➢ Ability to connect to different sources of data and report at same data with
no data redundancy
History of SAP HANA
• SAP HANA is the synthesis of three separate products – TREX search engine,
P*Time in-memory OLTPdatabase, and MaxDB in-memory liveCache engine.

• In 1996, a student project at SAP, in collaboration with DFKI, began development


of TREX(Text Retrieval and Information Extraction), a search engine.

• TREXbecame a standard component in SAPNet Weaver in 2000.

• In-memory attributes were added in 2002 and columnar data store was added
in 2003, both as ways to enhance performance.
• In 2005 SAP acquired Menlo Park-based Transact In Memory, Inc. With the acquisition
came P*Time, an in-memory, light-weight online transaction processing (OLTP) RDBMS
technology with a row-bases data store.

• MaxDB (formerly SAP DB), a relational database, came from (first) Nixdorf, (second)
Software AG (was named adabas D), and then (third) SAP. It was added to TREX and
P*Time to provide persistence and more traditional database features, like backup.

• In 2008, teams working from Hasso Plattner Institute and Stanford University developed
this “New Database” as it was called.

• First shipment was in November 2010, support for BW available in November 2011,
support for ERPavailable in May 2013.
What is HANA - Is it a data base or ERP or Software ?
• HANA is a solution for in-memory computing, Acronym HANA means “High Performance
Analytic Appliance”.
• SAP HANA is a flexible data source-agnostic appliance that enables customers to analyze
large volumes of data in real time.

• HANA DB takes advantage of the low cost of main memory (RAM), data processing
abilities of multi-core processors, and the fast data access of solid-state drives relative to
traditional hard drives to deliver better performance of analytical and transactional
applications.

• It offers a multi-engine query processing environment which allows it to support both


relational data (with both row- and column-oriented physical representations in a hybrid
engine), as well as graph and next processing for semi and unstructured data
management within the same system
Why to choose SAP HANA?
• SAP HANA is a next –generation in-memory platform. It accelerates analytics and application on
a single and in-memory platform.

• Mentioned below are the few reasons why to choose SAP HANA – Real Time – SAP HANA
provides Real – Time Data Provisioning and Real-time Reporting.

• Speed – SAP HANA provide high speeds processing on massive data due to In-Memory
Technology.

• Any Data/Source – SAP HANA can access various data source including Structured and Un-
Structured data from SAPor Non-SAP data source.

• Cloud – SAPHANA database and application can be deployed to the Cloud environment.

• Simplicity – SAP HANA reduce efforts behind ETL process, Data Aggregation, Indexing, and
Mapping.

• Cost – SAPclaims that SAPHANA software can reduce Total IT cost of a company.

• Choice Option – SAP HANA is supported by different hardware vendor and software provider,
so based on the requirement, the user can choose the best option.
Advantages of SAPHANA

• By In-Memory Technology user can explore and analyse all transactional


and analytic data in real time from virtually any data source.

• Data can be aggregated from many sources.

• Real-time replication services can be used to access and replicate data


from SAPERP.

• SQLand MDX interface from third party support.

• It provides information modelling and design environment.


Reasons To Choose SAP HANA
• Accelerates analytics – In future we can analyze huge Meter data fro smart
meters and billing analysis

• Applications on a single, in-memory platform as well as combining databases,


data processing, and application platform capabilities.
• Faster Business transactions
• Advanced analytics
• Social media – TextAnalyse possible

• Mobile experience – SAP Fiori can be used and good number of APPS
available
HANA Live
Spatial tables on HANA and its uses
SAP HANAPlatform
Hardware Architecture trends
•SAP HANA is the foundation for SAP
S/4HANA and provides many of its critical
services, so it is worth taking the time to
learn a little about it.

•S/4HANA is a business suite that has its


own application server. The application
server on which S/4HANA is based is SAP
NetWeaver AS ABAP. This is the same
application server as Business Suite, but is
upgraded to suit S/4HANA.

•The application server sits on top of the


database, in this case, and SAP HANA
provides all the database services that
S/4HANA requires.

•However, SAP HANA is far more than a


database. It is an application and data
management platform with a very large
portfolio of capabilities that power the new
applications that require real-time, instant
responses on a variety of different data
types.

•The figure illustrates the services provided


by SAP HANA, and as you can see, there
are quite a few
Recent trends in hardwareevolution
•SAP HANA takes full advantage of the recent trends in hardware evolution.

•Historically, the high cost of memory meant that only small amounts were available. This
caused a serious bottleneck in the flow of data from disk to CPU (see the figure), with the
CPU waiting idle for data to arrive through the tiny gateway.

•Now with memory prices falling, we have access to huge amounts. SAP HANA runs on
hardware with many terabytes of memory. In fact, with so much memory available, the
entire database of even a large organization can be stored completely inside memory, so
there is instant access to all data and wait times are eliminated. Memory is no longer the
bottleneck it once was.

•In addition to huge memory, the processors continue to improve at a phenomenal rate. We
have high-speed, multi-core processors that can take on complex tasks and process them
in parallel. This means response times for even the most complex analytical tasks, such as
predictive analysis, can be carried out in real time.

•SAP could have kept the same business applications produced 20 years ago, along with
the traditional databases that supported them, and installed all of these on the new
hardware. There would be some gains, but traditional databases and applications were
designed around old, restricted hardware architecture. This means they would not be able
to fully exploit the power of the new hardware.

•Put simply, the business software needed to catch up with advances in hardware
technology, so a complete rewrite of the business suite was required.
Column Store And RowStore
SAP HANA databaseProperties
•The SAP HANA database is fully in-memory, so it is very fast.

•The SAP HANA database is fully ACID-compliant. This means


Atomicity, Consistency, Isolation, Durability. This is the mark of a
database that is built to be 100% reliable for mission-critical
applications, where fast, simultaneous read and write operations are
applied to the same data sets. The ACID standard guarantees there will
never be partially updated records. You can fully trust the data at all
times.

•Most traditional business databases are row based. Some specialist


analytical databases are column based. SAP HANA is built to support
both types. Fast-moving transaction applications usually work better with
row store tables, whereas analytical applications that perform a lot of
aggregation work better with column store tables.

•Both storage types are needed in a system that handles both


transactional and analytical applications in one platform, as is the case
with SAP S/4HANA.
•Column store tables are incredibly efficient, especially for analytical applications
where access to data sets is not predictable and we often do not know which
columns are required. Column store tables work well with aggregation functions,
such as sum, average, min, and max. Column store tables are automatically
compressed, and can also be optionally partitioned. Column store tables are optimal
for parallel processing. Why do we need row tables at all?

•The downside to column store is the cost of reconstructing complete records from
the columns if all data is required by the application. This is the case when the
application is transactional and all fields are needed for an update, insert, and delete.
Additionally, for write-intensive applications, column store tables are not optimal
compared to row store tables.

•Row storage is still needed to support fast-moving transaction processing when


aggregation is not the main priority. Row store tables are not compressed and cannot
be partitioned.

•SAP S/4HANA combines transactional and analytical applications, so it utilizes both


column and row store tables.
Better Utilisation of Memory
Better Memory Utilization with ColumnStore
Classification of data and Memory Management
Disk is still required for logging and backup in case of power failure. However, the disk is
also required to store data that has been displaced from memory.

Memory is now huge and relatively affordable. It is technically possible to store an entire
enterprise database in memory, especially if you implement multi-terabyte memory.
However, for most organizations, most of the data that they own is not frequently used,
so they really do not need to implement such huge memory sizes. Only recent data is
frequently used.

This may well be only 5-10% of the entire company's data, which is called hot data. The
rest of the data, which makes up 90- 95%, is called warm data.

With SAPHANA, hot data is stored in memory, and warm data is stored on disk.

Whenever older data is needed by an application, it is loaded from disk to memory and the
application reads the data from memory. This data may not be needed again for a long
time, so it is displaced from memory at the moment when the memory is full and other,
more recent data, replaces it. The older data then goes back to disk until it is needed again.
For row store tables, loading and displacement happens at the row level.
This means all columns in the row, whether they are needed or not, are
loaded to memory. For analytical applications that require only few columns,
this is inefficient, as it involves moving all columns to memory, even those
not used.

For column store tables, loading and displacement happens at the column
and partition level. This means that only the required columns, and even
better, only the required partitions in the columns, are loaded to memory.
This is very efficient for analytical applications, which often only ask for
small portions of data
Reducing the dataFootprint
Benefits of reduced dataFootprint
•The data in the SAP HANA column store tables is automatically compressed in order to
reduce the data footprint.

•The following are a number of benefits associated with a reduced data footprint:

•You can get more data into the CPU cache, and therefore reduce main memory access, in
order to maintain high performance.

•You can fit entire enterprise databases into memory and avoid disk access.

•Operations such as backup and restore are speeded up as data sizes decrease.

•The amount by which data reduction can take place is driven by the shape of the business
data. Compression is most impressive when there is a lot of data repetition in the tables. An
example is a huge sales order table, in which the customer type is stored on each customer
order, but there are only three customer types. The customer type is repeated many times
across the table.

•Compression strips out the repetition and uses integers to represent the business values.
Then it uses special dictionary tables to hold the distinct list of business values and the
corresponding integers. This all happens in the background, and is not visible to the
business user. It is also not something with which the developer needs to be concerned.
Parallel Processing
A key theme of SAPHANA is parallel processing.
With the new hardware architecture, especially
utilizing the new multi-core processors, you can
ensure instant responses by spreading out the
processing tasks across the cores.

SAPHANA automatically spreads the workload


across all processors and ensures all parts of
the hardware are contributing to the
throughput.

SAPHANA is scalable, which means you can add


more processors, as required, to increase the
parallelization, and therefore the speed, of
processing.

In addition, you can manually partition column


tables to influence the parallelization based
on common business values that are accessed
frequently.

Parallel processing is a key enabler for real-time


processing, on which many new S/4HANA
applications are based.
Push Down Processing to SAPHANA
Data Intensive Processing
•In the past, the key job of the database layer was to listen out for requests for data
from the application server and then send that data to the application server for
processing. Once the data had been processed, the results were sent back down to
the database layer for storage.

•SAP HANA is capable of taking over many of the processing tasks from the
application server. All data-related tasks, such as aggregation, filter, sort,
calculate, and predict can be handled by SAP HANA.

•Now the application layer simply needs to tell SAP HANA what is to be done on the
data, and SAP HANA processes the data and send only the results. This is done in
memory, so speeds can be impressive. We call this code-to-data, as opposed to the
traditional way, which was data-to-code.

•The application layer is still needed with SAP S/4HANA to handle the complex
business logic that must be programmed in a business programming language. In the
case of S/4HANA, this is ABAP. However, many simpler applications can be built
directly on SAP HANA, with no need for an additional application server.
Multitenancy
A key theme of SAP HANA is parallel processing.
With the new hardware architecture, especially
utilizing the new multi-core processors, you can
ensure instant responses by spreading out the
processing tasks across the cores.

SAP HANA automatically spreads the


workload across all processors and ensures
all parts of the hardware are contributing to
the throughput.

SAP HANA is scalable, which means you can


add more processors, as required, to increase
the parallelization, and therefore the speed, of
processing.

In addition, you can manually partition column


tables to influence the parallelization based on
common business values that are accessed
frequently.

Parallel processing is a key enabler for real-time


processing, on which many new S/4HANA
applications are based.
Auto recovery
•SAP HANA utilizes memory for storage and once the
power is gone, we lose the data in memory.

•How does SAP HANA ensure we do not lose data


when the power goes, and how does it get back up and
running quickly? SAP HANA's solution for zero-
downtime is based on a two-phase approach.

•Every few minutes, SAP HANA automatically takes a


snapshot of the entire memory and stores this on a disk
layer. This is called a savepoint.

•What happens if the power goes off between


savepoints? Do we lose this data? We do not lose data
because between savepoints, every committed
transaction is also saved to a log area. This log area is
often based on flash memory (SSD) to ensure lightning
speed, so every update to the database is captured.

•When power is restored, SAP HANA automatically


readies the last savepoint, and also re-applies the
transactions from the log since that savepoint occurred,
to ensure the system is exactly where it was when the
power was lost.

•This all happens invisibly in the background.


Auto Recovery
Fit – Gap
•If a server fails, SAP HANA can automatically
swap it out to a standby server.

•Standby servers can be on warm standby,


which means they are ready to go
immediately and do not need to be started.
The data is loaded to memory from a backup
server. SAP HANA uses the savepoints and
log, as mentioned previously, to bring the
warm standby server up to date with the data.

•Standby servers can also be on hot standby,


which means the standby server is always in
sync with the live server, usually by continually
replaying the database log. If it is necessary to
swap over, this can happen with almost no
interruption to processing.

•For mission-critical applications and where


SLAs are implemented, you can ensure
customers' systems are always running by
implementing this approach. This auto-
recovery approach is referred to as failover.
Bigdata
•We know the digital world is
creating huge amounts of data. Do
we just keep loading this data to
SAP HANA?

•Technically, this is possible, but it


would not be efficient. Most
business applications refer to only
a small subset of data, and this is
usually the most recent data. You
should not fill SAP HANA's in-
memory database with data that is
old and hardly used. •storage options such as Big Data commodity server solutions
(Hadoop) and data archive systems.
•SAP HANA allows us to classify
our data as active and passive. •A key point is that, regardless of where the data physically
We also use temperatures as a resides, all of it is still available seamlessly to SAP HANA
reference to how hot (useful) the applications. Application developers do not need to know where
data is. Active, or hot, data is data data is, as this is managed by HANA.
that is recent or perhaps the focus
of a current analysis (even if it is •SAP HANA moves data across the storage tiers automatically
old). based on usage patterns and other programmable business
conditions. This ensures a customer's SAP S/4HANA will always
•Passive data is warm, or even run optimally, with no older data clogging up the database.
cold,data that is older and less
used
Realtime Event Processing
•SAP HANA can consume
data in many different
ways.

•Real-time data can be


consumed to power real-
time S/4HANA
applications. The Internet of
Things (IoT) means we will
connect large numbers of
devices that transmit •The following are examples of devices and
information continually. activities that could stream real-time data to
S/4HANA applications:
•It is important to remember •Sensors – machines
that real-time data
streaming is not the same •Clickstreams from Web activity
as real-time data loading.
Often, once the data is •Social media - respond to consumer
consumed and processed, sentiments (for example, Twitter)
it is of no further interest
and SAP HANA can ignore •Market stock prices
it.
•Energy consumption

•In-game sports analysis


IOT Data Synchronization
•SAP HANA can communicate with
devices (IoT) using remote data
sync. Often, such devices do not
need to be continually online with
SAP HANA. We call this
"occasionally connected".

•Devices can collect data locally,


with their built-in light databases,
and SAP HANA can periodically
collect this data. For example,
every hour a vending machine
passes its stock data to SAP
HANA. When an item is running
low, SAP HANA can pass back a
•The same technology is used to connect
message to the vending machine
that a refill is on its way. Remote
SAP HANA to remote environments that
data sync is bidirectional. may operate in hostile conditions, or where
the signal is not reliable, such as an
•S/4HANA applications can engineer working in a lift shaft where the
communicate with IoT devices. signal is poor, or an oil rig where a satellite
There are many innovative passes only once per day to provide
enterprise applications that can communication back to HQ
benefit from communication with
devices in the IoT.
Data Access From Anywhere andAnytime
Real-time streaming and remote data
sync, SAP HANA has many other
options for data provisioning.

•Smart Data Access (SDA) allows SAP


HANA to access remote database
tables and files from any source, as if
the data was loaded to SAP HANA. A
great use case for this is the integration
of Hadoop or data archives, where
occasional access to data is required.

•Smart Data Integration (SDI) and


Smart Data Quality (SDQ) provides
real-time data replication from any
source, with the option of enhancing
the data quality during the loading
process.

•SAP HANA is fully integrated with


existing and well-known data-loading
tools, such as SAP LT Replication
Server and SAP Data Services for
real-time and batch data loading.
Data Access From Anywhere andAnytime
•If all we asked of SAP HANA was to
support the database requests for
S/4HANA, then we would be using
only a fraction of SAP HANA's
capabilities.

•SAP HANA is not just a database,


it is also a powerful data
processing engine with many built-
in capabilities that can enable
organizations to develop
innovative applications integrating
S/4HANA. We call this "extending
the core", with the core as SAP
S/4HANA.

•Companies implement a digital


platform, such as SAP S/4HANA, not
only to run their core business
processes, but to take full advantage
of the new digital world where
innovative, disruptive applications
can be game changing.

•This is why companies will look to


exploit the full potential of the SAP
HANA platform to move beyond the
core
Text Processing With SAP HANA
•Between 70% and 80% of data in an
organization is unstructured, and most
of this unstructured data is text based?
•The majority of the most powerful and
insightful business information is locked
up in text. Unlocking it should be taken
seriously. SAP HANA has native text-
processing capabilities. These include
the following:
•Text search: Fuzzy search (Google-like
searching) helps users with fault-tolerant
searches during data input. It helps to
improve data quality by suggesting •Text mining: Which documents cover similar topics?
spellings and codes. It helps to avoid What is the key subject being discussed in a series of
duplication by suggesting similar documents or emails?
matches before a user creates another
customer account.
•SAP HANA text processing handles multiple
•Text analysis: Identifies key entities in
languages. It can identify the language
text. For example, how many times was
automatically from the text and apply appropriate
company x mentioned this week in
linguistic rules.
tweets that also mentioned words
relating to acquisition? Aggregated
•SAP HANA text-processing capabilities are already
sentiment analysis of a new product
very well exploited in S/4HANA applications, and
helps you to learn what consumers customers can develop their own applications using
think, so you can react and make the same
improvements.
Special data Analysis withHANA
•SAP HANA can store and process spatial
data. For example, we can identify the exact
location of each customer and when the
customer is browsing our online catalog we
can suggest the nearest pickup location.

•SAP HANA is fully integrated with industry


leading partners who specialise in spatial
processing. These include Google, ESRI,
Pitney Bowes and Tom.

•There are many use cases for spatial


data. These include:Live Traffic information
- communicate to emergency services
driver

•Sport - In-game football analysis - add geo


sensor to ball and players and track
movements, distances, contacts etc.

•Energy companies - map their pipes,


cables, identify closest engineer, or identify
nearby assets that could also be cleaned /
maintained to save on separate call out
Predictive Analysis with SAPHANA
PredictiveAnalysis
•A key theme running through SAP S/4HANA is embedded analytics. In many
cases, this means adding in predictive capabilities to a transaction flow. Customers
can continue to build their own applications that embed predictive capabilities.

•For example, an administrator is providing security clearance to sensitive data for


a new employee. However, during the clearance process, SAP HANA identifies
and alerts the administrator to a suspicious pattern of system access by the
employee that does not fit the profile of this type of worker.

•SAP HANA has an extensive built-in library of powerful predictive algorithms and
business functions to suit different analysis scenarios, as shown in the figure.

•In addition to the built-in algorithms, SAP HANA is integrated with the 'R 'public
libraries, where
thousands of additional algorithms can be found.

•With SAP HANA's ability to manage huge data volumes, and at speed, real-time
predictive analysis is possible and can add huge value to business transactional
processing to offer decision support in-line. You can find many examples of
embedded predictive analysis in S/4HANA applications.
Reasons To Choose SAP HANA - IOT, Big data,Social
media, Real time data

• Smart Meter Data Analytics Improves


Grid Reliability

• A Single View of Assets to Optimize Grid


Operations

• Predictive Equipment Maintenance to


Prevent Blackouts
Reasons To Choose SAP HANA - IOT, Big Data,Social
media, Real time data
All Major Industries now collect and process large volume of data as
business models have changed .

Example : Utilities – electricity


Past : No account on How much bill and consumption of power from
customers . Power was shortage . Now On Oil industry is there and on account
go suppress power, alternative entry .

Implementation of smart meter , Smart Grid , Feeder monitoring system and


SCDA for substation maintenance etc are generating huge data . This data is
being analyzed on real time in dashboards.
To process this ,AP Transco already implementing SAPS/4 HANAand other
discussions to follow.
To manage the data real time and huge volumes the solution is Big dataon
HANA.
What is OLAP &OLTP
How data Gets intoOLTP
OLAP VS OLTP
OLTP & OLAP optimization
Column based Tables Vs Rowbased
• Row Storage - It stores table records in a sequence ofrows.
• Column Storage - It stores table records in a sequence of columns i.e. the
entries of a column is stored incontiguous memory locations.

Traditional databases store data simply in rows. The HANA in-memory


database stores data in both rows and columns. It is this combination of
both storage approaches that produces the speed, flexibility and
performance of the HANAdatabase.
• Minimum Expected Compression of database is 5 time . Our current 1 TB
OLTPdatabase may become 200 GB

• Monthly data growth may be 20gb instead of 100 GB in the traditional


database
Feature of In -memory database

• Mostly Colum based tables

• Should be able to support both row based andColum based tables

• Low data footprint

• Realtime data reporting


What is In-memory data base?

• An in-memory database system is a database management system that stores


data entirely in main memory. This contrasts to traditional (on-disk) database
systems, which are designed for data storage on persistent media.
• Because working with data in memory is much faster than writing to and
reading from a file system, IMDSs can perform applications’ data management
functions an order of magnitude faster.
• Because their design is typically simpler than that of on-disk databases, IMDSs
can also impose significantly lower memory and CPUrequirements.
Column based Tables Vs Rowbased
Column based Tables Vs Rowbased
Which is suitable for OLTP andOLAP
Column Vs Row
Row and Column with DeltaMerge
Row for OLTP and Colum forOLAP

Row/Column – OLTP/OLAP
• Row stores are good fit for OLTP
• Reading small portions of a table, but often many of the columns
• Frequent changes to data
• Small (<2TB) amount of data (typically working set must fit in ram)
• “Nested loops” joins are good fit for OLTP
Row for OLTP and Column forOLAP
Row/Column – OLTP/OLAP

• Column stores are good fit for OLAP

• Read large portions of a table in terms of rows, but often a small


number of columns
• Batch loading / updates

• Big data (50TB-100TB per machine):

• Compression capabilities comes in handy

• Machine generated data is well suited


Column basedAdvantages
Column-based tables have advantages in the following
circumstances:
1.Calculations are typically executed on single or a few columns
only.
2.The table is searched based on values of a few columns.
3.The table has a large number of columns.
4.The table has a large number of rows and columnar
operations are required (aggregate, scan etc.)
5.High compression rates can be achieved because the majority
of the columns contain only few distinct values (compared to
number of rows).
Row based advantages
Row based tables have advantages in the following circumstances:

1. The application needs to only process a single record at one time (many selects and/or updates
of single records).

2.The application typically needs to access a complete record (or row).

3.The columns contain mainly distinct values so that the compression rate would be low.

4.Neither aggregations nor fast searching arerequired.

5.The table has a small number of rows (e. g. configuration tables).


To enable fast on-the-fly aggregations, ad-hoc reporting, and to benefit from compression
mechanisms it is recommended that transaction data is stored in a column-basedtable.

The SAP HANA data-base allows joining row-based tables with column-based tables. However, it is
more efficient to join tables that are located in the same row or column store. For example, master
data that is frequently joined with transaction data should also be stored in column-based tables.
HANA Row VsColumn
Limitation of standard data base and In-memorydatabase
• Potential loss of data and limit on database size. When this is fine, you should
certainly use RDM’s in memory solution.

• three schemes for dealing with the durability issue. Each has advantages and
challenges:

1)Write data to disk as well as putting it in memory. The challenge here is


whether you can write to the disk fast enough to keep up with the data that is
being loaded into memory.
2)Put the data in memory on two different machines. The risk here is if both
machines go down, you lose the data.
3)Use a combination of #1 and #2 above. Putting data in-memory on two
machines provides some level of protection that allows time for a background
process or asynchronous process to write data out to disk. In this case you
need to understand what scheme a vendor is using and whether it meets your
service level agreements.
• memory is much more expensive than spinning disk.
SSD dataStore
• Like a memory stick, there are
no moving parts to an SSD.
Rather, information is stored
in microchips.

Conversely, a hard disk drive


uses a mechanical arm with
a read/write head to move
around and read information
from the right location on a
storage platter. This difference is
what makes SSD somuch faster.
Hard Disk or SSD or DRAM
RAM Disk VsSSD

• RAM Disk vs SSD – Ten Times Faster Read and Write Speed
via RAM Virtual Disk

• RAM Disk is a program that takes a portion of your system


memory and uses it as a disk drive.
• This is same as in memory data base of Hana
In the age of SSD's why are in-memory databases like SAP
HANA needed

• In-memory processing in SAP HANA is not only about storing


data in RAM, but as well about cache-aware data structures
and algorithms.

• It is not only about how to retrieve data quickly from RAM,


but as well how to retrieve and process data so that CPUs'
caches are best utilized.
Advantages and Disadvantages of Standard Dbase and how
did ERP survive till now usingstandard Database

•The Process used is Data redundancy


•Same data is kept in many places
•Aggregation tables are built
•Business warehouse is built for reporting
•Still the reports are old never real time

•Whereas in HANAthe reports near real time


Single CPU Processing

1000 requests

Single CPU

500
500
Core 2
Core 1
Multi CPU Processing MultiCore

1000 requests

CPU1 CPU2 CPU3 CPU4 CPU


CPU5 CPU6
8

CORE CORE CORE CORE CORE CORE CORE


CORE CORE CORE CORE CORE CORE CORE
2 2 1 1 2 1 2
1 1 1 2 2 1 2
Hana Architecture
HANA Integration with IOT data or Big data in Utilities
HANA IOT
HANA Live
Hana Big data withVora
• Big Data’ as name implies is big volume of data that inundates a business
every minute of every day. It could be in both structured and unstructured
format. Big data can be analysed for insights that lead to better decisions
and strategic business moves, and will fundamentally change the way
businesses compete and operate.

• A simple example scenario is, while processing a sales order, the business
want to give special discounts to customers based on their transactions
history (say for last 30 years). The recent transaction data are available in
Hana and the very old data are moved to Hadoop

• In fact the analysis has to be done over data made by correlating the
recent data residing in Hana and old data residing in Hadoop and it has to
be processed on-the fly in faster fashion. Being an in-memory database
Hana runs very faster. SAP Vora is also an in- memory query engine and it
can access data from Hadoop and process some of them in a faster way.
• SAP Vora builds structured data hierarchies for the unstructured data in
Hadoop and integrates it with data from HANA, and then through the
Apache Spark SQL interface it enables OLAP-style in-memory analysis on
the combined data.

• Vora serves the purpose as a mediator when the compatibility question


rises in between SAP HANA and Hadoop. Spark is not well compatible
with HANA Systems and HANA Clouds, so SAP built something which
follows the Spark framework and also have HANA Adapters for data
connectivity.

• Typically, all this data in Hadoop is unstructured and SQL cannot be run
immediately on top of that. And that’s where Vora adds value and also
could be a bridge between HANA & Hadoop
How In-memory data base willhelp

• Faster Processing
• Ability to give real time analysis
• Live dash boards
• Lesser data foot print on account no data redundancy
• Single source of truth
Compression

• Data is compressed by different compression techniques (e.g.


dictionary encoding, run length encoding, sparse encoding,
cluster encoding,indirect encoding) in SAPHANAColumn store.

• When main memory limit is reached in SAP HANA, the whole


database objects (table, view,etc.) that are not used will be
unloaded from the main memory and saved into the disk.

• These objects names are defined by application semantic and


reloaded into main memory from the disk when required again.
Under normal circumstances SAP HANA database manages
unloading and loading of data automatically.

• However, the user can load and unload data from individual table
manually by selecting a table in SAP HANA studio in respective
Schema- by right- clicking and selecting the option "Unload/Load".
What is compression ratio
Compression Technologies
Multi –Core Parallel
Multi User parallel
HANA Streaming
HANA Streaming
HANA IOT
HANA IOTApplication
Architecture
HANAArchitecture

SAPHANAServer consists of:

1.Index Server
2.Pre-processor Server
3.Name Server
4.Statistics Server
5.XS Engine
Architecture Discussion
• Key points of the HANAarchitecture:

• In-Memory Database – the entire database is running in memory


Combines OLTP, OLAP, and HW Acceleration, eliminating unnecessary
complexity and latency

• Strict hardware specifications for performance designs reasons – 16GB of


memory per CPU core, fixed ratio of disk data storage to 4 times RAM, log
storage = 1 times RAM

• Two types of Relational Stores in HANA – Row Store (Common in previous


traditional databases) and Column Store (is what HANA uses primarily)

• Persistency Layer – In Memory is volatile, so persistency later makes sure all


data in memory is also stored on hard drive storage

• Not only is data stored in HANA memory, but what makes it faster is that
the calculations are made in the database and only the results transfer to
the application layer
Data Loading to HANA

• SAPLandscapeTransformation (SLT),
• Data Services (DS),
• Smart Data Access (SDA)
• SAPHANAthe major focus is real-time
• Data Services can do Near real-time and batch processing.
Data Provisioning For SAPHANA

Data provisioning is the process of loading data into SAP HANA.


Depending on the requirement scenario, the loading can be done once or
on regular basis(real time or scheduled).
HANA Spatial-Usage
Data classification

•Hot- Data that resides in your HANAMemory


•Warm- Data that resides in your HANADisk
•Cold - Data that resides out of your HANA
What is temperature data:
HOT DATA:

• This is the area where 100 % of your PRIMARY IMAGE DATA is in the
HANA in- memory space (RAM) and is instantly available for all
operations.

• In the BW world, this is typically the Info Cubes and Standard DSOs as they
constitute the reporting and harmonization (EDW) areas respectively as
show below. They are very frequently accessed for reporting and
harmonization purposes and hence is the ideal candidates for being fully in-
memory and to fully benefit from the HANA capabilities.
COLD DATA
• This is the area where 100 % of your
PRIMARY IMAGE DATA is in a
SECONDARY DATABASE (ON DISK) and
the response is slightly slower than
HANA but still offers reasonably fast
READ ONLY access to data for reporting
purposes, as if they were in one
database.
WARM DATA

• This is the area where the PRIMARY IMAGE DATAis


in the DISK storage of HANA Database instance, but
is always available on request. Using this you can
manage your LESS RECENT DATA and LESS
FREQUENT DATA more efficiently within the HANA
database such that data is instantly available for
READ, WRITE, UPDATE etc (all operations), but still
offers the lower TCObenefit
Storage of TemperatureData
How HANA is optimized both for read and write

• Read write optimization is achieved in HANA by the


concept called Delta Write
What is SOH?

• SOH: Suite on HANA


• Here database is HANAwhere as application is ERPSuite
HANA live
• SAP HANA Live (previously known as SHAF – SAP HANA Analytic Foundation) is solution
for real-time reporting on HANA. It is a separate package that comes with predefined
SAPHANA content across the SAPBusiness Suite.

• SAP HANA Live provides SAP-delivered content (similar in concept like SAP BW
content), in form of SAP HANA calculation views for real-time operational reporting.
The calculation views spans across majority of ECC modules (FI, CO, MM, PP, SD, PS,
CRM, GTS, AM and GRC). The content is represented as a VDM - virtual data model,
which is based on the transactional and master data tables of the SAPBusiness Suite.

Currently more than 2000 views are delivered in HANA Live Package.
HANA Fuzzysearch
• Full Text Search
• Full Text Indexing
• Fuzzy Search

• Fuzzy search is the technique of finding strings that match a pattern


approximately (rather than exactly).It is a type of search that will find
matches even when users misspell wordsor enter in only partial words
for the search.
A Real World Example:
If a user types "SAP HANO " into Yahoo or Google (both of which use fuzzy
matching), a list of hits is returned along with the question, "Did you mean
"SAPHANA ".
Top Business Use-cases of textAnalysis:
• Brand/ Product/ Reputation Management Market research and social media
monitoring, i.e. what people are saying about my brand or products

• Voice of the Customer/ Customer Experience Management Do I need to


step in and offer customer service?

• How many people recommend my brand vs. advocate against it?


• Search, Information Access, or Questions Answering Which bloggers are
negative towards USAPolicies?

• Which of the hotels on India get great reviews for the room service?

• Competitive Intelligence What competing products are people considering


and why?
• Are competitors‘ media sped generating purchase intent?
HANA modelling Introduction:
Hana Frontend Tools
Server Sizing
Sizing HANA
• Important SAP Notes about sizing HANA:
• 1514966 – Sizing HANA
• 1704499 – System Measurement for License Audit
• 1637145 – Sizing BW on HANA
• Static + Dynamic Ram requirements determine sizing. To do this, determine
uncompressed data volume to be loaded, then apply compression factor, then multiply
result by two.
• Only 50% of the total RAM should be used for the in-memory database. The other 50% is
needed for temporary objects (for example, intermediate results), the operating system,
and application code.
• Disk size for the persistence layer is equal to 4 times RAM
• Disk size for the log files equals 1 times RAM
• CPU equals 300 SAPS per active user. Never to exceed 65% of CPU server load.
• BW on HANA has a quick sizing tool available at: https://service.sap.com/quicksizing
• HANA is available in incremental sizes: XS, S, M, L
SAP HANADatabase:
SAP HANA isan in-memory database:
• It is a combination of hardware and software made to
process massive real time data using In-Memory computing.
• It combines row-based, column-based database
technology.
• Data now resides in main-memory (RAM) and no longer
on a hard disk.
• It’s best suited for performing real-time analytics, and
developing and deploying real-time applications.
Smart Data Access in SAPHANA:
HANA DataAnalysis

• Sensor data from equipment is monitored for trends or


correlations that indicate a problem, alerting an operator to take
immediate action before equipment damage occurs

• A commodity pricing application continuously adjusts quoted


prices in response to market conditions – where delays mean
either lost business or lost profit.

• IT system events are continuously monitored to watch for


patterns that indicate a possible security threat

• User actions on a web site are analysed to determine the best


offers to show, not just based on historical data for the user but
also considering current context
Server Sizing
• SAPHANA Sizing
• Sizing is a term which is used to determine hardware requirement for SAP HANA system, such as RAM,
Hard Disk and CPU, etc.
• The main important sizing component is the Memory, and the second important sizing component is
CPU. The third main component is a disk, but sizing is completely dependent on Memory and CPU.
• In SAP HANA implementation, one of the critical tasks is to determine the right size of a server
according to business requirement.
• SAPHANA DB differ in sizing with normal DBMS in terms of –
• Main Memory Requirement for SAP HANA ( Memory sizing is determined by Metadata and Transaction
data in SAP HANA)
• CPU Requirement for SAPHANA (Forecast CPU is Estimated not accurate).
• Disk Space Requirement for SAPHANA ( Is calculated for data persistence and for logging data)
• The Application server CPU and application server memory remain unchanged.
• For sizing calculation SAPhas provided various guidelines and method to calculate correct size.
• We can use below method- 1.Sizing using ABAP report.
• 2.Sizing using DB Script. 3.Sizing using Quick size Tool.
Quick sizer
Average: Starttime: 9 Endtime: 18
Peak: Starttime: 12 Endtime: 13

Valid f r o m 23.0 2.2016 to 30.05.2016

T a b l e 41: en t Us ers - Standard Sizing © SAP SE


Concurr Sizing Timeinter T I : Average/P No. of con No. of con No. of No. of m o Checks fo ID for mu l Fiori A p p s A short te
Element Sizing Y/P/H/ S A/P L o w activi M e d i u m con M o n . Arch. ID FIORI Short text
Element A L M- S A a H i g h activ _ _
U S ER S A _ _
MM-USER P P - S A _ _
USER PS- S A _ _
USER _ _
A
Q M - U S E R
hput -
Stan
dard © SAP SE
T a b l e 4 2 : T h r o u g Timeinter Sizing Sizing o b j No. of dis
No. of m o
Checks fo
Start o f p r
End of ID for mu l Fiori A p p s A short te
Sizing E l e me n t Average/P Avg. n u m No. of cha pro
Sizing E l e m e n t TI: Y / P / H / A / P Objects Items % chg. % dsp. M o n . Arch. S.t. E.t. ID FIORI Short text
A L M - P M Y A _ 9 18 _
A L M - P M P P _ 12 13 _
M M - I M Y A _ 9 18 _
M M - I M P P _ 12 13 _
M M - P U R Y A _ 9 18 _
M M - P U R P P _ 12 13 _
PP-CONF Y A _ 9 18 _
PP-CONF P P _ 12 13 _
PP-R EM Y A _ 9 18 _
PP-R EM P P _ 12 13 _
PP-SFC Y A _ 9 18 _
PP-SFC P P _ 12 13 _
Q M - I M Y A _ 9 18 _
Q M - I M P P _ 12 13 _

T a b l e 43: T h r o u g h p u t - P r oj e c t © SAP SE
Sizing Element Timeinter System Sizing o b j Structural Average n Average n N o . of cha N o . of dis No. of m o Checks fo Start o f p r End o f ID fo r m u l Fiori A p p s A short te
Sizing E l e m e n t T I : Y / P / H / Average/P Objects W B S Netw. Act/nw Changes Displays M o n . Arch. S.t. pro ID FIORI Short text
A/P E.t.
PS P Y A _ 9 18 _
PS P P P _ 12 13 _

T a b l e 44: T h r o u g h p u t - M a t erial rements anning © SAP SE


Sizing Element Timeinter Requi Pl Avg. Average n Purchase Purchase D u r a t i o n o N u m b e r o % o f B O M N u m b e r o Start o f p r End o f p r o ID f o r m u l Fiori A p p s A short t e
Sizing E l e m e n t TI: Y / P / H / Average/P no. o C o m p ReorderR Non-reordHoriz. % chg. % dep. % LTS S.t. E.t. ID FIORI Short text
M R P R U N P A/P Plan. orde 12 13 _
P

Legend: W it h
e xa m ples
T a b l e ... Table ding
hea S i z i n g o b j e c t s ... C e l l p
toolti Objects Cell ption st t h r e e co l u mn s of a
descri -in the s of the fir
A D o n o t fill cell
Inputfield
Inputfield
T Shirt Sizing

You might also like