techbytes

While HANA is SAP's answer for Big Data,then it is interesting to see how does HANA fits into fits into Big data paradigm. In particular, we will talk about HADOOP stack of technologies in view of Big Data. Welcome to world of unstructured data and HADOOP is ideal for processing large data sets & batch processing where response time is not a concern. Here Schema is not a concern as we are dealing with unstructured data and its not  optimized for data updates/inserts. It works with principle of write once, read always. Also random reads are not supported and data can only be appended. Having said above things, HANA follows for rows/columns storage model and we have to define schema before storing data. HANA is In-memory appliance thus supports faster read times/ on-the-fly aggregates/joins. After highlighting merits of both worlds, we can see that both comes from different worlds; HANA from world of structured with fixed schema optimized for real time access , HADOOP from...

Before we start, welcome to unstructured data. We will quickly review where current relational databases are lagging and need of new generation No-SQL databases. Examples are MongoDB, Cassandra, HBASE.                                                      Relational Databases are designed in times when memory costs were high and disk seek times are high. So the design of  database was focused on optimizing the memory required for string data. Hence  Normalization  of data model was promoted(No data redundancy). Normalized data model is also optimized for Inserts/Updates. Although Index are supported for sake of faster access,  primary concern was saving the space. However, we currently live in a world where memory costs are so cheap such that faster reads, Real-time systems are the need of hour. In current situations, we can comprom...

Project Transform  is about redesigning BW data flows while leveraging HANA's number crunching power. Goals :  1. Utilize HANA in-memory computing by pushing Stat/End Routines/Field Routines onto DB layer  2. Reduce intermediate staging DSO's there by reducing data foortprint, avoiding activation times 3. Promoting Virtual data mart layer 4. Providing users with up-to-date data rather than pre-computed data 5. Enabling users to query at item level rather than at summarized level(Cubes) 1.  Utilize HANA in-memory computing by pushing Stat/End Routines/Field Routines onto DB layer  Routines from data flow will be included in the generated program and DTP spends lot of time doing processing on ABAPAS. An ABAP program spends more than 50% of its execution time in ABAPAS normally. These routines can be efficiently pushed down to HANA layer by creating Stored procedures and calling them from Routines. Else we can create a Calculation/Analytic view /Stored...

Rank Node : We have new node type introduced in calculation views, Rank Node. This serves the same purpose of Exceptions from Bex. Instead of swamping  user with lot of data, we could restrict to display only TOP N values. The value of N could be fixed or based on a input parameter. In addition to Calculated, Restricted Attributes/ Measures , Rank node will further enhance OLAP toolkit of HANA Appliance. Temporal Join : ABAP vs HANA Native Data Types :   Every table in SAP will have two definitions. ABAP run time object and Database Object. From SE11, we can navigate to both and you can spot differences between them. reason being, ABAP Language  comes with some native data types. Examples being DATS, TIMS, CUKY, UNIT, CURR etc. These data types will mapped onto underlying Database native data types. Hence we have two representations of same object. Database interface helps us in converting Open SQL queries into underlying Database SQL. Lets shift our focus to Impo...

Analytic views comes with constraint that Measures should be coming from a single of Data foundation, although data foundation could contain any number of tables joined. Previously, we used model multiple Analytic views and combine them using JOIN node of an calculation view, in order to facilitate to Measures from multiple tables.  Star Join solves this by allowing measures coming from multiple tables. So we don't have to use multiple Analytic view to achieve this.  However Analytic views comes enriched with master data through Attribute views. To compensate this, We have Calculation Dimensional Models introduced. These artifacts are same as  Attribute views, but can only be used in a Star Join. So this solves out Master data enrichment issue while using Star Join. Introduction of Star Join Node and Calculation Dimensional Models  certainly introduces more uses cases for Calculation views and avoids scenario of creating multiple Analytic views for e...

owing to its complex landscape, we have just too many components that are integrating. As shown above, we will below components typically in a landscape. 1. SAP HANA Box 2. SAP SLT 3. SAP BODS 4. SAP BI 5. SAP ECC/CRM/SRM 6. Legacy System 7. SAP BOBJ Suite SAP HANA Box, it self has many components (to be continued...)