scalable data store and analy cs pla1orm for monitoring
play

Scalable data store and analy/cs pla1orm for monitoring - PowerPoint PPT Presentation

Scalable data store and analy/cs pla1orm for monitoring WLCG, a distributed data-intensive scien/fic infrastructure Uthay Suthakar Brunel University


  1. Scalable ¡data ¡store ¡and ¡analy/cs ¡pla1orm ¡for ¡monitoring ¡WLCG, ¡ ¡ ¡a ¡distributed ¡data-­‑intensive ¡scien/fic ¡infrastructure ¡ ¡ Uthay ¡Suthakar ¡ Brunel ¡University ¡ eepguus@brunel.ac.uk ¡

  2. Topics • Introduc/on ¡to ¡current ¡architecture ¡ • Proposed ¡architecture ¡ ¡ • Lambda ¡architecture ¡ • Review ¡of ¡technologies ¡

  3. Current ¡architecture: • Robust ¡architecture. ¡ • It ¡does ¡the ¡job! ¡ ¡ But ¡ ¡ • Expensive. ¡ • Does ¡not ¡scale ¡well. ¡ • Does ¡not ¡support ¡real-­‑/me ¡ analy/cs. ¡

  4. Proposed ¡architecture: Real-­‑Time ¡Processing ¡ Batch ¡Layer ¡ Serving ¡Layer ¡ Layer ¡ Stores ¡constantly ¡growing ¡ Stores ¡the ¡batch ¡ Perform ¡analy/cs ¡on ¡fresh ¡ dataset. ¡ processed ¡views ¡for ¡ data. ¡ interac/ve ¡querying. ¡

  5. Lambda ¡Architecture Three ¡layers ¡architecture: ¡ ¡ • Batch ¡Layer ¡ – ¡for ¡batch ¡ processing ¡on ¡Big ¡Data ¡and ¡ producing ¡queryable ¡views. ¡ • Serving ¡Layer ¡ – ¡for ¡ad-­‑hoc ¡ query ¡(ideally ¡from ¡views ¡ generated ¡by ¡the ¡batch ¡layer). ¡ • Speed ¡Layer ¡ – ¡for ¡real-­‑/me ¡ views ¡based ¡on ¡incremental ¡ algorithms. ¡

  6. Batch ¡Layer ¡(i): ¡Hadoop ¡& ¡MapReduce • Programming ¡model ¡proposed ¡by ¡Google. ¡ • Solve ¡the ¡complex ¡issues ¡(compute ¡in ¡parallel, ¡load ¡balance ¡& ¡fault ¡ • tolerance). ¡ • Two ¡primi/ve ¡parallel ¡methods ¡(Map ¡and ¡Reduce). ¡

  7. Batch ¡Layer ¡(ii): ¡Stratosphere • Stratosphere ¡extends ¡the ¡well-­‑known ¡MapReduce ¡model ¡with ¡new ¡operators. ¡ • All ¡operators ¡will ¡start ¡working ¡in ¡memory. ¡ • Support ¡Java ¡or ¡Scala. ¡ • Scales ¡horizontally. ¡ • Seamlessly ¡integrates ¡into ¡exis/ng ¡Hadoop. ¡ • Built-­‑In ¡Op/mizer. ¡

  8. Serving ¡Layer ¡(1): ¡Apache ¡Drill ¡ • Inspired ¡by ¡Google’s ¡Dremel. ¡ • Drill ¡provides ¡a ¡distributed ¡execu/on ¡engine ¡for ¡interac/ve ¡queries. ¡ • Low ¡latency ¡ad-­‑hoc ¡queries ¡to ¡many ¡different ¡data ¡sources. ¡ • Goal ¡is ¡to ¡scale ¡to ¡10,000 ¡servers ¡and ¡process ¡petabytes ¡of ¡data ¡within ¡seconds. ¡ • Supports ¡mul/ple ¡data ¡models: ¡ ¡-­‑ ¡Schema: ¡Protocol ¡Buffers ¡& ¡Apache ¡Avro ¡ ¡-­‑ ¡Schema-­‑less: ¡JSON,BSON, ¡etc.. ¡

  9. Serving ¡Layer ¡(ii): ¡Cloudera ¡Impala • Massively ¡Parallel ¡Processing ¡query ¡engine. ¡ • Low-­‑latency ¡SQL ¡queries. ¡ • ¡Interac/ve ¡analy/cs ¡directly ¡on ¡data ¡stored ¡in ¡Hadoop ¡without ¡data ¡movement ¡or ¡predefined ¡schemas. ¡ • Shares ¡workload ¡management, ¡metadata, ¡ODBC ¡driver, ¡SQL ¡syntax ¡and ¡user ¡interface ¡with ¡Apache. ¡ • SQL-­‑92 ¡features ¡of ¡Hive ¡Query ¡Language ¡including ¡SELECT, ¡joins, ¡and ¡aggregate ¡func/ons. ¡

  10. Serving ¡Layer(iii): ¡Presto ¡(Facebook) • Distributed ¡SQL ¡query ¡engine ¡op/mized ¡for ¡ad-­‑hoc ¡analysis. ¡ • Supports ¡complex ¡queries, ¡aggrega/ons, ¡joins, ¡and ¡window ¡func/ons. ¡ • Read-­‑Only. ¡

  11. Speed ¡Layer ¡(i): ¡Storm ¡ • Exposes ¡parallel ¡real-­‑/me ¡computa/on ¡model. ¡ • Highly ¡Scalable. ¡ • Guarantees ¡that ¡every ¡message ¡will ¡be ¡processed. ¡ • ¡Transac/onal ¡topologies. ¡ • Stream ¡Processing. ¡ • Con/nuous ¡Computa/on. ¡ • Distributed ¡RPC. ¡ • Stream ¡Groupings. ¡

  12. Speed ¡Layer ¡(ii): ¡Amazon ¡Kinesis ¡ • Streaming ¡data ¡as ¡managed ¡service ¡ (Cloud ¡Service). ¡ • Based ¡on ¡metering ¡system ¡(charged ¡ based ¡on ¡shards ¡and ¡HTTP ¡PUT ¡ transac/on). ¡ • Capacity ¡of ¡the ¡streams ¡are ¡ configured ¡as ¡shards ¡(throughput ¡ capacity). ¡ • Kinesis ¡Client ¡Library ¡– ¡responsible ¡ for ¡load ¡balancing, ¡coordina/on ¡and ¡ error ¡handling. ¡ ¡

  13. Speed ¡Layer ¡(iii): ¡Samza • Three ¡layers; ¡stream ¡layer, ¡execu/ng ¡layer ¡and ¡processing ¡layer. ¡ • Samza ¡is ¡pluggable. ¡ • Streams ¡are ¡par//oned ¡and ¡ordered ¡sequen/ally. ¡ • stream ¡is ¡composed ¡of ¡immutable ¡messages ¡of ¡a ¡similar ¡type ¡(kaea ¡topics). ¡ • States ¡are ¡co-­‑located ¡with ¡each ¡tasks. ¡ • Check ¡poin/ng ¡for ¡failure ¡recovery. ¡

  14. Speed ¡Layer ¡(iv): ¡S4 • Distributed ¡stream ¡processing ¡engine ¡inspired ¡by ¡the ¡MapReduce. ¡ • Combina/on ¡of ¡MapReduce ¡and ¡the ¡Actors ¡model. ¡ • Provides ¡a ¡simple ¡Programming ¡Interface. ¡ • Decentralized ¡and ¡Symmetric ¡architecture ¡(managed ¡by ¡ZooKeeper). ¡ • Pluggable ¡architecture. ¡ • Lossy ¡failover ¡is ¡acceptable ¡– ¡Processes ¡are ¡moved ¡to ¡standby. ¡ • Several ¡PEs ¡are ¡available ¡for ¡standard ¡tasks ¡such ¡as ¡count, ¡ ¡ ¡ ¡ ¡ ¡ ¡aggregate, ¡join, ¡and ¡so ¡on… ¡

  15. Spark, ¡Shark, ¡Spark ¡Stream, ¡etc… ¡(i) • In-­‑memory ¡distributed ¡compu/ng ¡framework. ¡ • Provides ¡a ¡general ¡programming ¡model ¡(operators ¡such ¡as ¡ Map, ¡Reduce, ¡Join, ¡Filter, ¡GroupBy, ¡Sort, ¡LeiOuterJoin, ¡ RightOuterJoin, ¡Count, ¡Union, ¡Cross, ¡etc..). ¡ • Low-­‑latency ¡ computa(ons ¡by ¡caching ¡the ¡working ¡dataset ¡ in ¡memory. ¡ • Fault ¡tolerance ¡by ¡lineage ¡or ¡check ¡poin/ng. ¡ • Spark ¡extends ¡it’s ¡engine ¡for ¡stream ¡processing. ¡ • Provides ¡same ¡Spark ¡APIs ¡for ¡processing ¡stream. ¡

  16. Summary • MapReduce ¡to ¡generate ¡reports ¡and ¡answer ¡historical ¡ queries. ¡ ¡Separate ¡technologies ¡== ¡Complex ¡to ¡manage ¡and ¡ • Interac/ve ¡computa/on ¡for ¡ad-­‑hoc ¡queries. ¡ maintain. ¡ • Stream ¡for ¡real-­‑/me ¡analy/cs. ¡

Recommend


More recommend