Posts

Benjamin Aunkofer

CAP Theorem

/0 Comments/in , , , , /by

Understanding databases for storing, updating and analyzing data requires the understanding of the CAP Theorem. This is the second article of the article series Data Warehousing Basics.

Understanding NoSQL Databases by the CAP Theorem

CAP theorem – or Brewer’s theorem – was introduced by the computer scientist Eric Brewer at Symposium on Principles of Distributed computing in 2000. The CAP stands for Consistency, Availability and Partition tolerance.

  • Consistency: Every read receives the most recent writes or an error. Once a client writes a value to any server and gets a response, it is expected to get afresh and valid value back from any server or node of the database cluster it reads from.
    Be aware that the definition of consistency for CAP means something different than to ACID (relational consistency).
  • Availability: The database is not allowed to be unavailable because it is busy with requests. Every request received by a non-failing node in the system must result in a response. Whether you want to read or write you will get some response back. If the server has not crashed, it is not allowed to ignore the client’s requests.
  • Partition tolerance: Databases which store big data will use a cluster of nodes that distribute the connections evenly over the whole cluster. If this system has partition tolerance, it will continue to operate despite a number of messages being delayed or even lost by the network between the cluster nodes.

CAP theorem applies the logic that  for a distributed system it is only possible to simultaneously provide  two out of the above three guarantees. Eric Brewer, the father of the CAP theorem, proved that we are limited to two of three characteristics, “by explicitly handling partitions, designers can optimize consistency and availability, thereby achieving some trade-off of all three.” (Brewer, E., 2012).

CAP Theorem Triangle

To recap, with the CAP theorem in relation to Big Data distributed solutions (such as NoSQL databases), it is important to reiterate the fact, that in such distributed systems it is not possible to guarantee all three characteristics (Availability, Consistency, and Partition Tolerance) at the same time.

Database systems designed to fulfill traditional ACID guarantees like relational database (management) systems (RDBMS) choose consistency over availability, whereas NoSQL databases are mostly systems designed referring to the BASE philosophy which prefer availability over consistency.

The CAP Theorem in the real world

Lets look at some examples to understand the CAP Theorem further and provewe cannot create database systems which are being consistent, partition tolerant as well as always available simultaniously.

AP – Availability + Partition Tolerance

If we have achieved Availability (our databases will always respond to our requests) as well as Partition Tolerance (all nodes of the database will work even if they cannot communicate), it will immediately mean that we cannot provide Consistency as all nodes will go out of sync as soon as we write new information to one of the nodes. The nodes will continue to accept the database transactions each separately, but they cannot transfer the transaction between each other keeping them in synchronization. We therefore cannot fully guarantee the system consistency. When the partition is resolved, the AP databases typically resync the nodes to repair all inconsistencies in the system.

A well-known real world example of an AP system is the Domain Name System (DNS). This central network component is responsible for resolving domain names into IP addresses and focuses on the two properties of availability and failure tolerance. Thanks to the large number of servers, the system is available almost without exception. If a single DNS server fails,another one takes over. According to the CAP theorem, DNS is not consistent: If a DNS entry is changed, e.g. when a new domain has been registered or deleted, it can take a few days before this change is passed on to the entire system hierarchy and can be seen by all clients.

CA – Consistency + Availability

Guarantee of full Consistency and Availability is practically impossible to achieve in a system which distributes data over several nodes. We can have databases over more than one node online and available, and we keep the data consistent between these nodes, but the nature of computer networks (LAN, WAN) is that the connection can get interrupted, meaning we cannot guarantee the Partition Tolerance and therefor not the reliability of having the whole database service online at all times.

Database management systems based on the relational database models (RDBMS) are a good example of CA systems. These database systems are primarily characterized by a high level of consistency and strive for the highest possible availability. In case of doubt, however, availability can decrease in favor of consistency. Reliability by distributing data over partitions in order to make data reachable in any case – even if computer or network failure – meanwhile plays a subordinate role.

CP – Consistency + Partition Tolerance

If the Consistency of data is given – which means that the data between two or more nodes always contain the up-to-date information – and Partition Tolerance is given as well – which means that we are avoiding any desynchronization of our data between all nodes, then we will lose Availability as soon as only one a partition occurs between any two nodes In most distributed systems, high availability is one of the most important properties, which is why CP systems tend to be a rarity in practice. These systems prove their worth particularly in the financial sector: banking applications that must reliably debit and transfer amounts of money on the account side are dependent on consistency and reliability by consistent redundancies to always be able to rule out incorrect postings – even in the event of disruptions in the data traffic. If consistency and reliability is not guaranteed, the system might be unavailable for the users.

CAP Theorem Venn Diagram

Conclusion

The CAP Theorem is still an important topic to understand for data engineers and data scientists, but many modern databases enable us to switch between the possibilities within the CAP Theorem. For example, the Cosmos DB von Microsoft Azure offers many granular options to switch between the consistency, availability and partition tolerance . A common misunderstanding of the CAP theorem that it´s none-absoluteness: “All three properties are more continuous than binary. Availability is continuous from 0 to 100 percent, there are many levels of consistency, and even partitions have nuances. Exploring these nuances requires pushing the traditional way of dealing with partitions, which is the fundamental challenge. Because partitions are rare, CAP should allow perfect C and A most of the time, but when partitions are present or perceived, a strategy is in order.” (Brewer, E., 2012).

Benjamin Aunkofer

ACID vs BASE Concepts

/0 Comments/in , , , , , /by

Understanding databases for storing, updating and analyzing data requires the understanding of two concepts: ACID and BASE. This is the first article of the article series Data Warehousing Basics.

The properties of ACID are being applied for databases in order to fulfill enterprise requirements of reliability and consistency.

ACID is an acronym, and stands for:

  • Atomicity – Each transaction is either properly executed completely or does not happen at all. If the transaction was not finished the process reverts the database back to the state before the transaction started. This ensures that all data in the database is valid even if we execute big transactions which include multiple statements (e. g. SQL) composed into one transaction updating many data rows in the database. If one statement fails, the entire transaction will be aborted, and hence, no changes will be made.
  • Consistency – Databases are governed by specific rules defined by table formats (data types) and table relations as well as further functions like triggers. The consistency of data will stay reliable if transactions never endanger the structural integrity of the database. Therefor, it is not allowed to save data of different types into the same single column, to use written primary key values again or to delete data from a table which is strictly related to data in another table.
  • Isolation – Databases are multi-user systems where multiple transactions happen at the same time. With Isolation, transactions cannot compromise the integrity of other transactions by interacting with them while they are still in progress. It guarantees data tables will be in the same states with several transactions happening concurrently as they happen sequentially.
  • Durability – The data related to the completed transaction will persist even in cases of network or power outages. Databases that guarante Durability save data inserted or updated permanently, save all executed and planed transactions in a recording and ensure availability of the data committed via transaction even after a power failure or other system failures If a transaction fails to complete successfully because of a technical failure, it will not transform the targeted data.

ACID Databases

The ACID transaction model ensures that all performed transactions will result in reliable and consistent databases. This suits best for businesses which use OLTP (Online Transaction Processing) for IT-Systems such like ERP- or CRM-Systems. Furthermore, it can also be a good choice for OLAP (Online Analytical Processing) which is used in Data Warehouses. These applications need backend database systems which can handle many small- or medium-sized transactions occurring simultaneous by many users. An interrupted transaction with write-access must be removed from the database immediately as it could cause negative side effects impacting the consistency(e.g., vendors could be deleted although they still have open purchase orders or financial payments could be debited from one account and due to technical failure, never credited to another).

The speed of the querying should be as fast as possible, but even more important for those applications is zero tolerance for invalid states which is prevented by using ACID-conform databases.

BASE Concept

ACID databases have their advantages but also one big tradeoff: If all transactions need to be committed and checked for consistency correctly, the databases are slow in reading and writing data. Furthermore, they demand more effort if it comes to storing new data in new formats.

In chemistry, a base is the opposite to acid. The database concepts of BASE and ACID have a similar relationship. The BASE concept provides several benefits over ACID compliant databases asthey focus more intensely on data availability of database systems without guarantee of safety from network failures or inconsistency.

The acronym BASE is even more confusing than ACID as BASE relates to ACID indirectly. The words behind BASE suggest alternatives to ACID.

BASE stands for:

  • Basically Available – Rather than enforcing consistency in any case, BASE databases will guarantee availability of data by spreading and replicating it across the nodes of the database cluster. Basic read and write functionality is provided without liabilityfor consistency. In rare cases it could happen that an insert- or update-statement does not result in persistently stored data. Read queries might not provide the latest data.
  • Soft State – Databases following this concept do not check rules to stay write-consistent or mutually consistent. The user can toss all data into the database, delegating the responsibility of avoiding inconsistency or redundancy to developers or users.
  • Eventually Consistent –No guarantee of enforced immediate consistency does not mean that the database never achieves it. The database can become consistent over time. After a waiting period, updates will ripple through all cluster nodes of the database. However, reading data out of it will stay always be possible, it is just not certain if we always get the last refreshed data.

All the three above mentioned properties of BASE-conforming databases sound like disadvantages. So why would you choose BASE? There is a tradeoff compared to ACID. If databases do not have to follow ACID properties then the database can work much faster in terms of writing and reading from the database. Further, the developers have more freedom to implement data storage solutions or simplify data entry into the database without thinking about formats and structure beforehand.

BASE Databases

While ACID databases are mostly RDBMS, most other database types, known as NoSQL databases, tend more to conform to BASE principles. Redis, CouchDB, MongoDB, Cosmos DB, Cassandra, ElasticSearch, Neo4J, OrientDB or ArangoDB are just some popular examples. But other than ACID, BASE is not a strict approach. Some NoSQL databases apply at least partly to ACID rules or provide optional functions to get almost or even full ACID compatibility. These databases provide different level of freedom which can be useful for the Staging Layer in Data Warehouses or as a Data Lake, but they are not the recommended choice for applications which need data environments guaranteeing strict consistency.

Benjamin Aunkofer

Data Warehousing Basiscs

/1 Comment/in , , , , , , , , , /by

Data Warehousing is applied Big Data Management and a key success factor in almost every company. Without a data warehouse, no company today can control its processes and make the right decisions on a strategic level as there would be a lack of data transparency for all decision makers. Bigger comanies even have multiple data warehouses for different purposes.

In this series of articles I would like to explain what a data warehouse actually is and how it is set up. However, I would also like to explain basic topics regarding Data Engineering and concepts about databases and data flows.

To do this, we tick off the following points step by step:

 

Benjamin Aunkofer

Six properties of modern Business Intelligence

/1 Comment/in , , , , , , , , /by

Regardless of the industry in which you operate, you need information systems that evaluate your business data in order to provide you with a basis for decision-making. These systems are commonly referred to as so-called business intelligence (BI). In fact, most BI systems suffer from deficiencies that can be eliminated. In addition, modern BI can partially automate decisions and enable comprehensive analyzes with a high degree of flexibility in use.

Read this article in German:
“Sechs Eigenschaften einer modernen Business Intelligence“

Let us discuss the six characteristics that distinguish modern business intelligence, which mean taking technical tricks into account in detail, but always in the context of a great vision for your own company BI:

1. Uniform database of high quality

Every managing director certainly knows the situation that his managers do not agree on how many costs and revenues actually arise in detail and what the margins per category look like. And if they do, this information is often only available months too late.

Every company has to make hundreds or even thousands of decisions at the operational level every day, which can be made much more well-founded if there is good information and thus increase sales and save costs. However, there are many source systems from the company’s internal IT system landscape as well as other external data sources. The gathering and consolidation of information often takes up entire groups of employees and offers plenty of room for human error.

A system that provides at least the most relevant data for business management at the right time and in good quality in a trusted data zone as a single source of truth (SPOT). SPOT is the core of modern business intelligence.

In addition, other data on BI may also be made available which can be useful for qualified analysts and data scientists. For all decision-makers, the particularly trustworthy zone is the one through which all decision-makers across the company can synchronize.

2. Flexible use by different stakeholders

Even if all employees across the company should be able to access central, trustworthy data, with a clever architecture this does not exclude that each department receives its own views of this data. Many BI systems fail due to company-wide inacceptance because certain departments or technically defined employee groups are largely excluded from BI.

Modern BI systems enable views and the necessary data integration for all stakeholders in the company who rely on information and benefit equally from the SPOT approach.

3. Efficient ways to expand (time to market)

The core users of a BI system are particularly dissatisfied when the expansion or partial redesign of the information system requires too much of patience. Historically grown, incorrectly designed and not particularly adaptable BI systems often employ a whole team of IT staff and tickets with requests for change requests.

Good BI is a service for stakeholders with a short time to market. The correct design, selection of software and the implementation of data flows / models ensures significantly shorter development and implementation times for improvements and new features.

Furthermore, it is not only the technology that is decisive, but also the choice of organizational form, including the design of roles and responsibilities – from the technical system connection to data preparation, pre-analysis and support for the end users.

4. Integrated skills for Data Science and AI

Business intelligence and data science are often viewed and managed separately from each other. Firstly, because data scientists are often unmotivated to work with – from their point of view – boring data models and prepared data. On the other hand, because BI is usually already established as a traditional system in the company, despite the many problems that BI still has today.

Data science, often referred to as advanced analytics, deals with deep immersion in data using exploratory statistics and methods of data mining (unsupervised machine learning) as well as predictive analytics (supervised machine learning). Deep learning is a sub-area of ​​machine learning and is used for data mining or predictive analytics. Machine learning is a sub-area of ​​artificial intelligence (AI).

In the future, BI and data science or AI will continue to grow together, because at the latest after going live, the prediction models flow back into business intelligence. BI will probably develop into ABI (Artificial Business Intelligence). However, many companies are already using data mining and predictive analytics in the company, using uniform or different platforms with or without BI integration.

Modern BI systems also offer data scientists a platform to access high-quality and more granular raw data.

5. Sufficiently high performance

Most readers of these six points will probably have had experience with slow BI before. It takes several minutes to load a daily report to be used in many classic BI systems. If loading a dashboard can be combined with a little coffee break, it may still be acceptable for certain reports from time to time. At the latest, however, with frequent use, long loading times and unreliable reports are no longer acceptable.

One reason for poor performance is the hardware, which can be almost linearly scaled to higher data volumes and more analysis complexity using cloud systems. The use of cloud also enables the modular separation of storage and computing power from data and applications and is therefore generally recommended, but not necessarily the right choice for all companies.

In fact, performance is not only dependent on the hardware, the right choice of software and the right choice of design for data models and data flows also play a crucial role. Because while hardware can be changed or upgraded relatively easily, changing the architecture is associated with much more effort and BI competence. Unsuitable data models or data flows will certainly bring the latest hardware to its knees in its maximum configuration.

6. Cost-effective use and conclusion

Professional cloud systems that can be used for BI systems offer total cost calculators, such as Microsoft Azure, Amazon Web Services and Google Cloud. With these computers – with instruction from an experienced BI expert – not only can costs for the use of hardware be estimated, but ideas for cost optimization can also be calculated. Nevertheless, the cloud is still not the right solution for every company and classic calculations for on-premise solutions are necessary.

Incidentally, cost efficiency can also be increased with a good selection of the right software. Because proprietary solutions are tied to different license models and can only be compared using application scenarios. Apart from that, there are also good open source solutions that can be used largely free of charge and can be used for many applications without compromises.

However, it is wrong to assess the cost of a BI only according to its hardware and software costs. A significant part of cost efficiency is complementary to the aspects for the performance of the BI system, because suboptimal architectures work wastefully and require more expensive hardware than neatly coordinated architectures. The production of the central data supply in adequate quality can save many unnecessary processes of data preparation and many flexible analysis options also make redundant systems unnecessary and lead to indirect savings.

In any case, a BI for companies with many operational processes is always cheaper than no BI. However, if you take a closer look with BI expertise, cost efficiency is often possible.

Benjamin Aunkofer

Interview: Profitiert Business Intelligence vom Data Warehouse in der Cloud?

/0 Comments/in , , , /by

Interview mit Ross Perez, Senior Director, Marketing EMEA bei Snowflake

Read this Article in English:
“Does Business Intelligence benefit from Cloud Data Warehousing?”

Profitiert Business Intelligence vom Cloud Data Warehousing?

Ross Perez ist Senior Director Marketing EMEA bei Snowflake. Er leitet das Snowflake-Marketingteam in EMEA und ist damit beauftragt, die Diskussion über Analysen, Daten und Cloud-Data-Warehousing in EMEA voran zu bringen. Vor Snowflake war Ross Produkt Marketer bei Tableau Software, wo er die Iron Viz Championship gründete, den weltweit größten und aufwändigsten Wettbewerb für Datenvisualisierung.

Data Science Blog: Ross, Business Intelligence (BI) ist kein wirklich neuer Trend. In 2019/2020 sollte es kein Thema mehr sein, Daten für das ganze Unternehmen verfügbar zu machen. Stimmt das soweit?

BI ist definitiv ein alter Trend, denn Berichterstattung gibt es schon seit 50 Jahren. Die Menschen sind es gewohnt, Statistiken und Daten für das gesamte Unternehmen und sogar für ihre Geschäftsbereiche zu erhalten. Die Verwendung von BI zur Bereitstellung von Analysen für alle Mitarbeiter im Unternehmen und die Ermutigung zur Entscheidungsfindung auf der Grundlage von Daten für den jeweiligen Bereich ist jedoch relativ neu. In vielen Unternehmen, mit denen Snowflake zusammenarbeitet, gibt es eine neue Gruppe von Mitarbeitern, die gerade erst den Zugriff auf Self-Service-BI- und Visualisierungstools wie Tableau, Looker und Sigma erhalten haben und nun auch anfangen, Antworten auf ihre Fragen zu finden.

Data Science Blog: Bi jetzt ging es im BI vor allem darum Dashboards für Geschäftsberichte zu erstellen. Und dabei spielte das Data Warehouse (DWH) die Rolle des Backends. Heute haben wir einen noch viel größeren Bedarf an Datentransparenz. Wie sollten Unternehmen damit umgehen?

Da immer mehr Mitarbeiter in immer mehr Abteilungen immer häufiger auf Daten zugreifen möchten, steigt die Nachfrage nach Back-End-Systemen – wie dem Data Warehouse – rapide. In vielen Fällen verfügen Unternehmen über Data Warehouses, die nicht für diese gleichzeitige und heterogene Nachfrage gebaut wurden. Die Erfahrungen der Mitarbeiter mit dem DWH und BI sind daher oftmals schlecht, denn Endbenutzer müssen lange auf ihre Berichte warten. Und nun kommt Snowflake ins Spiel: Da wir die Leistung der Cloud nutzen können, um Ressourcen auf Abruf bereitzustellen, können wir beliebig viele Benutzer gleichzeitig bedienen. Snowflake kann zudem unbegrenzte Datenmengen sowohl in strukturierten als auch in halbstrukturierten Formaten speichern.

Data Science Blog: Würden Sie sagen, dass das DWH der Schlüssel dazu ist, ein datengetriebenes Unternehmen zu werden? Was sollte noch bedacht werden?

Absolut. Ohne alle Ihre Daten in einem einzigen, hoch-elastischen und flexiblen Data Warehouse zu haben, kann es eine große Herausforderung sein, den Mitarbeitern im Unternehmen Einblicke zu gewähren.

Data Science Blog: So viel zur Theorie, lassen Sie uns nun über spezifische Anwendungsfälle sprechen. Generell macht es einen großen Unterschied, welche Daten wir speichern und analysieren wollen, beispielsweise Finanz- oder Maschinendaten. Was dürfen wir dabei nicht vergessen, wenn es um die Erstellung eines DWHs geht?

Finanzdaten und Maschinendaten sind sehr unterschiedlich und liegen häufig in unterschiedlichen Formaten vor. Beispielsweise weisen Finanzdaten häufig ein relationales Standardformat auf. Daten wie diese müssen mit Standard-SQL einfach abgefragt werden können, was viele Hadoop- und noSQL-Tools nicht sinnvoll bereitstellen konnten. Zum Glück handelt es sich bei Snowflake um ein SQL-Data-Warehouse nach ANSI-Standard, sodass die Verwendung dieser Art von Daten problemlos möglich ist.

Zum anderen sind Maschinendaten häufig teilstrukturiert oder sogar völlig unstrukturiert. Diese Art von Daten wird mit dem Aufkommen von Internet of Things (IoT) immer häufiger, aber herkömmliche Data Warehouses haben sich bisher kaum darauf vorbereitet, da sie für relationale Daten optimiert wurden. Halbstrukturierte Daten wie JSON, Avro, XML, Orc und Parkett können in Snowflake zur Analyse nahtlos in ihrem nativen Format geladen werden. Dies ist wichtig, da Sie die Daten nicht reduzieren müssen, um sie nutzen zu können.

Beide Datentypen sind wichtig und Snowflake ist das erste Data Warehouse, das nahtlos mit beiden zusammenarbeitet.

Data Science Blog: Zurück zum gewöhnlichen Anwendungsfall im Business, also der Erstellung von Verkaufs- und Einkaufs-Berichten für die Business Manager, die auf Daten von ERP-Systemen – wie etwa von Microsoft oder SAP – basieren. Welche Architektur könnte für das DWH die richtige sein? Wie viele Layer braucht ein DWH dafür?

Die Art des Berichts spielt weitgehend keine Rolle, da Sie in jedem Fall ein Data Warehouse benötigen, das alle Ihre Daten unterstützt und alle Ihre Benutzer bedient. Idealerweise möchten Sie es auch in der Lage sein, es je nach Bedarf ein- und auszuschalten. Das bedeutet, dass Sie eine Cloud-basierte Architektur benötigen… und insbesondere die innovative Architektur von Snowflake, die Speicher und Computer voneinander trennt und es Ihnen ermöglicht, genau das zu bezahlen, was Sie verwenden.

Data Science Blog: Wo würden Sie den Hauptteil der Geschäftslogik für einen Report implementieren? Tendenziell eher im DWH oder im BI-Tool, dass für das Reporting verwendet word? Hängt es eigentlich vom BI-Tool ab?

Das Tolle ist, dass Sie es frei wählen können. Snowflake kann als Data Warehouse für SQL nach dem ANSI-Standard ein hohes Maß an Datenmodellierung und Geschäftslogik-Implementierung unterstützen. Sie können aber auch Partner wie Looker und Sigma einsetzen, die sich auf die Datenmodellierung für BI spezialisiert haben. Wir sind der Meinung, dass es am besten ist, wenn jedes Unternehmen für sich selbst entscheidet, was der individuell richtige Ansatz ist.

Data Science Blog: Snowflake ermöglicht es Organisationen, Daten in der Cloud zu speichern und zu verwalten. Heißt das aber auch, dass Unternehmen ein Stück weit die Kontrolle über ihre eigenen Daten verlieren?

Kunden haben die vollständige Kontrolle über ihre Daten und Snowflake kann keinen Teil ihrer Daten sehen oder ändern. Der Vorteil einer Cloud-Lösung besteht darin, dass Kunden weder die Infrastruktur noch das Tuning verwalten müssen. Sie entscheiden, wie sie ihre Daten speichern und analysieren möchten, und Snowflake kümmert sich um den Rest.

Data Science Blog: Wie groß ist der Aufwand für kleinere oder mittelgroße Unternehmen, ein DWH in der Cloud zu errichten? Und bedeutet es auch, dass damit ein teures Langzeit-Projekt verbunden ist?

Das Schöne an Snowflake ist, dass Sie in wenigen Minuten mit einer kostenlosen Testversion beginnen können. Nun kann der Wechsel von einem herkömmlichen Data Warehouse zu Snowflake einige Zeit in Anspruch nehmen, abhängig von der von Ihnen verwendeten Legacy-Technologie. Snowflake selbst ist jedoch recht einfach einzurichten und sehr gut mit historischen Werkzeugen kompatibel. Der Einstieg könnte daher nicht einfacherer sein.

events

Meetup: Scalable Data Management “Warum agile Firmen auf Snowflake & Data Virtuality setzen”

/0 Comments/in /by
Erfahren Sie aus erster Hand, warum skalierbare Datenmanagementlösungen die Voraussetzung für agile Unternehmen sind. Um dies greifbarer zu machen haben wir einige Experten aus der Praxis eingeladen, die anhand realer Beispiele das Thema näher beleuchten und ihre wertvollen, langjährigen Erfahrungen mit uns teilen werden. Beim anschließenden Networking Event können Sie sich mit anderen Teilnehmern austauschen.

Snowflake ist eine analytische cloudbasierte Datenbank. Ein einziger Ort für alle Ihre Daten, alle Ihre Benutzer. Eine Lösung, die sich durch hohe Leistung, Benutzerfreundlichkeit, Parallelität und einen attraktiven Preis auszeichnet.

Data Virtuality bietet Datenintegrationslösungen an, mit denen Unternehmen ihre Daten von verschiedenen Datenquellen – wie APIs, Datenbanken und Flat Files – einfach verbinden und verwalten können. Die revolutionäre Plattform, die konsistente Datenbestände aller Daten gewährleistet (single source of truth), verbindet Datenvirtualisierung und automatisierte ETL Prozesse. Das Ergebnis: vereinfachtes Datenmanagement und um bis zu 80% effizientere Datenintegration.

Agenda:
14:00 – 14:15   Registrierung
14:15 – 14:45   Keynote (Nick Golovin, CEO von Data Virtuality)
14:45 – 17:15   Best Practices
17:15 – 17:30   Q&A
17:30 – 18:30   Networking

Tower 1 / 32. OG
Mies-van-der-Rohe Str. 6
80807 München
Thomas Scholz

DS-GVO: Wie das moderne Data-Warehouse Unternehmen entlastet

/1 Comment/in , , , , /by

Artikel des Blog-Sponsors: Snowflake

Viele Aktivitäten, die zur Einhaltung der DS-GVO-Anforderungen beitragen, liegen in den Händen der Unternehmen selbst. Deren IT-Anbieter sollten dazu beitragen, die Compliance-Anforderungen dieser Unternehmen zu erfüllen. Die SaaS-Anbieter eines Unternehmens sollten zumindest die IT-Sicherheitsanforderungen erfüllen, die sich vollständig in ihrem Bereich befinden und sich auf die Geschäfts- und Datensicherheit ihrer Kunden auswirken.

Snowflake wurde von Grund auf so gestaltet, dass die Einhaltung der DS-GVO erleichtert wird – und von Beginn darauf ausgelegt, enorme Mengen strukturierter und semistrukturierter Daten mit der Leichtigkeit von Standard-SQL zu verarbeiten. Die Zugänglichkeit und Einfachheit von SQL gibt Organisationen die Flexibilität, alle unter der DS-GVO erforderlichen Aktualisierungen, Änderungen oder Löschungen nahtlos vorzunehmen. Snowflakes Unterstützung für semistrukturierte Daten kann die Anpassung an neue Felder und andere Änderungen der Datensätze erleichtern. Darüber hinaus war die Sicherheit von Anfang an von grundlegender Bedeutung für Architektur, Implementierung und Betrieb von Snowflakes Data-Warehouse-as-a-Service.

Ein Grundprinzip der DS-GVO

Ein wichtiger Faktor für die Einhaltung der DS-GVO ist, zu verstehen, welche Daten eine Organisation besitzt und auf wen sie sich beziehen. Diese Anforderung macht es nötig, dass Daten strukturiert, organisiert und einfach zu suchen sind.

Die relationale SQL-Datenbankarchitektur von Snowflake bietet eine erheblich vereinfachte Struktur und Organisation, was sicherstellt, dass jeder Datensatz einen eindeutigen und leicht identifizierbaren Speicherort innerhalb der Datenbank besitzt. Snowflake-Kunden können auch relationalen Speicher mit dem Variant-Spaltentyp von Snowflake für semistrukturierte Daten kombinieren. Dieser Ansatz erweitert die Einfachheit des relationalen Formats auf die Schema-Flexibilität semistrukturierter Daten.

Snowflake ist noch leistungsfähiger durch seine Fähigkeit, massive Nebenläufigkeit zu unterstützen. Bei größeren Organisationen können Dutzende oder sogar Hunderte nebenläufiger Datenänderungen, -abfragen und -suchvorgänge zu einem bestimmten Zeitpunkt auftreten. Herkömmliche Data-Warehouses können nicht zu einem bestimmten Zeitpunkt über einen einzelnen Rechen-Cluster hinaus skaliert werden, was zu langen Warteschlangen und verzögerter Compliance führt. Snowflakes Multi-Cluster-Architektur für gemeinsam genutzte Daten löst dieses Problem, indem sie so viele einzigartige Rechen-Cluster bereitstellen kann, wie für einen beliebigen Zweck nötig sind, was zu einer effizienteren Workload-Isolierung und höherem Abfragedurchsatz führt. Jeder Mitarbeiter kann sehr große Datenmengen mit so vielen nebenläufigen Benutzern oder Operationen wie nötig speichern, organisieren, ändern, suchen und abfragen.

Rechte von Personen, deren Daten verarbeitet werden („Datensubjekte“)

Organisationen, die von der DS-GVO betroffen sind, müssen sicherstellen, dass sie Anfragen betroffener Personen nachkommen können. Einzelpersonen haben jetzt erheblich erweiterte Rechte, um zu erfahren, welche Art von Daten eine Organisation über sie besitzt, und das Recht, den Zugriff und/oder die Korrektur ihrer Daten anzufordern, die Daten zu löschen und/oder die Daten an einen neuen Provider zu übertragen. Bei der Bereitstellung dieser Dienste müssen Organisationen ziemlich schnell reagieren, in der Regel innerhalb von 30 Tagen. Daher müssen sie ihre Geschäftssysteme und ihr Data-Warehouse schnell durchsuchen können, um alle personenbezogenen Daten zu finden, die mit einer Person in Verbindung stehen, und entsprechende Maßnahmen ergreifen.

Organisationen können in großem Umfang von der Speicherung aller Daten in einem Data-Warehouse-as-a-Service mit vollen DML- und SQL-Fähigkeiten profitieren. Dies erleichtert das (mühevolle) Durchsuchen getrennter Geschäftssysteme und Datenspeicher, um die relevanten Daten zu finden. Und das wiederum hilft sicherzustellen, dass einzelne Datensätze durchsucht, gelöscht, eingeschränkt, aktualisiert, aufgeteilt und auf andere Weise manipuliert werden können, um sie an entsprechende Anfragen betroffener Personen anzupassen. Außerdem können Daten so verschoben werden, dass sie der Anforderung einer Anfrage zum „Recht auf Datenübertragbarkeit“ entsprechen. Von Anfang an wurde Snowflake mit ANSI-Standard-SQL und vollständiger DML-Unterstützung entwickelt, um sicherzustellen, dass diese Arten von Operationen möglich sind.

Sicherheit

Leider erfordern es viele herkömmliche Data-Warehouses, dass sich Unternehmen selbst um die IT-Sicherheit kümmern und diese mit anderen Services außerhalb des Kernangebots kombiniert wird. Außerdem bieten sie manchmal noch nicht einmal standardmäßige Verschlüsselung.

Als Data-Warehouse, das speziell für die Cloud entwickelt wurde und das Sicherheit als zentrales Element bietet, umfasst Snowflake unter anderem folgende integrierte Schutzfunktionen:

  • Minimaler Betriebsaufwand: Weniger Komplexität durch automatische Performance, Sicherheit und Hochverfügbarkeit, sodass die Infrastruktur nicht optimiert werden muss und kein Tuning nötig ist.
  • Durchgängige Verschlüsselung: Automatische Verschlüsselung aller Daten jederzeit (in ruhendem und bewegtem Zustand).
  • Umfassender Schutz: Zu den Sicherheitsfunktionen zählen Multi-Faktor-Authentifizierung, rollenbasierte Zugriffskontrolle, IP-Adressen-Whitelisting, zentralisierte Authentifizierung und jährliche Neuverschlüsselung verschlüsselter Daten.
  • Tri-Secret Secure: Kundenkontrolle und Datenschutz durch die Kombination aus einem vom Kunden, einem von Snowflake bereitgestellten Verschlüsselungsschlüssel und Benutzerzugangsdaten.
  • Unterstützung für AWS Private Link: Kunden können Daten zwischen ihrem virtuellen privaten Netzwerk und Snowflake übertragen, ohne über das Internet gehen zu müssen. Dadurch ist die Konnektivität zwischen den Netzwerken sicher und einfacher zu verwalten.
  • Stärkere unternehmensinterne Datenabgrenzung dank Snowflake Data Sharing: Organisationen können die Datenfreigabefunktionen von Snowflake nutzen, um nicht personenbezogene Daten mit anderen Abteilungen zu teilen, die keinen Zugriff benötigen – indem sie strengere Sicherheits- und DS-GVO-Kontrollen durchsetzen.
  • Private Umgebung: Unternehmen können eine dedizierte, verwaltete Snowflake- Instanz in einer separaten AWS Virtual Private Cloud (VPC) abrufen.

Rechenschaftspflicht

Was die Komplexität weiter erhöht: Organisationen müssen auch sicherstellen, dass sie und die Organisationen und Tools, mit denen sie arbeiten, Compliance nachweisen können. Snowflake prüft und verfeinert seine IT-Sicherheitspraxis regelmäßig mit peniblen Penetrationstests. Snowflakes Data-Warehouse-as-a-Service ist zertifiziert nach SOC 2 Type II, ist PCI-DSS-konform und unterstützt HIPAA-Compliance. Um Anfragen von Personen, deren Daten verarbeitet werden („Datensubjekte“), zu entsprechen, können Kunden genutzte Daten überprüfen.

Zusätzlich zu diesen Standardfunktionen und -validierungen schützt Snowflake seine Kunden auch durch den Datenschutznachtrag („Data Protection Addendum“), der genau auf die Anforderungen der DS-GVO abgestimmt ist. Snowflake hält sich außerdem an penibel vertraglich festgelegte Sicherheitsverpflichtungen („contractual security commitments“), um effizientere Transaktionen und eine vereinfachte Sorgfaltspflicht zu ermöglichen.

Fazit

Im Rahmen der Europäischen Datenschutz-Grundverordnung müssen Unternehmen technische Maßnahmen ergreifen, mit deren Hilfe sie den Anforderungen ihrer Kunden in Bezug auf Datenschutz und Schutz der Privatsphäre gerecht werden können. Snowflake bietet hier nicht nur den Vorteil, alle wichtigen Kundendaten an einem einzigen Ort zu speichern, sondern ermöglicht auch das schnelle Auffinden und Abrufen dieser Daten, sodass Unternehmen im Bedarfsfall schnell aktiv werden können.

Hoang Tu Nguyen

Datenmodell: Sternschema

/1 Comment/in , , /by

Ob es unsere Schritte während des Sports sind, Klicks auf Websiten oder auch Geschäftszahlen eines Unternehmens – all diese Informationen werden in Form von Daten gespeichert. Dabei fallen große Mengen an Daten an, die in der Regel in einer relationalen Datenbank gespeichert werden, um sie besonders gut administrieren zu können.
Gerade in einem Unternehmen ist es wichtig, dass mehrere Benutzer parallel und mit wenig Verzögerung Anfragen und Änderungen in den Daten durchführen können. Daher werden viele Datenbanken in Unternehmen als OLTP-Datenbank-Systeme ausgelegt. OLTP steht für Online Transaction Processing, auch Echtzeit-Transaktionsverarbeitung ist dafür optimiert, schnelle und parallele Zugriffe auf Daten in der Datenbank zu gewährleisten.
Möchte man hingegen Daten auswerten und analysieren, sind OLTP-Datenbanken-Systeme weniger geeignet, da sie nicht für diese Art von Anfragen konzipiert worden sind. Um effektiv analytische Befehle an eine Datenbank stellen zu können, werden daher Datenbanken genutzt, die mit einer OLAP-Verarbeitung arbeiten. OLAP ist die Abkürzung für Online Analytical Processing. Im Gegensatz zu OLTP, in welchen die Daten in einem zweidimensionalen Modell gespeichert werden, sind Daten in einem OLAP-System in einer multidimensionalen Struktur untergebracht, welche für die Durchführung komplexer Analysebefehle optimiert ist.
Für Analysen werden oft Daten aus mehreren Datenbanken benötigt, weswegen sie in einem Datenlager – oder auch Data Warehouse genannt – zusammengefasst und gespeichert werden. Ein Data Warehouse, welche auf der OLAP-Verarbeitung basiert, ist somit eine für Analysezwecke optimierte Datenbank.
Es gibt verschiedene Datenmodelle um die Daten in einem Data Warehouse anzulegen. Das verbreiteste Datenmodell für diese Zwecke ist das sogenannte Sternen-Schema (Star Schema). Neben dem Sternen-Schema gibt es auch die sogenannten Galaxy- und Snowflake-Schemen, die wiederum eine Erweiterung des zuerst genannten Datenmodells sind. In diesem Artikel werden wir das Sternschema näher beleuchten.

Aufbau und Funktionsweise

Bei einem Sternschema werden die Daten grundlegend in zwei Gruppen unterteilt:

  • Fakten, manchmal auch Metriken, Messwerte oder Kennzahlen genannt, sind die zu verwaltenden bzw. die zu analysierenden Daten und werden fortlaufend in der Faktentabelle gespeichert. Beispielhaft für Fakten sind Umsätze sowie Verkaufszahlen eines Unternehmens. Sie haben stets eine numerische Form.
  • Dimensionen sind die Attribute bzw. Eigenschaften der Fakten und beschreiben sozusagen die Fakten im Detail. Diese werden in Dimensionstabellen gelistet. Jeder Dimensionsdatensatz bzw. jede Zeile einer Dimensionstabelle wird durch Primärschlüssel eindeutig identifiziert. Diese Schlüssel werden in der Faktentabelle als Fremdschlüssel gespeichert und somit sind Dimensions- und Faktentabelle miteinander verknüpft.

Beispiel: Max Mustermann, 25 Jahre alt, wohnhaft in Musterstadt hat eine Kaffeemaschine mit dem Namen ‘Musterpresso’ am 01.01.2018 um 15:00:00 gekauft.

Wie in der Abbildung dargestellt, werden die Details, als Attribute dargestellt, vom Kunden wie Namen, Alter oder Wohnort in der Dimensionstabelle “Kunde” gespeichert und mit dem Primärschlüssel (in diesem Beispiel “1111”) gekennzeichnet. Dieser wird in der Faktentabelle als Fremdschlüssel gespeichert. Analog zu den Daten vom Kunden werden auch Dimensionstabellen für die Größen

  • Bestellung,
  • Produkt,
  • Produktkategorie und
  • Zeit gebildet.

Die Fakten, welche in diesem Beispiel der Umsatz von Max Mustermann ein Fakt wäre, können nun mithilfe der Fremdschlüssel

  • Kunden ID,
  • Bestellung ID,
  • Produkt ID,
  • Produktkategorie ID und
  • Zeit

aus der Faktentabelle aufgerufen werden.

Bei der Bildung von Tabellen ist es möglich, dass identische Werte mehrfach gespeichert werden. Dabei können Redundanzen und Anomalien in der Datenbank enstehen, welche zusätzlich einen erhöhten Speicherbedarf erfordern. Um dies zu verhindern werden Tabellen normalisiert. Bei einer Normalisierung einer Tabelle bzw. einer Tabellenstruktur wird es angestrebt, Redundanzen bis auf ein Maximum zu reduzieren. Je nach Grad der Normalisierung können diese in verschiedene Normalformen (1NF -2NF-3NF-BCNF-4NF-5NF) unterteilt werden.

Die Normalisierung in eine höhere Normalform hat jedoch zur Folge, dass die Abfrage-Performance abnimmt. Da das Sternschema-Modell darauf ausgelegt ist Leseoperationen effizient durchzuführen, sind Faktentabellen in der dritten Normalform (3NF) abgespeichert, da alle Redundanzen in dieser Form beseitigt worden sind und dennoch eine hohe Performance gewährleistet. Dimensionstabellen sind hingegen nur bis zur zweiten Normalform (2NF) optimiert. Es werden also bewusst Redundanzen und ein erhöhter Speicherbedarf in den Dimensionstabellen für eine schnelle Abfrage der Daten in Kauf genommen.

Vor- und Nachteile

Wie bereits erwähnt, sind Dimensionstabellen im Sternschema nicht vollständig normalisiert. Damit nimmt man zugunsten höherer Performance mögliche Anomalien und auch einen erhöhten Speicherbedarf in Kauf. Durch das einfache Modell ist dafür jedoch eine intuitive Bedienung möglich und auch Veränderungen sowie Erweiterungen des Modell sind leicht realisierbar.

Vorteile Nachteile
Einfaches Modell ermöglicht eine intuitive Bedienung. Durch mehrfaches Speichern identischer Werte steigt die Redundanz in den Dimenionstabellen
Veränderungen und Erweiterungen können leicht umgesetzt werden. Bei häufigen Abfragen sehr großer Dimensionstabellen verschlechtern sich die Antwortzeiten
Durch Verzicht der Normalisierung in den Dimensionstabellen ist die hierarchische Beziehung innerhalb einer Dimension leicht darstellbar Erhöhter Speicherbedarf durch Nicht-Normalisierung der Dimensionstabellen

Zusammenfassung

Das Sternschema ist ein Datenmodell, welches für analytische Zwecke im Data Warehouse und bei OLAP-Anwendungen zum Einsatz kommt. Es ist darauf optimiert, effiziente Leseoperationen zu gewährleisten.
Der Name des Modells beruht auf der sternförmigen Anordnung von Dimensionstabellen um die Faktentabelle, wobei die Dimensionstabellen die Attribute der Fakten beinhalten und in den Faktentabellen die zu analysierenden Größen gespeichert sind. Charakteristisch ist dabei, dass die Dimensionstabellen nicht bis zur dritten Normalform normalisiert sind. Der sich daraus ergebende Vorteil ist die schnelle Verarbeitung von Abfragen. Auch ist die intuitive Bedienung ein positiver Aspekt des einfachen Datenmodells. Jedoch können durch den Verzicht der Normalisierung Redundanzen innerhalb der Dimensionstabellen durch mehrfache Speicherung von identischen Werten entstehen. Ebenfalls ist bei häufigen Anfragen von großen Dimensionstabellen ein verschlechtertes Antwortverhalten feststellbar.
Daher sind sie vor allem dann effektiv, wenn

  • schnelle Anfrageverarbeitungen notwendig sind,
  • sich schnell ändernde Datenstrukturen (der Original-Daten) vorliegen,
  • Dimensionstabellen in ihrer Größe überschaubar bleiben,
  • und ein breites Spektrum an Benutzern Zugriff auf die Daten benötigt.

Events

Nothing Found

Sorry, no posts matched your criteria