Exact Contents of Our Online KDB+ Training Course
We often get asked what is in our online training course.
We do describe this on the course page and in a PDF to be be totally thorough here’s a screenshot of our full listing:
We often get asked what is in our online training course.
We do describe this on the course page and in a PDF to be be totally thorough here’s a screenshot of our full listing:
The biggest shakeup in the KDB world was Arthur Whitney, the founder of KX and creator of KDB selling his stake in KX and moving on to creating a new version of the K language called Shakti. “Shakti merges database, language, connectivity and stream processing into one powerful platform “. So far it appears to overlap heavily with kdb functionality, adding further cryptographic features, while not yet supporting on-disk storage.
FD/KX Products:
First Derivatives Shares have fell back to a price last seen in February 2017:
One cause of the fall has been a damning article by ShadowFall. Their main arguments are:
The 47 page report goes into a lot of detail, to give an idea here’s one of the charts:
He shows numerous statistics for FD compared to it’s peers, operating margin, gross margin, revenue, headcount. It’s worth a read if you have an interest in kdb/KX/FD.
Related Links: Shadowfall tweet, Independent.ie.
qStudio 1.45 Released, we have:
Some example charts:
Our standard time-series graph interpolates between points. When the data you are displaying is price points, it’s not really valid to always interpolate. If the price was 0.40 at 2pm then 0.46 at 3pm, that does not mean it could be interpreted as 0.43 at 2.30pm. Amazingly till now, sqlDashboards had no sensible way to show taht data. Now we do:
For comparison here is the same data as a time-series graph:
The step-plot is usable for time-series and numerical XY data series. The format is detailed on the usual chart format pages.
qStudio has added support for stacked bar charts:
The chart format for this is: The first string columns are used as category labels. Whatever numeric columns appear next are a separate series in the chart. Each row in the data becomes one stacked bar. The table for the data shown above for example is:
dt | LSE | BTS | NAS | ASE | NYQ | SES | TSE | HKG |
---|---|---|---|---|---|---|---|---|
2018-03-30 | 1047 | 2120 | 592 | 25 | 3660 | 303 | 225 | 383 |
2018-03-29 | 1148 | 2118 | 528 | 10 | 3656 | 541 | 215 | 303 |
2018-03-28 | 1201 | 2085 | 555 | 17 | 3644 | 302 | 290 | 339 |
2018-03-27 | 1206 | 2182 | 535 | 21 | 3604 | 235 | 299 | 319 |
2018-03-26 | 1239 | 2041 | 515 | 16 | 3549 | 251 | 234 | 363 |
2018-03-25 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
2018-03-24 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
2018-03-23 | 1379 | 2115 | 595 | 29 | 3430 | 138 | 251 | 348 |
2018-03-22 | 1431 | 2179 | 517 | 25 | 3399 | 531 | 222 | 320 |
2018-03-21 | 1530 | 2032 | 558 | 29 | 3282 | 438 | 296 | 359 |
2018-03-20 | 1531 | 2134 | 520 | 23 | 3256 | 515 | 265 | 322 |
You may need to “kdb pivot” your original data to get it in the correct shape.
“The Financial Information eXchange (FIX) protocol is an electronic communications protocol initiated in 1992 for international real-time exchange of information related to the securities transactions and markets.”. You can see an example of a FIX message being parsed here.
What we care about is that an order goes through a lifecycle. From newly created to filled or removed. Anything that involves state-transitions or a lifecycle can be visualized as a graph. A graph depicts transitions from one state to another. Often SQL tables record every transition of that state. This can then be summarised into a count of the last state, giving something like the following:
From | To | label | cnt |
---|---|---|---|
PendingCancel | Calculated | Rejected | 50 |
PendingReplace | Calculated | Rejected | 10 |
PendingReplace | Calculated | Replaced | 40 |
Calculated | PendingReplace | PendingReplace | 50 |
Calculated | Filled | Trade | 9400 |
Calculated | Calculated | Trade | 5239 |
PendingCancel | Removed | Cancelled | 150 |
Calculated | PendingCancel | PendingCancel | 200 |
New | Calculated | Calculated | 9660 |
New | Removed | Rejected | 140 |
Created | Removed | Rejected | 300 |
Created | New | New | 9800 |
qStudio now automatically converts this result table to DOT format and if you have graphviz“>graphviz installed and on the PATH, will generate the following:
Note I did tweak the table a little to add styling like so:
update style:(`Filled`Removed!("color=green";"color=red")) To,label:(label,'" ",/:cnt) from currentFixStatus
The format is detailed again in our qStudio Chart Data Format page.
This is another even simpler example:
The structure of banks and finance firms are constantly changing as they evolve towards the structure best for todays environment. The trend over recent years has been for less traders and more engineers as expanded in this (article. (thanks Zak). In these posts I’ll describe the current state and where I think fintech, in particular market data capture and kdb are going.
(Newer firms that are) “Tech savvy, led by quants and data engineers rather than the expensive traders sitting on the scrap heap of most banks’ inferior tech, the new entrants now just need people with the skills to win over large numbers of customers.”
Think of banks as a stack of services sitting ontop of each other [1]:
Communication within the system is mostly between the layers. Top layers rely on all the services of the layers beneath. e.g. A trader relies on a trading application, that relies on an internal web framework, that relies on a database, that relies on hardware. If we get more traders that need additional software changes, that could transmit down the stack into a request for more hardware. Communication outside the layer model, e.g. Sales asking for additional SAN storage is exceedingly rare.
Within the stack, I’ve highlighted in bold where market data capture sits. I believe most the points I’ll make can be applied wider to other areas within the stack but I’ll stick to examples within the area I know. Sometimes the “market data” team will include responsibility for Feeds, sometimes there will be a core team responsible for the database software they use, sometimes there won’t, but it captures the general structure.
Note each box on the diagram I refer to as a silo. A silo may be one team, multiple teams or a part of a team but generally it’s a group responsible for one area, looking after it’s own goals.
There are a number of possible solutions to the issues above available today, unfortunately I will have to expand on that in a future post. I am very interested in hearing others views.
Do you believe the stack and issues highlighted are an accurate representation? Solutions you see coming up? Either comment below or drop me an email.
I will hopefully post [part 2] shortly, if you want notified when that happens, sign up to our mailing list.
Notable events this year or possibly the previous year due to incoherent memory issues: