100 open source Big Data architecture papers for data professionals

zhuan :https://www.linkedin.com/pulse/100-open-source-big-data-architecture-papers-anil-madan

Big Data technology has been extremely disruptive with open source playing a dominant role in shaping its evolution. While on one hand it has been disruptive, on the other it has led to a complex ecosystem where new frameworks, libraries and tools are being released pretty much every day, creating confusion as technologists struggle and grapple with the deluge.

If you are a Big Data enthusiast or a technologist ramping up (or scratching your head), it is important to spend some serious time deeply understanding the architecture of key systems to appreciate its evolution. Understanding the architectural components and subtleties would also help you choose and apply the appropriate technology for your use case. In my journey over the last few years, some literature has helped me become a better educated data professional. My goal here is to not only share the literature but consequently also use the opportunity to put some sanity into the labyrinth of open source systems.  
One caution, most of the reference literature included is hugely skewed towards deep architecture overview (in most cases original research papers) than simply provide you with basic overview. I firmly believe that deep dive will fundamentally help you understand the nuances, though would not provide you with any shortcuts, if you want to get a quick basic overview.

Jumping right in…

Key architecture layers

  • File Systems- Distributed file systems which provide storage, fault tolerance, scalability, reliability, and availability.
  • Data Stores– Evolution of application databases into Polyglot storage with application specific databases instead of one size fits all. Common ones are Key-Value, Document, Column and Graph.
  • Resource Managers– provide resource management capabilities and support schedulers for high utilization and throughput.
  • Coordination– systems that manage state, distributed coordination, consensus and lock management.
  • Computational Frameworks– a lot of work is happening at this layer with highly specialized compute frameworks for Streaming, Interactive, Real Time, Batch and Iterative Graph (BSP) processing. Powering these are complete computation runtimes like BDAS (Spark) & Flink.
  • DataAnalytics –Analytical (consumption) tools and libraries, which support exploratory, descriptive, predictive, statistical analysis and machine learning.
  • Data Integration– these include not only the orchestration tools for managing pipelines but also metadata management.
  • Operational Frameworks – these provide scalable frameworks for monitoring & benchmarking.

Architecture Evolution

The modern data architecture is evolving with a goal of reduced latency between data producers and consumers. This consequently is leading to real time and low latency processing, bridging the traditional batch and interactive layers into hybrid architectures like Lambda and Kappa.

  • Lambda - Established architecture for a typical data pipeline. More details.
  • Kappa– An alternative architecture which moves the processing upstream to the Stream layer.
  • SummingBird– a reference model on bridging the online and traditional processing models.

Before you deep dive into the actual layers, here are some general documents which can provide you a great background on NoSQL, Data Warehouse Scale Computing and Distributed Systems.

  • Data center as a computer– provides a great background on warehouse scale computing.
  • NOSQL Data Stores– background on a diverse set of key-value, document and column oriented stores.
  • NoSQL Thesis– great background on distributed systems, first generation NoSQL systems.
  • Large Scale Data Management- covers the data model, the system architecture and the consistency model, ranging from traditional database vendors to new emerging internet-based enterprises.
  • Eventual Consistency– background on the different consistency models for distributed systems.
  • CAP Theorem– a nice background on CAP and its evolution.

There also has been in the past a fierce debate between traditional Parallel DBMS with Map Reduce paradigm of processing. Pro parallel DBMS (another) paper(s) was rebutted by the pro MapReduce one. Ironically the  Hadoop community from then has come full circle with the introduction of MPI style shared nothing based processing on Hadoop - SQL on Hadoop.

File Systems 

As the focus shifts to low latency processing, there is a shift from traditional disk based storage file systems to an  emergence of in memory file systems - which drastically reduces the I/O & disk serialization cost. Tachyon and Spark RDD are examples of that evolution.

File Systems have also seen an evolution on the file formats and compression techniques. The following references gives you a great background on the merits of row and column formats and the shift towards newer nested column oriented formats which are highly efficient for Big Data processing. Erasure codes are using some innovative techniques to reduce the triplication (3 replicas) schemes without compromising data recoverability and availability.

  • Column Oriented vs Row-Stores– good overview of data layout, compression and materialization.
  • RCFile– Hybrid PAX structure which takes the best of both the column and row oriented stores.
  • Parquet– column oriented format first covered in Google’s Dremel’s paper.
  • ORCFile– an improved column oriented format used by Hive.
  • Compression– compression techniques and their comparison on the Hadoop ecosystem.
  • Erasure Codes– background on erasure codes and techniques; improvement on the default triplication on Hadoop to reduce storage cost.

Data Stores

Broadly, the distributed data stores are classified on ACID & BASE stores depending on the continuum of strong to weak consistency respectively. BASE further is classified into KeyValue, Document, Column and Graph - depending on the underlying schema & supported data structure. While there are multitude of systems and offerings in this space, I have covered few of the more prominent ones. I apologize if I have missed a significant one...

BASE
Key Value Stores Dynamo – key-value distributed storage system Cassandra – Inspired by Dynamo; a multi-dimensional key-value/column oriented data store. Voldemort – another one inspired by Dynamo, developed at LinkedIn.
Column Oriented Stores BigTable – seminal paper from Google on distributed column oriented data stores. HBase – while there is no definitive paper , this provides a good overview of the technology. Hypertable – provides a good overview of the architecture.

Document Oriented Stores CouchDB – a popular document oriented data store. MongoDB – a good introduction to MongoDB architecture.

Graph Neo4j – most popular Graph database. Titan – open source Graph database under the Apache license.

ACID I see a lot of evolution happening in the open source community which will try and catch up with what Google has done – 3 out of the prominent papers below are from Google , they have solved the globally distributed consistent data store problem.

Megastore – a highly available distributed consistent database. Uses Bigtable as its storage subsystem. Spanner – Globally distributed synchronously replicated linearizable database which supports SQL access. MESA – provides consistency, high availability, reliability, fault tolerance and scalability for large data and query volumes. CockroachDB – An open source version of Spanner (led by former engineers) in active development.

Resource Managers

While the first generation of Hadoop ecosystem started with monolithic schedulers like YARN, the evolution now is towards hierarchical schedulers (Mesos), that can manage distinct workloads, across different kind of compute workloads, to achieve higher utilization and efficiency.
YARN – The next generation Hadoop compute framework. Mesos – scheduling between multiple diverse cluster computing frameworks.
These are loosely coupled with schedulers whose primary function is schedule jobs based on scheduling policies/configuration. Schedulers Capacity Scheduler- introduction to different features of capacity scheduler.  FairShare Scheduler - introduction to different features of fair scheduler. Delayed Scheduling - introduction to Delayed Scheduling for FairShare scheduler. Fair & Capacity schedulers – a survey of Hadoop schedulers.

Coordination

These are systems that are used for coordination and state management across distributed data systems. Paxos – a simple version of the classical paper; used for distributed systems consensus and coordination.  Chubby – Google’s distributed locking service that implements Paxos. Zookeeper – open source version inspired from Chubby though is general coordination service than simply a locking service

Computational Frameworks

The execution runtimes provide an environment for running distinct kinds of compute. The most common runtimes are

Spark – its popularity and adoption is challenging the traditional Hadoop ecosystem.Flink – very similar to Spark ecosystem; strength over Spark is in iterative processing.
The frameworks broadly can be classified based on the model and latency of processing
Batch MapReduce – The seminal paper from Google on MapReduce. MapReduce Survey – A dated, yet a good paper; survey of Map Reduce frameworks.

Iterative (BSP) Pregel – Google’s paper on large scale graph processing Giraph - large-scale distributed Graph processing system modelled around Pregel GraphX - graph computation framework that unifies graph-parallel and data parallel computation. Hama - general BSP computing engine on top of Hadoop Open source graph processing survey of open source systems modelled around Pregel BSP.

Streaming Stream Processing – A great overview of the distinct real time processing systems  Storm – Real time big data processing system Samza  - stream processing framework from LinkedIn Spark Streaming – introduced the micro batch architecture bridging the traditional batch and interactive processing.

Interactive Dremel – Google’s paper on how it processes interactive big data workloads, which laid the groundwork for multiple open source SQL systems on Hadoop. Impala – MPI style processing on make Hadoop performant for interactive workloads. Drill – A open source implementation of Dremel. Shark – provides a good introduction to the data analysis capabilities on the Spark ecosystem. Shark – another great paper which goes deeper into SQL access. Dryad – Configuring & executing parallel data pipelines using DAG. Tez – open source implementation of Dryad using YARN. BlinkDB - enabling interactive queries over data samples and presenting results annotated with meaningful error bars

RealTime Druid – a real time OLAP data store. Operationalized time series analytics databases Pinot – LinkedIn OLAP data store very similar to Druid.

Data Analysis

The analysis tools range from declarative languages like SQL to procedural languages like Pig. Libraries on the other hand are supporting out of the box implementations of the most common data mining and machine learning libraries.

Tools Pig – Provides a good overview of Pig Latin. Pig – provide an introduction of how to build data pipelines using Pig. Hive – provides an introduction of Hive. Hive – another good paper to understand the motivations behind Hive at Facebook. Phoenix – SQL on Hbase. Join Algorithms for Map Reduce – provides a great introduction to different join algorithms on Hadoop.  Join Algorithms for Map Reduce – another great paper on the different join techniques.

Libraires MLlib – Machine language framework on Spark. SparkR – Distributed R on Spark framework. Mahout – Machine learning framework on traditional Map Reduce.

Data Integration Data integration frameworks provide good mechanisms to ingest and outgest data between Big Data systems. It ranges from orchestration pipelines to metadata framework with support for lifecycle management and governance.

Ingest/Messaging Flume – a framework for collecting, aggregating and moving large amounts of log data from many different sources to a centralized data store. Sqoop– a tool to move data between Hadoop and Relational data stores. Kafka – distributed messaging system for data processing

ETL/Workflow Crunch – library for writing, testing, and running MapReduce pipelines. Falcon – data management framework that helps automate movement and processing of Big Data. Cascading – data manipulation through scripting. Oozie – a workflow scheduler system to manage Hadoop jobs.

Metadata HCatalog - a table and storage management layer for Hadoop.

Serialization ProtocolBuffers – language neutral serialization format popularized by Google. Avro – modeled around Protocol Buffers for the Hadoop ecosystem.

Operational Frameworks

Finally the operational frameworks provide capabilities for metrics, benchmarking and performance optimization to manage workloads.

Monitoring Frameworks OpenTSDB – a time series metrics systems built on top of HBase. Ambari - system for collecting, aggregating and serving Hadoop and system metrics

Benchmarking YCSB – performance evaluation of NoSQL systems. GridMix – provides benchmark for Hadoop workloads by running a mix of synthetic jobs Background on big data benchmarking with the key challenges associated.

Summary

I hope that the papers are useful as you embark or strengthen your journey. I am sure there are few hundred more papers that I might have inadvertently missed and a whole bunch of systems that  I might be unfamiliar with - apologies in advance as don‘t mean to offend anyone though happy to be educated....

时间: 2024-10-29 19:11:06

100 open source Big Data architecture papers for data professionals的相关文章

Android App data write as file data with synchronous Demo

1 package com.android.utils; 2 3 import java.io.File; 4 import java.io.IOException; 5 import java.io.RandomAccessFile; 6 import java.util.Arrays; 7 8 import android.app.Activity; 9 import android.util.Log; 10 11 12 /** 13 * 在一些对数据实时性要求比较高的场合,如随时可能断电的

错误描述:请求“System.Data.SqlClient.SqlClientPermission, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089”类型的权限已失败

错误描述:请求“System.Data.SqlClient.SqlClientPermission, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089”类型的权限已失败. 解决办法:在配置文件web.config中<trust></trust>节点,把<trust level="WSS_Minimal" originUrl=""

混合 Data Warehouse 和 Big Data 倉庫的新架構

(讀書筆記)許多公司,儘管想導入 Big Data,仍必須繼續用 Data Warehouse 來管理結構化的營運數據.系統記錄.而 Big Data 的出現,為 Data Warehouse 提供了一個互補的機會,而不是取代後者. 高度結構化的營運資料 (data,數據),仍然可保留在 Data Warehouse 中:而分散式 (distributed) 的資料,以及會即時改變的資料,則可交由基於 Hadoop 的架構來控制. 圖 1 傳統的 Data Warehouse 和 Data Ma

jQuery.data() 与 jQuery(elem).data()源码解读

之前一直以为 jQuery(elem).data()是在内部调用了 jQuery.data(),看了代码后发现不是.但是这两个还是需要放在一起看,因为它们内部都使用了jQuery的数据缓存机制.好吧,重点就是data_user对象,跟另一个data_priv是姐妹~~ 先来看下jQuery.data(): 它调用了data_user.access( elem, name, data ); 那么data_user到底是什么鬼呢?? 我们看到,它是由Data构造的实例,Data构造器都做了一些什么呢

Mysql text类型字段存储提示错误信息 String data,right truncated:1406 Data too long for column &#39;content&#39; at row 1

String data,right truncated:1406 Data too long for column 'content' at row 1 当Mysql提示如下时: 1.首先查看存入的文本内容的大小,根据内容大小设置类型 如果超出,根据大小进行更换类型 2.如果还是超出那可能是Mysql根据配置文件限制Server接受数据包大小,有时候大的插入和更新会受max_allowed_packet参数限制,导致写入或者更新失败. 查看目前配置: 代码如下: 以上说明目前的配置是:60 M

编译器错误消息: CS0122: “System.Data.DataRow.DataRow(System.Data.DataRowBuilder)”不可访问,因为它受保护级别限制

编译错误 说明: 在编译向该请求提供服务所需资源的过程中出现错误.请检查下列特定错误详细信息并适当地修改源代码. 编译器错误消息: CS0122: "System.Data.DataRow.DataRow(System.Data.DataRowBuilder)"不可访问,因为它受保护级别限制 源错误:   行 17: 行 18: DataTable dt = new DataTable(); 行 19: System.Data.DataRow r = new DataRow(); 行

System.Data.DataRow.DataRow(System.Data.DataRowBuilder 因为它受保护级别限制 如何解决,解决办法

错误 1 "System.Data.DataRow.DataRow(System.Data.DataRowBuilder)"不可访问,因为它受保护级别限制 原因:DataRow dr= new DataRow();    // 错误,DataRow 不能直接new 解决办法: DataRow dr :或者,使用DataTable dt = new DataTable(); //对应的行,使用dt[],例如第一行  dt[0]

jquery data属性 attr vs data

html5的自定义data属性相信大家都不会陌生,有了它你可以绑定所需的数据到指定元素上.然后通过jquery设置.获取数据,简直开心的不行啊.想到设置.获取元素属性值,大家一定首先想到了jquery的.attr()方法,但是你一定知道jquery还有个.data()的方法.本人以前一直萌(傻)萌(傻)哒(的)以为这两个方法在处理data属性过程中实现的效果是一样的,只不过.data()方法官方更推荐使用(看名字就感觉人家是正规军).但后来本人在做项目的过程中发现,这两种方法处理data属性并不

System.Data.Dbtype转换为System.Data.SqlDbType

最近在做一些OM Mapping的准备工作,新学了一招. 如果要将System.Data.Dbtype转换为System.Data.SqlDbType,以前以为要写Switch Case语句.其实有很简单的方法: ??????? private System.Data.SqlDbType ConvertToSqlDbType(System.Data.DbType pSourceType)??????? {??????????? SqlParameter paraConver = new SqlP