Embed Size (px)
Citation preview
DEGREE PROJECT, IN , SECOND LEVELCOMPUTER SCIENCESTOCKHOLM, SWEDEN 2015
A new approach for EnterpriseApplication Architecture for FinancialInformation SystemsAN INVESTIGATION OF THE ARCHITECTURALIMPLICATIONS OF ADOPTING SERIALIZATIONAND RPC FRAMEWORKS, NOSQL/HYBRIDDATA STORES AND HETEROGENEOUSCOMPUTING IN FINANCIAL INFORMATIONSYSTEMS
PETER ERIKSSON
KTH ROYAL INSTITUTE OF TECHNOLOGY
SCHOOL OF COMPUTER SCIENCE AND COMMUNICATION
A new approach for Enterprise ApplicationArchitecture for Financial Information Systems
An investigation of the architectural implications of adopting serialization and RPC
frameworks, NoSQL/hybrid data stores and heterogeneous computing in Financial
Information Systems
PETER ERIKSSONEMAIL [email protected]
Master’s Thesis at CSC
Supervisor: Fredrik Fagerlund
Examiner: Stefan Arnborg
AbstractThis thesis investigates the architectural implications ofadopting serialisation and remote procedure call (RPC)frameworks, NoSQL/hybrid data stores and heterogeneouscomputing in financial information systems. Each tech-nology and its implications is analysed separately togetherwith its benefits and drawbacks for the system implemen-tor.
The investigation shows that all three technologies canhelp alleviate technical challenges facing financial enter-prises; but they all come at a cost of complexity.
ReferatInverkan på ’Enterprise Application
Architecture’ för finansiellainformationssystem
Denna rapport undersöker inverkan av serialiserings- ochfjärrproceduranropsramverk (RPC), NoSQL/hybrid data-lagringslöningar samt heterogen beräkning på arkitekturenav finansiella informationssystem. Varje teknologi och dessinverkan analyseras var för sig tillsammans med dess för-och nackdelar för systemutvecklaren.
Undersökningen visar att alla tre teknologierna kan av-hjälpa de tekniska utmaningar som finansiella aktörer stårinför; men alla medför en komplexitetskostnad.
Contents
1 Introduction 11.1 Problem Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Aim and Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Requirements and Delimitations . . . . . . . . . . . . . . . . . . . . 21.4 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.1 Architectural Considerations for Financial Information Systems 31.4.2 System Architecture . . . . . . . . . . . . . . . . . . . . . . . 31.4.3 Computational Library . . . . . . . . . . . . . . . . . . . . . 31.4.4 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
I Architectural Considerations for Financial Information Sys-
tems 5
2 Current standard of Enterprise Information Systems 72.1 n-Tier architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Three Principal Layers . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Technical Challenges for Financial Information Systems 113.1 Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.4 Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4 Technical Insights from the largest websites 134.1 Remote Procedure Call . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1 Apache Thrift . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.1.2 Apache Thrift IDL . . . . . . . . . . . . . . . . . . . . . . . . 144.1.3 Protocol bu�ers . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2.1 CAP theorem . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2.2 RDBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2.3 Cassandra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
II System Architecture 19
5 System Overview 215.1 Improving the Highways as well as the Access Roads . . . . . . . . . 225.2 Extending the Three Tiers . . . . . . . . . . . . . . . . . . . . . . . . 235.3 Speeding up the Arithmetic . . . . . . . . . . . . . . . . . . . . . . . 25
6 Components 276.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.3 Bridging the Domain Gap . . . . . . . . . . . . . . . . . . . . . . . . 286.4 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
IIIData Model 29
7 RDBMS 317.1 custom_behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327.2 strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327.3 custom_column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327.4 symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347.5 daily_price . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347.6 daily_option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8 NoSQL 358.1 timeseries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
IVConnecting the Layers 37
9 Sample IDL 399.1 Basic building blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . 399.2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
V Computational Library 41
10 Matrix Methods 4310.1 Matrix Multiplication . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.1.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4310.1.2 Naive algorithm Java Implementation . . . . . . . . . . . . . 4410.1.3 Optimised Implementation . . . . . . . . . . . . . . . . . . . 4710.1.4 GPGPU Implementation . . . . . . . . . . . . . . . . . . . . 4910.1.5 Results and Analysis . . . . . . . . . . . . . . . . . . . . . . . 51
11 Approximation Algorithms 5311.1 Implied Volatility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
VIEmpirical Findings & Analysis 55
12 RPC and serialisation 5712.1 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5712.2 Drawbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5812.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
13 Separation of Database-Tier 5913.1 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5913.2 Drawbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5913.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
14 Heterogeneous computing 6114.1 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6114.2 Drawbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6114.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
15 Final Reflections of the Study 6315.1 Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
15.1.1 RPC and serialisation . . . . . . . . . . . . . . . . . . . . . . 6315.1.2 Separation of Database-Tier . . . . . . . . . . . . . . . . . . . 6315.1.3 Heterogeneous computing . . . . . . . . . . . . . . . . . . . . 64
Bibliography 65
A Financial Instruments 67A.1 Cash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A.2 Stocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A.3 Bonds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A.4 Derivatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
A.4.1 Futures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68A.4.2 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68A.4.3 Swaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.5 FX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
B Portfolio Theory 71B.1 Structure of a Portfolio . . . . . . . . . . . . . . . . . . . . . . . . . 71B.2 Modern Portfolio Theory, MPT . . . . . . . . . . . . . . . . . . . . . 71B.3 MPT as a Mean-Variance optimisation problem . . . . . . . . . . . . 72
B.3.1 Unconstrained Optimisation . . . . . . . . . . . . . . . . . . . 72B.3.2 Optimisation with equality constraints . . . . . . . . . . . . . 72
B.3.3 Optimisation with equality and budget constraints . . . . . . 72B.4 The Opportunity set . . . . . . . . . . . . . . . . . . . . . . . . . . . 73B.5 The E�cient frontier . . . . . . . . . . . . . . . . . . . . . . . . . . . 73B.6 The tangency portfolio . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Chapter 1
Introduction
Fredrik Fagerlund at E�con Nordic AB has a lot of experience with financial in-formation systems and the financial enterprises that rely on them. Fredrik commis-sioned this study to investigate the potential benefits of new technologies that hasbeen developed in the last decade.
1.1 Problem BackgroundFinancial institutions and other financial enterprises currently face many challenges.New regulations are put in place in an e�ort to lower the risk of another financialcrisis. These often result in resource demanding calculations for risk measurements.Demands for more transparency and lower fees puts pressure on the budget side.Traditionally well capitalised, the IT departments of the financial enterprises arenow being asked to do more with less.
1.2 Aim and ObjectiveE�con Nordic AB works with financial enterprises to implement Financial Informa-tion Systems and custom extensions of these systems to meet business and regula-tory requirements. The aim is to find out how these technologies can be used to helpfinancial enterprises with the challenges they face with regard to their informationsystems.
1
CHAPTER 1. INTRODUCTION
1.3 Requirements and DelimitationsThe technologies that have been identified as potentially being valuable in aidingwith the challenges for Financial Information Systems are:
serialization and RPC (remote procedure call) advances in serialization andRPC frameworks promise higher performance serialization /deserialization,smaller messages and support for many programming languages.
Database new approaches to database design promise horizontal scaling.
Heterogeneous computing by taking advantage of the increased computing ca-pabilities of GPGPU (General-purpose computing on graphics processing units),DSP (digital signal processor) and even FPGA (field-programmable gate ar-ray).
2
1.4. THESIS OUTLINE
1.4 Thesis outline1.4.1 Architectural Considerations for Financial Information SystemsThe first part goes through the current architectural standard for Enterprise Infor-mation Systems and the specific challenges to financial information systems. It thenoutlines two of the technologies investigated in this thesis when analysing the solu-tions that the largest websites in the world have adopted when faced with similarchallenges as traditional enterprises.
1.4.2 System ArchitectureIn the second part, an envisioned architecture of a portfolio management system ispresented where the technologies investigated are exemplified in order to illustratetheir usage.
1.4.3 Computational LibraryIn the third part, the performance benefits of heterogeneous computing are analysedand exemplified.
1.4.4 AppendixAppendices with explanations financial instruments and portfolio theory are pro-vided.
3
Part I
Architectural Considerations forFinancial Information Systems
5
Chapter 2
Current standard of EnterpriseInformation Systems
2.1 n-Tier architecture
A clear trend in enterprise applications during the last decades has been to layerthe system. The first step in this direction was taken when the relatively cheapPCs took over from the mainframes and mini-computers. The result was the 2-Tierarchitecture, otherwise known as client-server system [18].
The main parts of the logic resided in the client layer and the server was oftenlittle more than a thin wrapper around a relational database. Resulting in systemsthat were hard to administer and since the database layer was relatively exposed,quite often vulnerable to many types of security exploits. One prominent securityvulnerability is SQL injection [7].
Architects needed to solve this problem and by striving to move as much aspossible of the logic to the server-side and insulating the database in a third layer,the 3-Tier architecture was born.
7
CHAPTER 2. CURRENT STANDARD OF ENTERPRISE INFORMATION SYSTEMS
2.2 Three Principal LayersBrown named the three layers and defined the separate responsibilities forming thestandard pattern for the way enterprise applications are built today and they aredescribed by Fowler [2] [18].
Presentation The ’Client Tier’ is responsible for what is visible to the user.
Domain The ’Business Logic Tier’ where all the logic of the system resides.
Data Source The ’Database Tier’, mostly represented by a relational database.
Separating the design into three layers have brought benefits but there is still con-fusion on which pieces of logic go where. As Fowler points out [18]:
You can run business logic all on the server or all on the client, oryou can split it. Again, all on the server is the best choice for ease ofmaintenance.
8
2.2. THREE PRINCIPAL LAYERS
There are many arguments for putting all the business logic on the server andthis becomes even more apparent when considering multi-platform solutions. Con-structing any information system with the requirement that the system should beusable from a Windows PC, Mac, Linux workstation, smartphone or the web natu-rally lend itself to put as much logic as possible in the server and making the clientsas thin as possible. At the extreme, which has become more and more commonrecently, is to refrain from a ’fat client’ and rely completely on a web front-end.
Another argument pointed out by Fowler:
The demand to move it to the client is for either responsiveness or dis-connected use.
Turning the focus to responsiveness, it is easy to say that a few seconds waiting forserver information or a button press shouldn’t matter much as long a productivityisn’t hurt. There are some types of Financial Information Systems, such as thosebuilt for what is known as ’high frequency trading’ systems, in witch latencies aremeasured in nanoseconds. That might be an extreme example as there is usuallyno point in having a graphical user interface with nanosecond latency requirements.
The security concerns, exemplified in the previous section by vulnerability toSQL injection, is in the case of a 3-Tier architecture more an implementation concernrather than a concern with the architectural model.
9
Chapter 3
Technical Challenges for FinancialInformation Systems
3.1 ScaleThe sheer size of the data that is handled by a financial information system dwarfmost traditional enterprises. As an example, let’s have a look at a system that isdesigned to analyse orders for stocks over time. To get a start one might want tohave only the most liquid stocks that are traded on the largest exchanges in theworld. This can be represented by the S&P 1200, which is a global version of thefamous S&P 500 [19].
The length and granularity of these time-series are of course subject to the typeof analysis to be done but 10 years worth of "real-time" data, put this limited set ofstocks at about 2TB of data. If one expands the universe to not only other stocks,but exchange traded derivatives such as options and futures, 1 200 easily grow by afactor of 100, 1 000 or more. For an explanation of exchange traded derivatives, seeappendix A.
To a certain degree it could be said that large financial institutions dealt with’Big Data’ before the expression was made popular.
3.2 ComplexityThus far we have only counted the prices, adding transaction data, static dataabout companies and instruments, corporate actions, valuation models, regulatoryframeworks and security concerns; to say that a financial information system iscomplex is an understatement.
11
CHAPTER 3. TECHNICAL CHALLENGES FOR FINANCIAL INFORMATIONSYSTEMS
3.3 Big Data’Big Data’ has become a popular buzz-word lately but is commonly defined as datasets that are too large to be handled by a single server and/or storage system. Asservers and storage systems become more powerful, what is considered ’Big Data’shifts.
3.4 Cloud’Cloud computing’ o�er enterprises a more e�cient way to scale up and down thecomputing and/or storage resources used for their information systems. However,many enterprises belonging to the financial sector are not able to use the servicesof the cloud providers due to regulatory restrictions and security concerns. Some ofthe benefits of the cloud technologies can still be had by the largest enterprises inthe financial sector as they can deploy private clouds.
3.5 SecurityEnterprises often have security concerns regarding their technologies, strategies,partnerships ans so on. What sets financial enterprises apart is that while ’normalenterprises’ might have secrets that are of interest to their competitors, everyoneare interested in the secrets of the enterprises of the financial sector as they concernpayments and money. On top of the ’digital bank robbery’ risk, financial institutionsalso handle very intimate information about their clients.
12
Chapter 4
Technical Insights from the largestwebsites
Google, Facebook and Amazon have faced technical challenges on a scale neverbefore addressed by enterprise information systems. A selection of technologiesthat have been contributed by these companies are presented together with thebenefits they bring in comparison to current enterprise standards.
4.1 Remote Procedure CallWhen building a system using multiple technologies, a need arises for a frameworkto handle remote procedure calls (RPC) and serialization between the domains.RPC is about calling a procedure outside of the current application scope, eitherin a di�erent process in the same environment or on a server. Earlier examplesare CORBA (Common Object Request Broker Architecture) and Java RMI (JavaRemote Method Invocation). In this section two of the new generation of theseframeworks are presented, namely Protocol bu�ers from Google and Thrift fromFaceBook. Thrift was open sourced and is now a top level project with Apache.
4.1.1 Apache ThriftApache Thrift uses an Interface Definition Language, IDL, to define the data types.The IDL is then compiled for the languages used. This enables the server side tobe written in Java, one client in a Microsoft .NET language and a second client iswritten in Objective-C to run on an iPhone.
This could be achieved using JSON (JavaScript Object Notation) or XML (Ex-tensible Markup Language) but in comparison to these text based formats, Thriftachieves the same result with smaller messages that are faster to parse.
13
CHAPTER 4. TECHNICAL INSIGHTS FROM THE LARGEST WEBSITES
Apache Thrift also provides a library of servers. The Apache Thrift IDL is usednot only to define data types, but to define services. Compiling a service defined inThrift generates a server stub where all that is left is to implement the logic of theservice [1].
4.1.2 Apache Thrift IDLThis is a short descriptions of the Apache Thrift Interface Definition Language. Fora more thorough documentation of the Apache Thrift IDL, refer to the documen-tation or Randy Abernethy’s book[1].
Data Types
The base types are somewhat restricted by the intended purpose of being able tosupport many programming languages and thus the common subset.
bool a boolean value (true or false)
byte an 8-bit signed integer
i16 a 16-bit signed integer
i32 a 32-bit signed integer
i64 a 64-bit signed integer
double a 64-bit IEEE 754 standard floating point number
string a text string encoded in UTF-8
Structs
Complex datatypes are composed of fields. Every field is defined with an integeridentifier, a Thrift type (base or struct), a name and an optional default value.
struct NameOfStruct {1: thriftType field1 = defaultValue2: thriftType field2
}
Containers
Apache Thrift provide strongly typed containers that are commonly available inprogramming languages.
map<T1,T2> a map from one type to another
list<T1> an ordered list of elements of the same type
set<T1> a set of unique elements of the same type
14
4.1. REMOTE PROCEDURE CALL
Services
Apache Thrift provide a complete Service Oriented Architecture. Stub servicesare generated from Apache Thrift IDL that are defined like a pure virtual abstractclasses in object oriented programming languages. The argument list of the methodsare numbered just like the fields in a struct.
namespace java namespaceName
service serviceName {returnValue methodName(1: arg1, ...)
}
4.1.3 Protocol bu�ersGoogle has another technology that is similar to Thrift and solves the same cross-domain serialisation and remote procedure calls more e�ciently than doing the samewith text based formats such as XML or JSON. Google has named their solutionto the problem Protocol bu�ers.
The reason Apache Thrift is more closely analysed in this thesis is due to thefact that Protocol bu�ers doesn’t generate ready to use servers.
15
CHAPTER 4. TECHNICAL INSIGHTS FROM THE LARGEST WEBSITES
4.2 DatabaseThere are many di�erent databases to choose from. In the last years NoSQL, NotOnly SQL, has challenged traditional database systems. This has been especiallytrue regarding web-applications and so called ’Big Data’ applications.
4.2.1 CAP theoremIn 2000, Dr. Eric Brewer gave a presentation called ’Towards Robust DistributedSystems’ at the nineteenth ACM Symposium on Principles of Distributed Com-puting (PODC 2000). In this presentation he introduced the CAP Theorem. TheC, A and P stand for Consistency, Availability and Partition tolerance respectivelyand the theorem states: ’You can have at most two of these properties for anyshared-data system’ [4].
C onsistency: All clients always have the same view of the data.
A vailability: Each client can always read and write.
P atition tolerance: The system works well despite physical network partitions.
This means that a system can be characterised as following:
CA Consistent, Available Systems.
CP Consistent, Partition-Tolerant Systems.
AP Available, Partition-Tolerant Systems.
16
4.2. DATABASE
4.2.2 RDBMSRelational DataBase Management System, RDBMS, are software that manages arelational database and a relational database is a database based on the relationalmodel, developed by E.F. Codd, a computer scientist at IBM Research Laboratoryin San Jose, California, in 1969 [6].
Not strictly a rule but it is usually assumed that an RDSMS provides a stan-dard compliant Structured Query Language, SQL, to define and manipulate data.The two parts of SQL are referred to as data definition language, DDL, and datamanipulation language, DML, respectively.
In the language of the CAP theorem, relational databases sacrifice the PartitionTolerance in order to ensure that the data is available and consistent, thus makingrelational databases ’CA’-type systems.
4.2.3 CassandraGoogle and Amazon have presented research papers than spurred a lot of develop-ment in the ’NoSQL’ space. The two most influential papers in this regard are:
BigTable: A Distributed Storage System for Structured Data presented byGoogle at the Seventh Symposium on Operating System Design and Imple-mentation, in November 2006 [5].
Dynamo: Amazon’s Highly Available Key-Value Store presented by Ama-zon at the 21st ACM Symposium on Operating Systems Principles, in October2007 [9].
Bigtable
From the Abstract of the paper that in 2006 presented Google Bigtable [5]:
Bigtable is a distributed storage system for managing structured datathat is designed to scale to a very large size: petabytes of data acrossthousands of commodity servers.
Google built Bigtable, which is also the name of their data store, as a ’CP’ system.It is not available for the public but is internal to Google. The ideas borrowed byCassandra from BigTable are the data model and the handling of data in memoryand on disk in an e�cient way.
17
CHAPTER 4. TECHNICAL INSIGHTS FROM THE LARGEST WEBSITES
Dynamo
From the Abstract of the paper that in 2007 presented Amazon Dynamo [9]:
Dynamo, a highly available key-value storage system that some of Ama-zon’s core services use to provide an ’always-on’ experience.
Amazon built Dynamo, which is also the name of their data store, as an ’AP’system. From Dynamo, Cassandra has borrowed the ideas of using a gossip protocolto achieve a data store without a single point of failure, there is no ’Master Node’in a Cassandra cluster [16].
Cassandra is particularly suitable for temporal data such as time series dataas the data can be read sequentially. This is one of the underlying reasons forthe speed of the system. A RDBMS’ performance is typically very dependent ofrandom IOPS, Input/Output Operations Per Second, as the data might be storedanywhere. The speedy access to temporal data is very important when performingeconometric calculations which is common in Financial Information Systems.
18
Part II
System Architecture
19
Chapter 5
System Overview
The three key architectural design approaches presented and evaluated in this thesisare:
Improving the Infrastructure by facilitating a serialization and RPC frame-work that supports many programming languages.
Extending the Three Tiers where we extend the classical 3-Tier architectureto accommodate for multiple databases.
Speeding up the Arithmetic by taking advantage of the increased computingcapabilities of GPGPU.
They are described in more detail in the following sections.
21
CHAPTER 5. SYSTEM OVERVIEW
5.1 Improving the Highways as well as the Access RoadsUsing a serialisation and remote procedure call framework such as Apache Thrift,gives two benefits. One being performance which is impacted both by the latencywins from serializing and de-serializing more e�ciently as well as the bandwidthgains from using much smaller message sizes. This is especially true in the enterpriseworld as the standard for interchanging messages is XML which tends to generatequite large messages.
The second benefit comes from choosing such a framework in a manner that itsupports a large number of platforms, thereby enabling each part of the system tobe built with a tool suitable to the task at hand.
22
5.2. EXTENDING THE THREE TIERS
5.2 Extending the Three Tiers
When taking advantage of the advances in database design that come from thetechnical insights of the largest websites in the world, in this case using the Cas-sandra database, the first step is to analyse the data that needs to be stored andrepresented in the Database Tier. If the Data Source still needs to cater for datathat might be relational in nature or an external reporting tool expects to connectto a classical RDBMS, it might be di�cult to completely replace the RDBMS. Theapproach taken here is not to replace it at all but to separate out the data thatneeds the horizontal scaling of a NoSQL such as Cassandra while still keeping aRDBMS for the rest of the data. This is illustrated below.
The disadvantage of this design is that the design of the Database Tier as well asthe Business Logic Tier gets more complex. The Data Model can no longer bemodelled with regular SQL DDL but also with something else, which in the caseof Cassandra is CQL (Cassandra Query Language), which is similar but not thesame as SQL. The Domain gets more complex as the task of keeping the databaseconsistent suddenly spans more than just one database. To avoid having the logicof keeping the databases consistent and in sync, a fourth tier is introduced betweenthe Business Logic Tier and the Database Tier.
23
CHAPTER 5. SYSTEM OVERVIEW
This fourth layer, called the Data Logic Tier, is responsible for which data belongto which database as well as keeping the data in sync when data relations spandatabases. It is the Domain from Brown that has been split in two in order toachieve a separation of concerns [2]. The two tiers of the Domain are now theBusiness Logic Tier and the Data Logic Tier.
24
5.3. SPEEDING UP THE ARITHMETIC
5.3 Speeding up the ArithmeticThe server side of the Portfolio Management System is built in Java. As long asthe performance of the system is IO-bound, the performance of Java does not con-stitute a significant bottle-neck. However, in some operations, such as Monte Carlosimulations, Finite Di�erence methods or more common mathematical operationson large matrices, the choice of Java as an implementation technology is a limitingfactor.
A valid argument is that even if the e�ort was undertaken to implement thelogic in a standard lower level language, such as C or C++ (one can argue whetherC++ is low or high level, but that discussion is left out), the performance gains aretypically such that the run time of an algorithm is cut in half [3] but in some casesthe di�erences can be more profound [12], nearly an order of magnitude. Using ahybrid library that makes use of Java-Native-Interface, JNI for short, behind thescenes brings easy to use, high-performance arithmetic to Java. As a referenceimplementation jblas is used. The description of jblas according to the website:
jblas is a fast linear algebra library for Java. jblas is based on BLASand LAPACK, the de-facto industry standard for matrix computations,and uses state-of-the-art implementations like ATLAS for all its compu-tational routines, making jblas very fast [14].
GPGPU-calculations on the other hand can o�er performance gains of an entireorder of magnitude, in ideal cases even two orders of magnitude. There are two mainframeworks used for GPGPU, OpenCL and CUDA. The currently most successfulGPGPU framework is arguably CUDA from nVidia, but OpenCL provides fallbackto CPU when there is no dedicated GPU available, which CUDA doesn’t. OpenCLhas also recently been expanded to also support FPGA computing, which promisesperformance of yet another order of magnitude. A compelling argument can stillbe made for CUDA due to the maturity of the libraries. As an example, CuBLASallow lots of functionality for GPU acceleration of numerical calculations withouthaving to implement the algorithms. The sample implementation presented in thisthesis makes use of CUDA to illustrate the possible performance gains [8].
25
Chapter 6
Components
A central part of building a modern system is the choice of components. To buildanything but a very rudimentary system from scratch would be a Herculean taskthat should only be undertaken by large development teams and only if there is agood reason to do so. The various libraries and components that are used in thesystem together with a motivation as to why they have been included follows.
6.1 Server
In the enterprise sector two technology stacks dominate, Java and .NET. Java havingthe benefit of running on a multitude of platforms such as MS Windows, OS Xas well as a plethora of di�erent Linux and UNIX’s and .NET being championedby Microsoft and running on the majority of all desktop systems in the corporatesector. There are many compelling arguments for using the tool-chain that Microsoftprovides to build solutions that run well on Windows. However, in doing so asa software provider, you also dictate to your customers that they must run MSWindows on their servers if they are to run the software you provide.
There are essentially three situations that arise from this:One, your customers have already standardised on a Microsoft technology stack
so they do not really consider this to be a drawback. However, they have madeit di�cult for themselves to re-evaluate their decision to standardise on Microsoftwhich might cost them in the future.
Two, they do not want to run MS Windows on their servers but they need thesoftware you provide. They reluctantly run MS Windows against their will andin doing so incur costs that are associated with your system, but doesn’t generateincome for you.
Three, the customer choose your competitor even though they prefer your prod-uct, due to the technology platform.
27
CHAPTER 6. COMPONENTS
6.2 ClientClient applications have diversified significantly since Apple started the smartphonerevolution in 2007 and the web-centricity that has been going on longer. End-users expect to be able to run the applications they need on the web, in theirsmartphones or on their desktops. There are clearly still some features more suitablefor the desktop than the phone and in other cases the opposite is true. However,in order to make the most of modern smartphones as well as desktop systems,be it WPF (Windows Presentation Foundation) powered MS Windows desktops,iPhones, Macs, Linux workstations or Android phones, there is no substitute fornative implementations.
6.3 Bridging the Domain GapThere are many contenders for the glue that binds the heterogeneous server-environmentto the world of the heterogeneous clients, some of which are:
• XML
• JSON
• Apache Thrift
• Protocol Bu�ers
In the last decade, XML evolved as a standard for serialization and made it sig-nificantly easier to interface heterogeneous systems. There were even some attemptsto use XML as the base for remote procedure call, RPC, but they were never widelyadopted.
In the last years JSON has emerged as the new standard for serialization. Inpart this is because it is easy to parse but it is also more compact than XML,reducing the message size. That said, JSON has not replaced XML but the two arecurrently both considered standard, coexisting as two separate tools in the toolbox.
In this thesis, Apache Thrift has been chosen for analysing the benefits of aserialisation and RPC framework.
6.4 DatabaseThe database chosen for the sample system is a hybrid data store using PostgreSQLas the RDBMS and Cassandra as the NoSQL data store. For the RDBMS side,the two major open source competitors are MySQL and PostgreSQL while on theNoSQL side there are many to choose from. PostgreSQL was chosen because itprovides inheritance in its DDL.
28
Part III
Data Model
29
Chapter 7
RDBMS
The main tables that make up the database representation are presented below.The database does contain more tables but for sake of brevity only a selection oftables are presented to illustrate the design and modelling approach.
The Class-model style inheritance arrows are presented in the diagram to illustratehow inheritance can be used in DDL. The strategy and custom_column tableshave no functionality of their own. In case inheritance had not been part of theDDL the two tables would have been duplicates.
31
CHAPTER 7. RDBMS
7.1 custom_behaviorThe purpose of the custom_behavior table is to be the parent of other tables. Thechild tables are to store scripts that extend the features of the system.
CREATE TABLE IF NOT EXISTS custom_behavior (id serial
,source text,version serial,PRIMARY KEY (id)
);
7.2 strategyThe strategy table contain custom strategy scripts to provide the features forautomated trading strategies.
CREATE TABLE IF NOT EXISTS strategy (
) INHERITS (custom_behavior);
7.3 custom_columnThe custom_column table contain scripts to provide features to customise the userinterface.
CREATE TABLE IF NOT EXISTS custom_column (
) INHERITS (custom_behavior);
32
7.3. CUSTOM_COLUMN
The symbol, daily_price and daily_option tables together with the timeseries’table’, described in the next section, are illustrates how the data model of theRDBMS and the NoSQL are meant to work together.
33
CHAPTER 7. RDBMS
7.4 symbolCREATE TABLE IF NOT EXISTS symbol (
id serial,ticker varchar(32),instrument serial NOT NULL,name varchar(255),sector varchar(255),currency char(3),created_date timestamp NOT NULL,last_updated_date timestamp NOT NULL,PRIMARY KEY (id)
);
7.5 daily_priceCREATE TABLE IF NOT EXISTS daily_price (
id serial,data_vendor_id int,timeseries varchar(255),PRIMARY KEY (id)
);
7.6 daily_optionCREATE TABLE IF NOT EXISTS daily_option (
call boolean NOT NULL,expiry date NOT NULL,strike decimal(19,4) NOT NULL,PRIMARY KEY (id)
) INHERITS (daily_price);
34
Chapter 8
NoSQL
The data that is separated out from the RDBMS and into the NoSQL are first andforemost time-series data.
8.1 timeseriesCREATE TABLE timeseries (
ticker_id text,event_date date,created_date date,last_updated_date date,open float,high float,low float,close float,adj_close float,volume varint
PRIMARY KEY (ticker_id,event_date));
35
Part IV
Connecting the Layers
37
Chapter 9
Sample IDL
A sample implementation of the structs and service used to illustrate how a servicebased solution can be built with Apache Thrift.
9.1 Basic building blocksnamespace java ch.pm.timeseries
struct TimeStamp {1: i16 year2: i16 month3: i16 day4: i16 hour5: i16 minute6: i16 second
}
struct Quote {1: string kind2: double value
}
struct QuoteValue {1: TimeStamp timeStamp2: Quote quote
}
39
CHAPTER 9. SAMPLE IDL
9.2 Servicesnamespace java ch.pm.timeseries
service svTimeSeries {list<QuoteValue> GetSeriesFor(1: string ticker
2: string kind3: TimeStamp from4: TimeStamp to)
}
40
Part V
Computational Library
41
Chapter 10
Matrix Methods
Many financial calculations depend on manipulations of large matrices that are notnecessarily sparse. A matrix representing all stocks in a certain market and thecovariances between them can easily measure 8 000 ◊ 8 000. To illustrate, a simpleimplementation in Java is presented, which is then compared to an optimised librarywhich in turn is compared to a solution making use of a modern GPU. Then therun-time of the algorithms are studied to see how they perform in practice.
10.1 Matrix MultiplicationA naive algorithm to multiply two matrices has the complexity of O(n3), whichfor matrices of 8 000 ◊ 8 000 equals about 512 000 000 000 operations. There arebetter matrix multiplication algorithms, such as Strassen’s algorithm at O(nlog27) ≥O(n2.807) and Coppersmith-Winograd at O(n2.376). But even with Coppersmith-Winograd, we still have to perform nearly 2 000 000 000 operations to multiply twomatrices of 8 000 ◊ 8 000. Even with the fast CPUs of modern computers, clearlyit would be beneficial if some of the computational load could be o�-loaded to theGPU.
10.1.1 HardwareThe tests were carried out on the following hardware
CPU Intel Core i7 4790K 4GHz, it has 4 processor cores and Intel Hyper-ThreadingTechnology lets it run 8 threads.
GPU Nvidia GTX 980 with 4GB GDDR5 video memory and 2 048 shader proces-sors.
43
CHAPTER 10. MATRIX METHODS
10.1.2 Naive algorithm Java ImplementationThe naive algorithm, sometimes referred to as the ’Schoolbook’-algorithm has thebenefit of being very easy to implement. The two matrices to be multiplied, A
n,m
and Bm,p
are represented as two-dimensional arrays and the elements of the resultingMatrix AB
n,p
are calculated as:
(AB)ij
=mÿ
k=1A
ik
Bkj (10.1)
Here is the implementation of the naïve algorithm:
public double[][] multiply(double[][] A, double[][] B) {double[][] result = new double[A.length][B[0].length];if(A[0].length == B.length) { //check dimensions
double value = 0.0;for(int n = 0; n < A.length; ++n) { //for each row in A
for(int p = 0; p < B[0].length; ++p) { //for each column in B
value = 0.0;for(int k = 0; k < B.length; ++k) {
value += ( A[n][k] * B[k][p]);}result[n][p] = value;
}}return result;
} else {...//wrong dimensions
}}
44
10.1. MATRIX MULTIPLICATION
All tests results are presented as run-time in milliseconds on the Y-axis and thematrix size on the X-axis. 500 in this case represents a matrix size of 500 ◊ 500.Using the ’Schoolbook’-algorithm to perform the matrix multiplication gives thefollowing results:
The test show the computation time, measured in milliseconds, to perform aBLAS sgemm generalised matrix computation of the form:–A ◊ B + — ◊ CWe can see that already with matrix sizes of 1 500 ◊ 1 500, a single such operationtakes 20s to perform.
45
CHAPTER 10. MATRIX METHODS
Here is another diagram to illustrate the performance or matrix sizes up to1 000 ◊ 1 000 that showed up as a flat section above:
Here we clearly see that the O(n3) nature of the algorithm ensures that calcu-lations that makes use of a few matrix multiplications quickly raise the runtime. Ifthe user is to experience a responsive system, here defined as taking at most 0.1s,matrix sizes of more than 500 ◊ 500 is not realistic.
46
10.1. MATRIX MULTIPLICATION
10.1.3 Optimised ImplementationPerforming the same matrix multiplication with jblas and comparing the results tothe naïve implementation [14]:
Clearly the results are vastly improved. A calculation involving matrices of size3 000 ◊ 3 000 are performed in less than 14.3s compared to about 176s for the naïveimplementation. That is more than a 12-fold performance increase.
47
CHAPTER 10. MATRIX METHODS
A more detailed look at the matrix sizes that are performed in under one secondgives:
Even with the much better performing jblas, the computational complexity ofmultiplying matrices still limits the calculations to matrices of about 600 ◊ 600.
48
10.1. MATRIX MULTIPLICATION
10.1.4 GPGPU ImplementationThis section turns to the GPU in an e�ort to improve on the results with the aimof increasing the sizes of matrices that are realistically used in computation. Tobridge the domain gap between Java and CUDA, the Java bindings for CUDA fromjcuda.org were used [15]. The results were the following:
49
CHAPTER 10. MATRIX METHODS
In order to interpret the numbers for the cuBLAS, the comparison with the jblasis taken away and the range of matrix sizes is increased:
Performing the calculations on the GPU now allow for matrix sizes of up to4 500 ◊ 4 500 given the criteria of 100ms.
50
10.1. MATRIX MULTIPLICATION
10.1.5 Results and AnalysisThere are many ways to improve on the naïve implementation. The two mostobvious ones are making use of a smarter algorithm, such as Strassen’s algorithm,and/or parallelising the calculations. A big win in this context is that making use ofbetter performing algorithms in the case of matrix multiplication involves breakingthe matrix down into sub-matrices, so some degree of parallelism comes almost forfree.
However, if one designs an enterprise information system, there are enough partsto worry about without having to optimise computation. This is especially truewhen there are people who have specialised in optimising computational librarieswhich are available. The tested one here, jblas, makes use of the BLAS and LA-PACK routines developed by the Fortran community where computational perfor-mance is extremely important [14]. This is clearly shown by the 12-times fasterexecution.
The ’Big-O’ notation used in complexity analysis also hide lower order termsas well as constants and in real-world scenarios that might have a large impact onthe performance. A smarter algorithm such as Strassen’s [21] has a complexity ofO(n2.8). Therefore, I now turn to analysing the largest matrices tested, 3 000◊3 000,more numerically. In the naïve case we then have 3 0003 ≥ 2.7 ◊ 1010 operations.Strasse however, does not get the full benefit of the lower order of 2.8 as in orderto use Strassen, the matrix sizes have to be a power of 2. Thus the number tocompare is then 4 0962.8 ≥ 1.3 ◊ 1010 operations. The di�erence is then more afactor of 2 than 5 which 3 0002.8 ≥ 5.4 ◊ 109 operations would suggest if lookingat the non-factor adjusted Strassen. In fairness it should be pointed out that largeinput data such as 3 000 might show Strassen in a bad light. A really bad inputnumber might be matrix sizes of 4 097 ◊ 4 097 as this would result in 6.9 ◊ 1010
operations for the naïve approach and 8 1922.8 ≥ 9.1 ◊ 1010 operations for Strassen,ergo Strassen might in some cases perform worse than a naïve algorithm. It shouldbe pointed out that such overuse of padding is a bad implementation of Strassen,subdivision in combination with Strassen would give much better results [21].
The tests clearly show that GPGPU can give some very impressive performance.At the reference size of 3 000 ◊ 3 000, cuBLAS took only 41ms while jblas took14 294ms. That is nearly 350 times faster than the already highly optimised jblas.In the case of matrix multiplication GPGPU really shines and has the potential togive huge performance wins.
51
Chapter 11
Approximation Algorithms
As there are many computations in finance that lack a closed form solution, iter-ative techniques for root finding and computational schemes such as Monte Carlosimulations and finite di�erence methods are heavily used. Thus, when available,well performing approximation algorithms are well received.
11.1 Implied VolatilityImplied volatility, that is when the reversing the Black-Scholes equation is a usefulway to calculate the volatility. An interface that defines what method to call leavesthe possibility to extend the system with more implementations of either iterativesolvers or other approximation algorithms.
public interface ImpliedVolatility {static double ofCall(double C, double S, double X, double T, double r) {
return Double.NaN;}
}
Steven Li at the School of Economics and Finance at the Queensland Universityof Technology has provided a very well performing approximation algorithm as itsaverage error is 0.021497 less than ’true’ values of volatility [17] while avoidingiterative solutions. If the error is too great, the approximation can still be useful asa starting point for an iterative algorithm.
Li’s algorithm:
fl = |÷ ≠ 1|(C/S)2 = |K ≠ S|S
C2 (11.1)
‡ ¥
Y____]
____[
2Ô
2ÔT
z̃ ≠ 1ÔT
Ú8z̃2 ≠ 6–̃Ô
2z̃if fl 6 1.4
–̃+Ú
–̃2≠4(÷≠1)21+÷
2Ô
Tif fl > 1.4
(11.2)
53
CHAPTER 11. APPROXIMATION ALGORITHMS
Li’s algorithm has been implemented as follows:
public class StevenLi extends ImpliedVolatility{static final double SQRT_TWO = Math.sqrt(2);static final double SQRT_TWO_PI = Math.sqrt(2 * Math.PI);
public static double atmCall(double C, double S, double T, double r) {double alpha = SQRT_TWO_PI * C / S;double z = Math.cos(Math.acos(3 * alpha / Math.sqrt(32) ) / 3);double oneOverSqrtT = 1 / Math.sqrt(T);return oneOverSqrtT *
( 2 * SQRT_TWO * z - Math.sqrt(8 * z * z - 6 * alpha / SQRT_TWO / z));}
public static double dOITMcall(double C, double S, double X, double T, double r) {double K = X * Math.exp(-r * T);double eta = K / S;double etam1 = eta - 1;double alpha = SQRT_TWO_PI / (1 + eta) * (2 * C / S + etam1);return (alpha + Math.sqrt(alpha * alpha - 4 * etam1 * etam1 / (eta + 1) ) )
* 0.5 / Math.sqrt(T);}
public static double nATMcall(double C, double S, double X, double T, double r) {double K = X * Math.exp(-r * T);double eta = K / S;double etam1 = eta - 1;double oneOverSqrtT = 1 / Math.sqrt(T);double alpha = SQRT_TWO_PI / (1 + eta) * (2 * C / S + etam1);double z = Math.cos(Math.acos(3 * alpha / Math.sqrt(32)) / 3);return oneOverSqrtT * (2 * SQRT_TWO * z -
Math.sqrt(8 * z * z - 6 * alpha / SQRT_TWO / z));}
public static double call(double C, double S, double X, double T, double r) {double K = S * Math.exp(-r * T);double rho = Math.abs(K - S) * S / C / C;if(rho > 1.4)
return dOITMcall(C, S, X, T, r);else
return nATMcall(C, S, X, T, r);}
}
54
Part VI
Empirical Findings & Analysis
55
Chapter 12
RPC and serialisation
Apache Thrift has been analysed by studying the documentation and reading Aber-nethy’s book [1]. Sample structs and a service to provide a calling client programwith time series data has been rudimentarily implemented and presented in part IVof this thesis.
12.1 BenefitsApache Thrift brings high performance serialisation that can be used across plat-forms. The major benefits of deploying Apache Thrift as an RPC and serialisationframework are:
small messages small messages take up less bandwidth on the network, thus allowfor more messages per given time unit.
fast serialisation/deserialisation fast parsing and serialisation of messages givesa lower overhead when sending/receiving messages, thus more time can bespent on the business logic of the system as oppose to the interface layer.
generated services Light weight service stubs can be generated directly from theInterface Definition Language of Apache Thrift which reduce the e�ort todevelop a server based on Service Oriented Architecture.
That all objects have to be defined in IDL can be a benefit in situations where thesystem is built by not just a few but several programming languages. It provides acommon ground and a sort of ’Lingua Franca’ for a diverse development team.
57
CHAPTER 12. RPC AND SERIALISATION
12.2 DrawbacksAll objects that are to be transferred over the Apache Thrift serialisation layerhas to be defined in the Interface Definition Language, IDL. This poses additionalchallenges, both in regard to developer expertise and integration with other systems.
The developers of the information systems can no longer be pure Java-developersor .NET-developers. They need to at least have a rudimentary knowledge of howthe IDL works, especially as the classes generated by the IDL needs to be the ’superclasses’ of the objects the programmers work with.
A significant drawback with being forced to use IDL is when closed source thirdparty libraries or components are used, especially with single inheritance languagessuch as Java or C#. In such situations, not being able to control the inheritancestructure of the objects brings a lot of wrapping at best or render the combinationof the library or component and Apache Thrift not feasible.
When using XML based messages to interconnect the various systems in anenterprise environment, the individual messages are in a human readable form. Thebinary format of Apache Thrift or other serialisation frameworks that relies on thebinary format for e�cient parsing and message size loose the human readability.This makes trouble shooting more di�cult. Moreover, as there are likely othersystems in place and those systems are likely interfaced with XML. It is possible tomake Apache Thrift use XML instead of it’s binary format but then most benefitsare gone.
12.3 ConclusionsApache Thrift can be a good solution for an enterprise that is flexible regardingthe other systems present or if there are few other systems. If there are lots ofother systems that need to be integrated, Apache Thrift can still be used but mostperformance benefits are then gone. However, a good argument can be made forusing the binary format of Apache Thrift for the use cases where small and fastmessages are needed and XML where integration is needed.
Developer expertise is the other consideration. If the enterprise has a strongteam of developers, using modern technologies such as Apache Thrift can be usedas a tool to avoid attrition, as good developers tend to want to work with goodtools. If the enterprise on the other hand has outsourced it’s internal developmentsor has a policy of not developing systems but rather buy them ready made from avendor, Apache Thrift might be a bad choice.
58
Chapter 13
Separation of Database-Tier
For the analysis of the Database-Tier a study of Enterprise Application Architecturewas carried out by reading Fowler [18]. Brewer’s presentation and the BigTable,Dynamo and Cassandra papers were studied together with Codd’s paper to get atheoretical base from which to contrast the strengths and weaknesses of relationaldatabases and NoSQL respectively [4][5][9][16].
13.1 BenefitsThe benefits of separating the Database-Tier is that it is possible to combine a ’CA’and an ’AP’ system. The CAP theorem still holds so it is not possible to get a full’CAP’ system but it allows the architect of the system to choose, on a data by datacase, if he or she needs a ’CA’, ’CP’ or ’AP’ data store which adds a lot of flexibility.The two letter choice can be made case by case base and is no longer system wide.
13.2 DrawbacksFragmentation of the Database in, not only separate databases, but di�erent databasetypes increases the administration overhead. This overhead is two-fold, both in theamount of work performed by the DataBase Administrators, DBA, and the exper-tise required of them. Another drawback is that the implementation of the BusinessLogic-Tier gets more complex as it has to coordinate more than one database andto some degree keep them in sync.
59
CHAPTER 13. SEPARATION OF DATABASE-TIER
13.3 ConclusionsThe strengths and weaknesses of relational databases and the various NoSQL databasesleaves the architect with a di�cult choice.
By splitting up the Database-Tier, the selection of which binomial letter combi-nation to choose from in the ’CAP’ alphabet becomes contextual. It can be done inthe implementation phase rather than in the design-phase when more informationis at hand.
However, the added complexity to the Business Logic-Tier is hard to quantifyand might be source of a lot of future problems.
60
Chapter 14
Heterogeneous computing
14.1 BenefitsThe performance gains from letting the GPU o�oad the CPU are hard to deny.Whenever lots of similar calculations can be performed independently or the cal-culations are matrix or vector based, there is a lot to be gained performance wise.However, if double precision calculation is important, the more computer game ori-ented cards are not a good option. It should be noted that if GPUs are used inan enterprise environment, the GPU manufacturers have cards that handle doubleprecision much better.
14.2 DrawbacksThe drawbacks of heterogeneous computing are developer skill set and virtualisa-tion. The most common platforms for building Enterprise Information Systems, ofwhich Financial Information Systems are a subset, are Java and C#/.NET. Workingwith GPGPU frameworks such as OpenCL or CUDA brings complexity that mightnot fit the expertise of developers working in the area of Enterprise InformationSystems.
The virtualisation trend continues as it allow for more cost e�cient usage ofinformation technology and plays well with the continuous pressure to lower the ITbudget [13]. However, GPGPU computation relies on having access to the hardwareas the computations are performed by specialised chips. This is usually not feasiblein a virtualised server environment.
61
CHAPTER 14. HETEROGENEOUS COMPUTING
14.3 ConclusionsIf the drawbacks regarding developer expertise and virtualisation can be managed,heterogeneous computing promise very large performance gains. Especially in thearea of Financial Information Systems as the calculations are matrix based or caneasily be parallelised, for example when the same computation is performed on manydi�erent data points. The risk numbers, which are generally based on econometricdata, are also suitable for GPGPU calculations.
62
Chapter 15
Final Reflections of the Study
The performance gains and the increased scalability achieved when combining het-erogeneous computing with new approaches to database modelling clearly show thatEnterprise Information Systems could gain a lot from the non traditional approachof the large websites. The computational performance increases of CPUs have lev-elled out and led the CPU manufacturers towards multi-core technology instead ofhigher frequencies. This makes the heterogenous computing and the frameworks tomake use of them key to the computational requirements of the future.
15.1 Future ResearchFuture research can be more in-depth analysis of each technology presented in thisthesis, as suggested in the subsections below. Other areas to investigate would bealternative platforms, such as go-lang or Scala to see if the newer programmingparadigms can bring e�ciencies to the system development as a complete reimple-mentation of an enterprise system takes a lot of resources.
15.1.1 RPC and serialisationFurther study to compare the various serialisation- and RCP-frameworks with eachother would help an information system architect decide the most suitable for thespecific project. Apache Thrift, investigated here might not be the most suitablechoice.
15.1.2 Separation of Database-TierFurthermore, there are many non relational data stores available and further studyon how they compare against each other. What are the strengths and weaknesses ofthe alternatives? Especially from the perspective of combining them with a RMDBSas in the 4-Tier architecture presented in this thesis.
An empirical study of the promises of the 4-Tier solution presented in this thesiswould be interesting.
63
CHAPTER 15. FINAL REFLECTIONS OF THE STUDY
15.1.3 Heterogeneous computingRegarding heterogeneous computing, OpenCL might be a better choice as it iscompatible with many more GPUs and even Digital Signal Processors (DSP) andField-programmable gate array (FPGA).
64
Bibliography
[1] Randy Abernethy. The Programmer’s Guide to Apache Thrift. MEAP12. Man-ning Publications, 2015. isbn: 9781617291814.
[2] Brown et al. Enterprise Java Programming with IBM Webspere. Addison-Wesley, 2001.
[3] alioth.debian.org. The Computer Language Benchmarks Game. 2015. url:http://web.archive.org/web/20150406093807/http://benchmarksgame.alioth.debian.org/u64q/java.html (visited on 04/06/2015).
[4] Eric A. Brewer. “Towards Robust Distributed Systems (Abstract)”. In: Pro-ceedings of the Nineteenth Annual ACM Symposium on Principles of Dis-tributed Computing. PODC ’00. Portland, Oregon, USA: ACM, 2000, pp. 7–.isbn: 1-58113-183-6. doi: 10.1145/343477.343502. url: http://doi.acm.org/10.1145/343477.343502.
[5] Fay Chang et al. “Bigtable: A distributed storage system for structured data”.In: IN PROCEEDINGS OF THE 7TH CONFERENCE ON USENIX SYM-POSIUM ON OPERATING SYSTEMS DESIGN AND IMPLEMENTATION- VOLUME 7. 2006, pp. 205–218.
[6] E. F. Codd. “A Relational Model of Data for Large Shared Data Banks”.In: Commun. ACM 13.6 (June 1970), pp. 377–387. issn: 0001-0782. doi: 10.1145/362384.362685. url: http://doi.acm.org/10.1145/362384.362685.
[7] “Common Application Security Vulnerabilities”. In: (2008).[8] Raphael Couturier. Designing Scientific Applications on GPUs. Chapman &
Hall/CRC, 2013. isbn: 1466571624, 9781466571624.[9] Giuseppe DeCandia et al. “Dynamo: amazon’s highly available key-value store”.
In: IN PROC. SOSP. 2007, pp. 205–220.[10] Eben Hewitt. Cassandra: The Definitive Guide. 1st. O’Reilly Media, Inc.,
2010. isbn: 1449390412, 9781449390419.[11] J. C. Hull. Options, Futures, and Other Derivatives. sixth. Upper Saddle
River, N.J.: Prentice-Hall, 2006.[12] Robert Hundt. “Loop Recognition in C++/Java/Go/Scala”. In: Proceedings
of Scala Days 2011. 2011. url: https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf.
65
BIBLIOGRAPHY
[13] “Implementing Server Virtualization At Southwestern Illinois College (CaseStudy)”. In: (2010).
[14] jblas.org. jblas.org. 2015. url: https://web.archive.org/web/20150425135252/http://www.jblas.org/ (visited on 04/25/2015).
[15] jcuda.org. jcuda.org. 2015. url: https://web.archive.org/web/20150516024114/http://www.jcuda.org/ (visited on 05/16/2015).
[16] Avinash Lakshman and Prashant Malik. “Cassandra: A Decentralized Struc-tured Storage System”. In: SIGOPS Oper. Syst. Rev. 44.2 (Apr. 2010), pp. 35–40. issn: 0163-5980. doi: 10.1145/1773912.1773922. url: http://doi.acm.org/10.1145/1773912.1773922.
[17] Steven Li. “A New Formula for Computing Implied Volatility”. In: AppliedMathematics and Computation 170 (Nov. 2005), pp. 611–625.
[18] Fowler M. Patterns of Enterprice Application Architecture. Addison-WesleyProfessional, 2002.
[19] Standard & Poor. S&P Global 1200. 2015. url: http://web.archive.org/web/20150529000728/https://en.wikipedia.org/wiki/S%26P_Global_1200 (visited on 05/29/2015).
[20] Ronald N. Kahn Richard C. Grinold. Active Portfolio Management: A Quanti-tative Approach for Producing Superior Returns and Controlling Risk. McGraw-Hill Education, 1999.
[21] Volker Strassen. Strassen algorithm. 2015. url: http://web.archive.org/web / 20150602175450 / https : / / en . wikipedia . org / wiki / Strassen _algorithm (visited on 06/02/2015).
[22] Edward J. Szewczak. Human Factors in Information Systems. IGI Publishing,2002. isbn: 1931777101, 9781931777100.
66
Appendix A
Financial Instruments
To ensure that the financial theory part is complete, a non-exhaustive list of themost commonly traded financial instruments follow [11]:
A.1 CashThe most basic financial asset is cash or cash equivalent instruments. Cash is notjust notes and coins in your wallet. The "minted" part of the total amount of cashis actually very small, the vast majority of all cash are just entries in the computersystems of the various central banks. Often other financial instruments that aredeemed cash equivalent or nearly so, are also categorised as cash, an example ofsuch are CDs, certificates of deposit.
A.2 StocksLegally as well as in theory, stocks or shares are ownership parts of companies. His-torically they were stock certificates stating the ownership of these limited liabilitylegal entities, sometimes referred to as corporations. If you were in possession ofstock certificates, you had stock in the company. These companies usually come intwo forms, unlisted and listed. If a company is listed, the most common variety fora certain size of corporation, it means that its shares are listed for trade on a stockexchange. Combined, these stock exchanges make up the stock market where listedstocks are traded. In practice, especially regarding the larger companies when themarket cap is measured in billions, a stock is not so much a small ownership partbut a right to future dividend payments.
A.3 BondsA bond is actually an IOU. It is nothing more than a paper that states that theissuer of the bond owe the holder of the bond an amount of money. The maintypes of bonds are fixed rate bonds, which pay a fixed rate dividend, and floating
67
APPENDIX A. FINANCIAL INSTRUMENTS
rate bonds, also known as floaters and pay a floating rate dividend. Floating ratedividends are usually bound to a benchmark interest rate index such as LIBOR,The London Inter-Bank O�ered Rate. Bonds are further classified by their emitters,sovereign or corporate, and their credit rating.
A.4 DerivativesFinancial derivatives normally have no intrinsic value, but derive their value froman underlying asset. The most common types of derivative contracts are forwards,options and swaps.
A.4.1 FuturesForward contract are the name given to agreements that are to take place at alater time where a party agrees to buy or sell a specified amount of an asset ata predetermined price at a designated future date. An example would be a wineproducer that in April makes an agreement to buy grapes in August. Forwardcontracts were mostly used in various commodity markets to ensure delivery ofraw materials without having to worry about price fluctuations. A lot of forwardcontracts have been standardised and are now traded on regulated exchanges, theseare called Futures. Forward agreements still exist but are somewhat out of scopefor this thesis.
A.4.2 OptionsOptions, like Forwards and Futures are contracts describing a deal that is to happenin the future. However, the holder of the option has the optionality to make thedeal or step out of it. There are two main types of options, call options and putoptions. The call option gives the option holder the right to buy the underlyingasset at some point whereas the put option gives the option holder the right to sellthe asset. Options are also categorised according their exercise style. The mainstyles are American and European where European means that the option can beexercised on the day of expiry whereas American means that the option can beexercised at any time up to and including the day of expiry.
Over time a lot of di�erent features have been thought up to give the optionsdi�erent qualities, so called exotic options. The only options that will be coveredhere are the commonly exchange traded kind. Those happen to be regular put-and call-options with American exercise and in most cases a standardised contractsize of 100 units of the underlying asset. American exercise means that the optionholder can ’exercise’ his option at any point up to the expiry of the option. In theliterature, options are usually of the European variety which means that the exercisecan only happen on the day of expiry. This makes the mathematical analysis easierbut since the exchange traded options are all American, this often leads to a gapbetween theory and practice.
68
A.5. FX
A.4.3 SwapsSwaps are financial contracts in which two parties agree two swap a financial resultwith one another. One of the most straight forward examples are interest rate swapswhere one swap a set of fixed cashflows for a set of floating cashflows, in essenceturning a fixed interest paying position into a floating rate paying one, or the otherway around. Some swaps are exchange traded but the vast majority are OTC.
A.5 FXForeign Exchange is the trading of currencies. These range from so called spot tradeswhere one straight up exchange one currency for another to advanced derivativesthereof. The currency market, with a daily turnover of 4 trillion US dollars is byfar the largest market in the world.
69
Appendix B
Portfolio Theory
B.1 Structure of a PortfolioA portfolio is an allocation of capital to a selection of assets. Conceptually thatmeans that the portfolio is made up by a vector of asset allocations where each assetallocation is a tuple of an asset identifier and a ratio (or weight) of capital allocatedto the asset.
(a, w) (B.1)Each asset is present only once in the portfolio and the weights sum up to 1. Thisis sometimes known as the budget equation.
nÿ
i
wi
= 1, ai
”= aj
(B.2)
or in vector notationwT 1
n
= 1, ai
”= aj
(B.3)
B.2 Modern Portfolio Theory, MPTThe Modern Portfolio Theory, MPT for short, was pioneered by Harry Markowitzin 1952. That makes it 65 years old as this thesis is being written and one couldthink that it should get ready to retire but alas, it is till referred to as ModernPortfolio Theory. Markowitz’s assumption was that all asset returns are normallydistributed and that the assets are fully characterised by their expected return,standard deviation of returns and their pair-wise correlation. Furthermore there isa risk free asset which by definition has zero correlation with all other assets andhas a return referred to as the risk free rate. It could be argued that the existence ofa risk free asset has been challenged in the last years but that discussion is outsidethe scope of this thesis.
The expected return of an asset is usually denoted µ, the standard deviationof returns is denoted ‡ and the correlation is denoted fl. There are additionalassumptions made. However, it should be noted that some of those are unrealistic:
71
APPENDIX B. PORTFOLIO THEORY
• investors can borrow and deposit at the risk free rate
• markets are frictionless, that is there are no commissions to pay, no taxes andno margin requirements.
Disregarding the somewhat unrealistic assumptions. We have that for a portfoliofi the expected return is:
µfi
= r + wT (µ ≠ 1n
r) (B.4)where r is the risk-free interest and the risk of the same portfolio fi is:
‡fi
= r +Ô
wT �w (B.5)
where µ is the column vector of expected assets returns and � is the covariancematrix.
B.3 MPT as a Mean-Variance optimisation problemThe optimisation problem can be stated in two di�erent ways. Either one tries tominimise the risk given a target return rate or maximise the return given a certainrisk budget. Risk is measured in variance, or ‡2, and not standard deviations andusing risk terminology, variance is often called volatility.
B.3.1 Unconstrained OptimisationIn the unconstrained case of minimising risk:
minw1,...,wn
‡2P
(w1, ..., wn
) (B.6)
The gradient (vector of derivatives) must be zero and the Hessian has to be positivedefinite. Together these two conditions are necessary and su�cient to find thesolution that satisfies the equation.
B.3.2 Optimisation with equality constraintsIn the case with equality constraints we have
minw1,...,wn
‡2P
(w1, ..., wn
)
subject to E[RP
] = m(B.7)
B.3.3 Optimisation with equality and budget constraintsIn the case with equality as well as budget constraints we have
minw1,...,wn
‡2P
(w1, ..., wn
)
subject to E[RP
] = m
wT 1n
= 1
(B.8)
72
B.4. THE OPPORTUNITY SET
B.4 The Opportunity setAll allocations of two assets, plotted in a Risk-Return diagram give rise to a hyper-bola. This hyperbola is called the opportunity set.
B.5 The E�cient frontierFrom an investors point of view, only the upper part of the hyperbola is of interestas each point represents the maximum possible return for each amount of risk taken.The upper part or the hyperbola is called the e�cient frontier.
B.6 The tangency portfolioIf the risk free asset is introduced to the asset universe, it ends up as a point onthe Return-axis. Every point on the opportunity set can be connected to the riskfree asset. This means that the e�cient frontier is no longer the upper part of the
73
APPENDIX B. PORTFOLIO THEORY
hyperbola but the straight line touching the hyperbola in a single point. The singlepoint where the line of the new e�cient frontier touches the hyperbola is called thetangency portfolio.
74
www.kth.se
