Apache Iceberg - A Table Format for Hige Analytic DatasetsAlluxio, Inc.
Data Orchestration Summit
www.alluxio.io/data-orchestration-summit-2019
November 7, 2019
Apache Iceberg - A Table Format for Hige Analytic Datasets
Speaker:
Ryan Blue, Netflix
For more Alluxio events: https://www.alluxio.io/events/
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안SANG WON PARK
Apache Kafak의 빅데이터 아키텍처에서 역할이 점차 커지고, 중요한 비중을 차지하게 되면서, 성능에 대한 고민도 늘어나고 있다.
다양한 프로젝트를 진행하면서 Apache Kafka를 모니터링 하기 위해 필요한 Metrics들을 이해하고, 이를 최적화 하기 위한 Configruation 설정을 정리해 보았다.
[Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안]
Apache Kafka 성능 모니터링에 필요한 metrics에 대해 이해하고, 4가지 관점(처리량, 지연, Durability, 가용성)에서 성능을 최적화 하는 방안을 정리함. Kafka를 구성하는 3개 모듈(Producer, Broker, Consumer)별로 성능 최적화를 위한 …
[Apache Kafka 모니터링을 위한 Metrics 이해]
Apache Kafka의 상태를 모니터링 하기 위해서는 4개(System(OS), Producer, Broker, Consumer)에서 발생하는 metrics들을 살펴봐야 한다.
이번 글에서는 JVM에서 제공하는 JMX metrics를 중심으로 producer/broker/consumer의 지표를 정리하였다.
모든 지표를 정리하진 않았고, 내 관점에서 유의미한 지표들을 중심으로 이해한 내용임
[Apache Kafka 성능 Configuration 최적화]
성능목표를 4개로 구분(Throughtput, Latency, Durability, Avalibility)하고, 각 목표에 따라 어떤 Kafka configuration의 조정을 어떻게 해야하는지 정리하였다.
튜닝한 파라미터를 적용한 후, 성능테스트를 수행하면서 추출된 Metrics를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
This talk delves into the many ways that a user has to use HBase in a project. Lars will look at many practical examples based on real applications in production, for example, on Facebook and eBay and the right approach for those wanting to find their own implementation. He will also discuss advanced concepts, such as counters, coprocessors and schema design.
Apache Iceberg - A Table Format for Hige Analytic DatasetsAlluxio, Inc.
Data Orchestration Summit
www.alluxio.io/data-orchestration-summit-2019
November 7, 2019
Apache Iceberg - A Table Format for Hige Analytic Datasets
Speaker:
Ryan Blue, Netflix
For more Alluxio events: https://www.alluxio.io/events/
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안SANG WON PARK
Apache Kafak의 빅데이터 아키텍처에서 역할이 점차 커지고, 중요한 비중을 차지하게 되면서, 성능에 대한 고민도 늘어나고 있다.
다양한 프로젝트를 진행하면서 Apache Kafka를 모니터링 하기 위해 필요한 Metrics들을 이해하고, 이를 최적화 하기 위한 Configruation 설정을 정리해 보았다.
[Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안]
Apache Kafka 성능 모니터링에 필요한 metrics에 대해 이해하고, 4가지 관점(처리량, 지연, Durability, 가용성)에서 성능을 최적화 하는 방안을 정리함. Kafka를 구성하는 3개 모듈(Producer, Broker, Consumer)별로 성능 최적화를 위한 …
[Apache Kafka 모니터링을 위한 Metrics 이해]
Apache Kafka의 상태를 모니터링 하기 위해서는 4개(System(OS), Producer, Broker, Consumer)에서 발생하는 metrics들을 살펴봐야 한다.
이번 글에서는 JVM에서 제공하는 JMX metrics를 중심으로 producer/broker/consumer의 지표를 정리하였다.
모든 지표를 정리하진 않았고, 내 관점에서 유의미한 지표들을 중심으로 이해한 내용임
[Apache Kafka 성능 Configuration 최적화]
성능목표를 4개로 구분(Throughtput, Latency, Durability, Avalibility)하고, 각 목표에 따라 어떤 Kafka configuration의 조정을 어떻게 해야하는지 정리하였다.
튜닝한 파라미터를 적용한 후, 성능테스트를 수행하면서 추출된 Metrics를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
This talk delves into the many ways that a user has to use HBase in a project. Lars will look at many practical examples based on real applications in production, for example, on Facebook and eBay and the right approach for those wanting to find their own implementation. He will also discuss advanced concepts, such as counters, coprocessors and schema design.
Communication between Microservices is inherently unreliable. These integration points may produce cascading failures, slow responses, service outages. We will walk through stability patterns like timeouts, circuit breaker, bulkheads and discuss how they improve stability of Microservices.
Cloud dw benchmark using tpd-ds( Snowflake vs Redshift vs EMR Hive )SANG WON PARK
몇년 전부터 Data Architecture의 변화가 빠르게 진행되고 있고,
그 중 Cloud DW는 기존 Data Lake(Hadoop 기반)의 한계(성능, 비용, 운영 등)에 대한 대안으로 주목받으며,
많은 기업들이 이미 도입했거나, 도입을 검토하고 있다.
본 자료는 이러한 Cloud DW에 대해서 개념적으로 이해하고,
시장에 존재하는 다양한 Cloud DW 중에서 기업의 환경에 맞는 제품이 어떤 것인지 성능/비용 관점으로 비교했다.
- 왜기업들은 CloudDW에주목하는가?
- 시장에는어떤 제품들이 있는가?
- 우리Biz환경에서는 어떤 제품을 도입해야 하는가?
- CloudDW솔루션의 성능은?
- 기존DataLake(EMR)대비 성능은?
- 유사CloudDW(snowflake vs redshift) 대비성능은?
앞으로도 Data를 둘러싼 시장은 Cloud DW를 기반으로 ELT, Mata Mesh, Reverse ETL등 새로운 생테계가 급속하게 발전할 것이고,
이를 위한 데이터 엔지니어/데이터 아키텍트 관점의 기술적 검토와 고민이 필요할 것 같다.
https://blog.naver.com/freepsw/222654809552
데이터를 둘러싼 정책과, 기업과 기술의 진화는 빠르게 변화하고 있으며, 모든 지향점은 기업들이 다양한 데이터를 활용하여 경쟁력을 확보하고 이를 통해 AI기반의 혁신을 하고자 하는데 있다.
이 과정에서 수 많은 기업의 업무 전무가, 데이터 사이언티스트 등이 다양한 기업의 혁신을 지원할 수 있는 AI 모델을 검증하는 과정을 거치게 됩니다.
하지만, 이렇게 수 많은 AI 모델이 실제 비즈니스에 적용되기 위해서는 인프라, 및 서비스 관점의 기술이 반드시 필요하게 됩니다.
MLOps는 기업에 필요한 혁신적인 아이디어(AI Model)을 적시에 비즈니스 환경에 적용할 수 있도록 지원하는 기술 및 트렌드 입니다.
주요 내용은
- 데이터를 둘러싼 환경의 변화
- 기업의 AI Model 적용시 마주하는 현실
- MLOps가 해결 가능한 문제들
- MLOps의 영역별 주요 기술들
- MLOps 도입 시 기업의 AI 환경은 어떻게 변할까?
- AI 모델을 비즈니스 환경에 적용(배포)한다는 것은?
2021년 12월 코리아 데이터 비즈니스 트렌드(데이터산업진흥원 주최)에서 발표한 내용을 공유 가능한 부분만 정리함.
발표 영상 참고 : https://www.youtube.com/watch?v=lL-QtEzJ3WY
HBase hast established itself as the backend for many operational and interactive use-cases, powering well-known services that support millions of users and thousands of concurrent requests. In terms of features HBase has come a long way, overing advanced options such as multi-level caching on- and off-heap, pluggable request handling, fast recovery options such as region replicas, table snapshots for data governance, tuneable write-ahead logging and so on. This talk is based on the research for the an upcoming second release of the speakers HBase book, correlated with the practical experience in medium to large HBase projects around the world. You will learn how to plan for HBase, starting with the selection of the matching use-cases, to determining the number of servers needed, leading into performance tuning options. There is no reason to be afraid of using HBase, but knowing its basic premises and technical choices will make using it much more successful. You will also learn about many of the new features of HBase up to version 1.3, and where they are applicable.
Performance Optimizations in Apache ImpalaCloudera, Inc.
Apache Impala is a modern, open-source MPP SQL engine architected from the ground up for the Hadoop data processing environment. Impala provides low latency and high concurrency for BI/analytic read-mostly queries on Hadoop, not delivered by batch frameworks such as Hive or SPARK. Impala is written from the ground up in C++ and Java. It maintains Hadoop’s flexibility by utilizing standard components (HDFS, HBase, Metastore, Sentry) and is able to read the majority of the widely-used file formats (e.g. Parquet, Avro, RCFile).
To reduce latency, such as that incurred from utilizing MapReduce or by reading data remotely, Impala implements a distributed architecture based on daemon processes that are responsible for all aspects of query execution and that run on the same machines as the rest of the Hadoop infrastructure. Impala employs runtime code generation using LLVM in order to improve execution times and uses static and dynamic partition pruning to significantly reduce the amount of data accessed. The result is performance that is on par or exceeds that of commercial MPP analytic DBMSs, depending on the particular workload. Although initially designed for running on-premises against HDFS-stored data, Impala can also run on public clouds and access data stored in various storage engines such as object stores (e.g. AWS S3), Apache Kudu and HBase. In this talk, we present Impala's architecture in detail and discuss the integration with different storage engines and the cloud.
3 Things to Learn About:
-How Kudu is able to fill the analytic gap between HDFS and Apache HBase
-The trade-offs between real-time transactional access and fast analytic performance
-How Kudu provides an option to achieve fast scans and random access from a single API
Spark 의 핵심은 무엇인가? RDD! (RDD paper review)Yongho Ha
요즘 Hadoop 보다 더 뜨고 있는 Spark.
그 Spark의 핵심을 이해하기 위해서는 핵심 자료구조인 Resilient Distributed Datasets (RDD)를 이해하는 것이 필요합니다.
RDD가 어떻게 동작하는지, 원 논문을 리뷰하며 살펴보도록 합시다.
http://www.cs.berkeley.edu/~matei/papers/2012/sigmod_shark_demo.pdf
Amazon S3 Best Practice and Tuning for Hadoop/Spark in the CloudNoritaka Sekiyama
Amazon S3 Best Practice and Tuning for Hadoop/Spark in the Cloud (Hadoop / Spark Conference Japan 2019)
# English version #
http://hadoop.apache.jp/hcj2019-program/
Druid and Hive Together : Use Cases and Best PracticesDataWorks Summit
Two popular open source technologies, Druid and Apache Hive, are often mentioned as viable solutions for large-scale analytics. Hive works well for storing large volumes of data, although not optimized for ingesting streaming data and making it available for queries in realtime. On the other hand, Druid excels at low-latency, interactive queries over streaming data and making data available in realtime for queries. Although the high level messaging presented by both projects may lead you to believe they are competing for same use case, the technologies are in fact extremely complementary solutions.
By combining the rich query capabilities of Hive with the powerful realtime streaming and indexing capabilities of Druid, we can build more powerful, flexible, and extremely low latency realtime streaming analytics solutions. In this talk we will discuss the motivation to combine Hive and Druid together alongwith the benefits, use cases, best practices and benchmark numbers.
The Agenda of the talk will be -
1. Motivation behind integrating Druid with Hive
2. Druid and Hive together - benefits
3. Use Cases with Demos and architecture discussion
4. Best Practices - Do's and Don'ts
5. Performance vs Cost Tradeoffs
6. SSB Benchmark Numbers
Running Airflow Workflows as ETL Processes on Hadoopclairvoyantllc
While working with Hadoop, you'll eventually encounter the need to schedule and run workflows to perform various operations like ingesting data or performing ETL. There are a number of tools available to assist you with this type of requirement and one such tool that we at Clairvoyant have been looking to use is Apache Airflow. Apache Airflow is an Apache Incubator project that allows you to programmatically create workflows through a python script. This provides a flexible and effective way to design your workflows with little code and setup. In this talk, we will discuss Apache Airflow and how we at Clairvoyant have utilized it for ETL pipelines on Hadoop.
한빛데브그라운드에서 발표했던 내용입니다.
발표 영상 : https://youtu.be/ohpfSLf0V3Y
--
스타트업 비즈니스에서 데이터를 활용한 전략 수립과 의사결정은 필수적인 요소입니다. 서비스 운영 데이터에서부터 다양한 고객의 행동 로그, 소셜 미디어 데이터까지 다양한 데이터를 모두 모아 분석 환경을 구축하기 위해서는 많은 준비와 고민이 필요합니다. 스타트업에서 빠른 속도와 최소한의 비용, 다양한 분석 Tool들과 연동되는 Data Pipeline, Data Lake, Data Warehouse 구축 경험기를 공유하고자 합니다. 이 과정을 통해 애널리틱스 파이프라인을 구축 과정과 S3, Glue, Athena,EMR, Quicksight와 같은 서버리스 애널리틱스 서비스에 대한 구축 사례를 확인하실 수 있습니다.
Apache kafka performance(latency)_benchmark_v0.3SANG WON PARK
Apache Kafka를 이용하여 이미지 데이터를 얼마나 빠르게(with low latency) 전달 가능한지 성능 테스트.
최종 목적은 AI(ML/DL) 모델의 입력으로 대량의 실시간 영상/이미지 데이터를 전달하는 메세지 큐로 사용하기 위하여, Drone/제조공정 등의 장비에서 전송된 이미지를 얼마나 빨리 AI Model로 전달 할 수 있는지 확인하기 위함.
그래서 Kafka에서 이미지를 전송하는 간단한 테스트를 진행하였고,
이 과정에서 latency를 얼마나 줄여주는지를 확인해 보았다.(HTTP 프로토콜/Socket과 비교하여)
[현재 까지 결론]
- Apache Kafka는 대량의 요청 처리를 위한 throughtput에 최적화 된 솔루션임.
- 현재는 producer의 몇가지 옵션만 조정하여 테스트한 결과이므로,
- 잠정적인 결과이지만, kafka의 latency를 향상을 위해서는 많은 시도가 필요할 것 같음.
- 즉, 단일 요청의 latency는 확실히 느리지만,
- 대량의 처리를 기준으로 평균 latency를 비교하면 평균적인 latency는 많이 낮아짐.
Test Code : https://github.com/freepsw/kafka-latency-test
Communication between Microservices is inherently unreliable. These integration points may produce cascading failures, slow responses, service outages. We will walk through stability patterns like timeouts, circuit breaker, bulkheads and discuss how they improve stability of Microservices.
Cloud dw benchmark using tpd-ds( Snowflake vs Redshift vs EMR Hive )SANG WON PARK
몇년 전부터 Data Architecture의 변화가 빠르게 진행되고 있고,
그 중 Cloud DW는 기존 Data Lake(Hadoop 기반)의 한계(성능, 비용, 운영 등)에 대한 대안으로 주목받으며,
많은 기업들이 이미 도입했거나, 도입을 검토하고 있다.
본 자료는 이러한 Cloud DW에 대해서 개념적으로 이해하고,
시장에 존재하는 다양한 Cloud DW 중에서 기업의 환경에 맞는 제품이 어떤 것인지 성능/비용 관점으로 비교했다.
- 왜기업들은 CloudDW에주목하는가?
- 시장에는어떤 제품들이 있는가?
- 우리Biz환경에서는 어떤 제품을 도입해야 하는가?
- CloudDW솔루션의 성능은?
- 기존DataLake(EMR)대비 성능은?
- 유사CloudDW(snowflake vs redshift) 대비성능은?
앞으로도 Data를 둘러싼 시장은 Cloud DW를 기반으로 ELT, Mata Mesh, Reverse ETL등 새로운 생테계가 급속하게 발전할 것이고,
이를 위한 데이터 엔지니어/데이터 아키텍트 관점의 기술적 검토와 고민이 필요할 것 같다.
https://blog.naver.com/freepsw/222654809552
데이터를 둘러싼 정책과, 기업과 기술의 진화는 빠르게 변화하고 있으며, 모든 지향점은 기업들이 다양한 데이터를 활용하여 경쟁력을 확보하고 이를 통해 AI기반의 혁신을 하고자 하는데 있다.
이 과정에서 수 많은 기업의 업무 전무가, 데이터 사이언티스트 등이 다양한 기업의 혁신을 지원할 수 있는 AI 모델을 검증하는 과정을 거치게 됩니다.
하지만, 이렇게 수 많은 AI 모델이 실제 비즈니스에 적용되기 위해서는 인프라, 및 서비스 관점의 기술이 반드시 필요하게 됩니다.
MLOps는 기업에 필요한 혁신적인 아이디어(AI Model)을 적시에 비즈니스 환경에 적용할 수 있도록 지원하는 기술 및 트렌드 입니다.
주요 내용은
- 데이터를 둘러싼 환경의 변화
- 기업의 AI Model 적용시 마주하는 현실
- MLOps가 해결 가능한 문제들
- MLOps의 영역별 주요 기술들
- MLOps 도입 시 기업의 AI 환경은 어떻게 변할까?
- AI 모델을 비즈니스 환경에 적용(배포)한다는 것은?
2021년 12월 코리아 데이터 비즈니스 트렌드(데이터산업진흥원 주최)에서 발표한 내용을 공유 가능한 부분만 정리함.
발표 영상 참고 : https://www.youtube.com/watch?v=lL-QtEzJ3WY
HBase hast established itself as the backend for many operational and interactive use-cases, powering well-known services that support millions of users and thousands of concurrent requests. In terms of features HBase has come a long way, overing advanced options such as multi-level caching on- and off-heap, pluggable request handling, fast recovery options such as region replicas, table snapshots for data governance, tuneable write-ahead logging and so on. This talk is based on the research for the an upcoming second release of the speakers HBase book, correlated with the practical experience in medium to large HBase projects around the world. You will learn how to plan for HBase, starting with the selection of the matching use-cases, to determining the number of servers needed, leading into performance tuning options. There is no reason to be afraid of using HBase, but knowing its basic premises and technical choices will make using it much more successful. You will also learn about many of the new features of HBase up to version 1.3, and where they are applicable.
Performance Optimizations in Apache ImpalaCloudera, Inc.
Apache Impala is a modern, open-source MPP SQL engine architected from the ground up for the Hadoop data processing environment. Impala provides low latency and high concurrency for BI/analytic read-mostly queries on Hadoop, not delivered by batch frameworks such as Hive or SPARK. Impala is written from the ground up in C++ and Java. It maintains Hadoop’s flexibility by utilizing standard components (HDFS, HBase, Metastore, Sentry) and is able to read the majority of the widely-used file formats (e.g. Parquet, Avro, RCFile).
To reduce latency, such as that incurred from utilizing MapReduce or by reading data remotely, Impala implements a distributed architecture based on daemon processes that are responsible for all aspects of query execution and that run on the same machines as the rest of the Hadoop infrastructure. Impala employs runtime code generation using LLVM in order to improve execution times and uses static and dynamic partition pruning to significantly reduce the amount of data accessed. The result is performance that is on par or exceeds that of commercial MPP analytic DBMSs, depending on the particular workload. Although initially designed for running on-premises against HDFS-stored data, Impala can also run on public clouds and access data stored in various storage engines such as object stores (e.g. AWS S3), Apache Kudu and HBase. In this talk, we present Impala's architecture in detail and discuss the integration with different storage engines and the cloud.
3 Things to Learn About:
-How Kudu is able to fill the analytic gap between HDFS and Apache HBase
-The trade-offs between real-time transactional access and fast analytic performance
-How Kudu provides an option to achieve fast scans and random access from a single API
Spark 의 핵심은 무엇인가? RDD! (RDD paper review)Yongho Ha
요즘 Hadoop 보다 더 뜨고 있는 Spark.
그 Spark의 핵심을 이해하기 위해서는 핵심 자료구조인 Resilient Distributed Datasets (RDD)를 이해하는 것이 필요합니다.
RDD가 어떻게 동작하는지, 원 논문을 리뷰하며 살펴보도록 합시다.
http://www.cs.berkeley.edu/~matei/papers/2012/sigmod_shark_demo.pdf
Amazon S3 Best Practice and Tuning for Hadoop/Spark in the CloudNoritaka Sekiyama
Amazon S3 Best Practice and Tuning for Hadoop/Spark in the Cloud (Hadoop / Spark Conference Japan 2019)
# English version #
http://hadoop.apache.jp/hcj2019-program/
Druid and Hive Together : Use Cases and Best PracticesDataWorks Summit
Two popular open source technologies, Druid and Apache Hive, are often mentioned as viable solutions for large-scale analytics. Hive works well for storing large volumes of data, although not optimized for ingesting streaming data and making it available for queries in realtime. On the other hand, Druid excels at low-latency, interactive queries over streaming data and making data available in realtime for queries. Although the high level messaging presented by both projects may lead you to believe they are competing for same use case, the technologies are in fact extremely complementary solutions.
By combining the rich query capabilities of Hive with the powerful realtime streaming and indexing capabilities of Druid, we can build more powerful, flexible, and extremely low latency realtime streaming analytics solutions. In this talk we will discuss the motivation to combine Hive and Druid together alongwith the benefits, use cases, best practices and benchmark numbers.
The Agenda of the talk will be -
1. Motivation behind integrating Druid with Hive
2. Druid and Hive together - benefits
3. Use Cases with Demos and architecture discussion
4. Best Practices - Do's and Don'ts
5. Performance vs Cost Tradeoffs
6. SSB Benchmark Numbers
Running Airflow Workflows as ETL Processes on Hadoopclairvoyantllc
While working with Hadoop, you'll eventually encounter the need to schedule and run workflows to perform various operations like ingesting data or performing ETL. There are a number of tools available to assist you with this type of requirement and one such tool that we at Clairvoyant have been looking to use is Apache Airflow. Apache Airflow is an Apache Incubator project that allows you to programmatically create workflows through a python script. This provides a flexible and effective way to design your workflows with little code and setup. In this talk, we will discuss Apache Airflow and how we at Clairvoyant have utilized it for ETL pipelines on Hadoop.
한빛데브그라운드에서 발표했던 내용입니다.
발표 영상 : https://youtu.be/ohpfSLf0V3Y
--
스타트업 비즈니스에서 데이터를 활용한 전략 수립과 의사결정은 필수적인 요소입니다. 서비스 운영 데이터에서부터 다양한 고객의 행동 로그, 소셜 미디어 데이터까지 다양한 데이터를 모두 모아 분석 환경을 구축하기 위해서는 많은 준비와 고민이 필요합니다. 스타트업에서 빠른 속도와 최소한의 비용, 다양한 분석 Tool들과 연동되는 Data Pipeline, Data Lake, Data Warehouse 구축 경험기를 공유하고자 합니다. 이 과정을 통해 애널리틱스 파이프라인을 구축 과정과 S3, Glue, Athena,EMR, Quicksight와 같은 서버리스 애널리틱스 서비스에 대한 구축 사례를 확인하실 수 있습니다.
Apache kafka performance(latency)_benchmark_v0.3SANG WON PARK
Apache Kafka를 이용하여 이미지 데이터를 얼마나 빠르게(with low latency) 전달 가능한지 성능 테스트.
최종 목적은 AI(ML/DL) 모델의 입력으로 대량의 실시간 영상/이미지 데이터를 전달하는 메세지 큐로 사용하기 위하여, Drone/제조공정 등의 장비에서 전송된 이미지를 얼마나 빨리 AI Model로 전달 할 수 있는지 확인하기 위함.
그래서 Kafka에서 이미지를 전송하는 간단한 테스트를 진행하였고,
이 과정에서 latency를 얼마나 줄여주는지를 확인해 보았다.(HTTP 프로토콜/Socket과 비교하여)
[현재 까지 결론]
- Apache Kafka는 대량의 요청 처리를 위한 throughtput에 최적화 된 솔루션임.
- 현재는 producer의 몇가지 옵션만 조정하여 테스트한 결과이므로,
- 잠정적인 결과이지만, kafka의 latency를 향상을 위해서는 많은 시도가 필요할 것 같음.
- 즉, 단일 요청의 latency는 확실히 느리지만,
- 대량의 처리를 기준으로 평균 latency를 비교하면 평균적인 latency는 많이 낮아짐.
Test Code : https://github.com/freepsw/kafka-latency-test
이 발표는 [야생의 땅: 듀랑고]의 지형 배포 시스템과 생태계 시뮬레이션 자동화 시스템에 대한 이야기를 다룹니다. 듀랑고의 각 섬은 크기와 지형, 기후 조건이 다양하고 섬의 개수가 많아서 수동으로 관리하는 것은 사실상 불가능합니다. 몇번의 사내 테스트와 베타 테스트를 거치면서 이러한 문제를 해결해주는 자동화된 도구의 필요성이 절실해졌고, 작년에 NDC에서 발표했던 생태계 시뮬레이터와 Docker, 그리고 아마존 웹서비스(AWS)를 이용하여 수많은 섬들을 자동으로 생성하고 관리하는 자동화 시스템을 구축하게 되었습니다. 그 과정에서 했던 고민들, 기존의 애플리케이션을 "Dockerizing" 했던 경험, AWS의 각 서비스들을 적절히 활용했던 이야기, AWS의 각 지역별 요금이 상이하다는 점을 이용해서 비용을 절감한 사례, 그리고 자동화 시스템의 문제점과 앞으로의 방향에 대해서 이야기 할 계획입니다.
26. 스토리지 측면
• 3 Copy (기본 옵션)
• 같은 랙에 하나, 다른 랙에 하나
• 64mb 블록
• 파일을 64mb 블록으로 나눠서 저장
• namenode 에서 각 파일 블록을 관리한다. (속도 위해 In-momory 관리)
• namenode 장애에 매우 취약하다.
• namenode 메모리가 매우 중요하다.
• 작은 크기의 매우 많은 파일에 매우 취약하다.
• secondary namenode 는 그냥 grace 종료를 위한 용도이다.
39. PIG
• 맵리듀스는 분석가가 만들기 어렵다.
• 하지만 보통 데이터 분석은 몇가지 기능만 사용된다.
• 그럼 기능을 스크립트로 제공하고 스크립트를 해석해서 맵리듀스 코드를 생성해서 돌리자
• 전용 스크립트 PigLatin 을 사용
• 스크립트를 분석해서 맵리듀스 코드 생성
• 코드를 하둡에 올리고 돌려서 결과 생성
40. 확 줄었다
데이터 로드
c = load '/user/bdh/data27/cite.TXT' using PigStorage(',') as (c1:int, c2:int);
/** 카운트를 위한 컬럼 그룹화 */
g = group c by c1, c2;
/** group 데이터 수를 카운트 */
f = foreach g generate flatten(group), COUNT($1) as cnt;
/** 결과를 확인해 볼 수 있다. */
L = limit f 10;
Dump L;
41. HIVE
• 전용 스크립트를 분석해서 맵리듀스를 생성하는 건 같다.
• 하지만 그 과정이 별도 테이블을 정의하고 SQL Query 를 통해서 분석 결과를 뽑고 결
과를 다시 테이블 형태로 저장 가능
• 멋있어 보이지만, 생각만큼 만만한 얘는 아니다.
42. 테이블 생성
create external table cite (
citing int , cited int
)row format delimited fields terminated by ',' lines terminated by 'n'
stored as textfile;
로컬데이터로드
load data local inpath '/home/bdh/data/cite.TXT' overwrite into table cite;
카운팅
select citing, count(citing) from cite group by citing limit 100;
43. HBASE
• 하둡의 심장!
• 이거 때문에라도 하둡을 써야 한다.
• 구글의 빅테이블을 구현한 데이터베이스 (하둡 생태계에서 유일한 스토리지)
• 컬럼 베이스 형태의 NoSQL DB(카산드라와 같다)
• RDBMS 랑 구조와 완전히 다르다 (DB 라는 생각을 버려야 한다)
• 하둡의 작은 파일에 대한 취약점을 극복
44. • 컬럼 패밀리를 미리 정의하고 컬럼패밀리 내의 컬럼은 무한히 증가될 수 있는 구조
• 각 컬럼 별 타임스태프로 버전관리가 된다.
• RowKey 를 통한 랜덤억세스에 특화되어 있다.
• Full Scan 은 뭘해도 느리다 (복잡한 문제를 한방에 푸는 방법은 없다.)
• 그래도 싱글머신에서 돌리는 것보단 훨 빠르다.
HBASE
45. HBASE 의 데이터 구조
• • 테이블 (Table)
• 로우(Row)들의 집합. - 각 로우는 로우키(Row Key)가있으며 다수의 컬럼패밀리로 구성됨 - 스키마 정의시 컬럼패
밀리(Column Family)만 정의
• • 로우키(Row Key)
• 임의의바이트열, 사전순으로 내림차순 정렬 - 빈바이트 문자열은 테이블의 시작과 끝을 의미
• • 컬럼패밀리 (Column Family)
• 컬럼들의그룹이며, 컬럼패밀리의 멤버컬럼은 같은접두사(prefix) - course:history와 course:math는
course라는 컬럼패밀리의 멤버컬럼임. history와 math를 컬럼 Qualifier라고 함
• • 셀(Cell)
• 로우키& 컬럼& 버전이 명시된 튜플 - 값은 임의의 바이트열이며 Timestamp가있음 StumbleUpon의
HBase의 선택 이유
46.
47. HBASE 의 특징
• 컬럼패밀리만 사전에 정의하고 컬럼은 무한정 늘어날 수 있다.
• RowKey 는 바이너리로 저장된다.
• 저장은 Cell 단위로 저장된다.
• 하나의 Cell 이 타임스탬프로 여러 버전이 저장될 수 있다.
• RowKey 로 엑세스가 빠르다.
• Query 문을 지원하지 않는다 (Get, Put, Del 등만 지원)
48. ZOOKEEPER
• 여러개의 머신에서 데이터를 동기화해주는 툴
• 머신을 죽었을 때 자동으로 리더를 새로 선출해서 결정한다.
• HBase 등의 다른 시스템에서 공유 데이터를 관리하기 위해서 사용한다.
• 굉장히 좋은 툴로, 비슷한 기능이 요구될 때 별도로 사용 가능해 보인다.
49. FLUME
• 로그 수집기
• 로그가 발생되는 머신에 Agent 를 띄운다.
• 로그는 Source – Channel – Sink 를 거치며 저장된다.
• Agent 는 다시 다른 Agent 로 연결될 수 있다.
• 최종적으로 HBase 와 같은 DB 에 저장된다.
50.
51. SKOOP
• 외부 DB 에서 하둡으로 데이터를 옮겨준다 (ETL 툴)
• JDBC 를 제공하는 모든 DB 에서 테이블 구조를 읽어서
• 데이터를 옮기는 맵리듀스 코드를 생성해주고
• 해당 코드를 실행함으로써 옮긴다.
• 주로 배치 잡으로 일정 간격으로 외부 DB 에서 데이터를 긁어오는데 사용
56. 데이터 적재
• Flume 을 이용해서 로그 데이터를 실시간으로 쌓거나
• Sqoop 을 이용해서 일정 간격으로 외부 DB 에서 데이터를 긁어서 적재한다.
• 일반적으로 적재는 HBase 를 이용한다.
57. 데이터 분석
• Hive 를 이용해서 데이터를 샘플링하고
• 샘플링 데이터를 데이터 분석가에게 넘겨서 R 을 이용해서 데이터 분석 모
델링을 만든다.
• 분석 모델링을 가지고 맵리듀스 스크립트를 만든다 (수동)
• 배치 잡으로 일정 간격 맵리듀스 스크립트를 만들어 결과를 생성한다.
• 생성한 결과를 외부 DB 에 저장한다.
