Big data and APIs for PHP developers - SXSW 2011

15,963 views

Published on

Slides from the Big Data presentation by Bradley Holt, Laura Thomson, Julie Steele, Eli White, Dennis Yang, and David Zülke

Published in: Technology
0 Comments
16 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
15,963
On SlideShare
0
From Embeds
0
Number of Embeds
84
Actions
Shares
0
Downloads
305
Comments
0
Likes
16
Embeds 0
No embeds

No notes for slide

Big data and APIs for PHP developers - SXSW 2011

  1. 1. Big Data and APIsfor PHP Developers SXSW Interactive 2011 Austin, Texas #BigDataAPIs
  2. 2.  Text REDCROSS to 90999 to make a $10 donation andsupport the American Red Cross disaster relief efforts to helpthose affected by the earthquake in Japan and tsunamithroughout the Pacific.
  3. 3. Topics & GoalTopics: o Introductions o Definition of Big Data o Working with Big Data o APIs o Visualization o MapReduce Goal: To provide an interesting discussion revolving around allaspects of big data & to spark your imagination on the subject.
  4. 4. Who we are
  5. 5. Bradley Holt (@bradleyholt)Curator of this WorkshopCo-Founder and Technical Director,Found LineAuthor
  6. 6. Julie Steele (@jsteeleeditor)Pythonista (but we like her anyway)Acquisitions Editor, OReilly MediaGraphic Designer, freelanceVisualization curator
  7. 7. Laura Thomson (@lxt)Webtools Engineering Manager,Mozillacrash-stats.mozilla.comPHP, Python, Scaling, Systems
  8. 8. Eli White (@eliw)Worked for: Digg, Tripadvisor, HubblePHP guy at heartCurrently unemployed (Hiring?)Author:
  9. 9. Dennis Yang (@sinned)Director of Product & Marketing, InfochimpsPreviously: mySimon, CNET, & cofounder of Techdirt
  10. 10. David Zuelke (@dzuelke)Lead Developer: AgaviManaging Partner, Bitextender GmbHAddicted to rockets, sharks w/friggin laser beams, helicopters,HTTP, REST, CouchDB andMapReduce. And PHP.
  11. 11. Who are you?Lets Learn about the Audience!
  12. 12. Tell Us About You• Who is currently working on a Big Data problem?• Have you integrated with an existing API?• Do you publish your own API?• How many of you are PHP developers?• Tell us what you hope to learn here today.
  13. 13. What is Big Data?
  14. 14. Different Types of Big DataLarge chunks of data o Massive XML files, Images, Video, log filesMassive amounts of small data points o Typical Web Data, Survey votes, TweetsRequests/Traffic o Serving lots of data, regardless of set sizeProcessing vs storing o Different concerns if only processing versus storing
  15. 15. Working with Big Data
  16. 16. CAP TheoremConsistency All clients will see a consistent view of the data.Availability Clients will have access to read and write data.Partition Tolerance The system wont fail if individual nodes cant communicate.You cant have all three—pick two!http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf
  17. 17. Common Tools Hadoop and HBase Cassandra Riak MongoDB CouchDB Amazon Web Services
  18. 18. Scaling Data vs. Scaling RequestsHighly related? (or are they?)At Digg, both were related, as more requests meant more data,and more data made it harder to handle more requests.At TripAdvisor, it was handling pass through big data, we neverstored it, but had to process it quickly.Mozillas Socorro has a small number of webapp users (100?),but catches 3 million crashes a day via POST, median size150k, and must store, process, and analyze these.
  19. 19. OLTP vs. OLAPOLTP: low latency, high volumeOLAP: long running, CPU intensive, low volume (?)Trying to do both with the same system happens more oftenthan you might think (and will make you cry)One bad MapReduce can bring a system to its knees
  20. 20. Online vs offline solutionsKeep only recent data in online systemReplicate / snapshot data to secondary systemRun expensive jobs on secondaryCache output of expensive jobs in primaryMake snapshot/window data available to end users for ad hocprocessing
  21. 21. Case Study: Socorro
  22. 22. Whats Socorro?
  23. 23. Scaling upA different type of scaling:Typical webapp: scale to millions of users without degradationof response timeSocorro: less than a hundred users, terabytes of data.Basic law of scale still applies:The bigger you get, the more spectacularly you fail
  24. 24. Some numbersAt peak we receive 3000 crashes per minute3 million per dayMedian crash size 100k -> 150k30TB stored in HBase and growing every day
  25. 25. What can we do?Does betaN have more (null signature) crashes than otherbetas?Analyze differences between Flash versions x and y crashesDetect duplicate crashesDetect explosive crashesEmail victims of a malware-related crashFind frankeninstalls
  26. 26. War storiesHBase Low latency writes Fast to retrieve one record or a range, anything else MRStability problems and solutions Big clusters: network is key Need spare capacity, secondary systems Need great instrumentation Redundant layers (disk, RDBMS, cache) Next: Universal APIBig data is hard to move
  27. 27. APIs for Public Datasets
  28. 28. Sources for public data• Data.gov• DataSF: http://datasf.org/• Public Data Sets on AWS: http://aws.amazon.com/publicdatasets/• UNData: http://data.un.org/• OECD: http://stats.oecd.org/
  29. 29. InfochimpsOver 10,000 data sets listed at InfochimpsOver 1,800 data sets available through our APIAPIs allow easy access to terabyte scale data
  30. 30. Data is the lifeblood of your productAny great application consists of:• Awesome code• The right dataAnd, as weve seen with sites like CNET, NPR, Netflix & Twitter,it has become a best practice to build applications against APIsto access that data.
  31. 31. Infochimps Screennames AutocompleteAPIGET
http://www.infochimps.com/datasets/twitter‐screen‐name‐autocomplete?prefix=infochi&apikey=api_test-W1cipwpcdu9Cbd9pmm8D4Cjc469{"completions":["infochimps","InfoChile","infochiapas","infochilecompra","Infochick","infochimp","infoChief1","infochip2","infochild","infochiocciola",
  32. 32. How we make the ScreennameAutocomplete API• Flying Monkey Scraper o continually crisscrosses the user graph, to discover new users o 1B objects to insert a day, 8 nodes• Hadoop o To do the processing, 15+ nodes o Pig, Wukong o Precalculate 100M usernames -> prefixes -> a few hundred million rows o Sorted by Trstrank• Apeyeye o load balanced cluster of 10 nodes, across 2 data centers
  33. 33. Infochimps Yahoo Stock APIGET
http://api.infochimps.com/economics/finance/stocks/y_historical/price_range{"results":[{"open":19.1,"adj_close":9.55,"close":19.09,"high":19.33,"symbol":"AAPL","date":20010813,"exchange":"NASDAQ","volume":5285600,"low":18.76},
  34. 34. How we make the Stock APIChanges every day...You can get Yahoo stock data, every day too, in CSV form.• Hackbox: o little piece of armored sausage that takes the data and munges it up to be useful• Troop: o Publishes it into the datastore o Writes the API docs o Puts the API endpoint into the code o Stages for deploy
  35. 35. Build these APIs yourself.. if you want.You can build these APIs yourself.Check out http://infochimps.com/labs to see our opensourced codebase.Or, you can let us do it, and you can focus on writing awesomecode for your application, and let us do the monkeying with thedata.
  36. 36. And actually....These two APIs illustrate great reasons why you *wouldnt*want to build them yourself:• The data involved is too large to practically handle• The data involved updates frequently, so its a hassle
  37. 37. Examples of data available through theInfochimps API• Trstrank o How trustworthy is a Twitter user?• Conversations o Given two users, get a summary of their interactions• Twitter Name Autocomplete o Given a string, find twitter names that complete it• Geo Name Autocomplete o Given a string, find place names that complete it• Qwerly o maps from Twitter handle to other social networks• Daily Historical Stock Quotes• IP to Census o Given an IP address, map to Geo, then map to US Census info
  38. 38. And many more APIs...Many more APIs available:• Word Frequencies• Word Lists• Freebase• DBPedia• AggData• Material Safety Data Sheets (MSDS)• Internet "Weather" from CedexisAnd... many more to come.Relocate your subroutine to the cloud.http://infochimps.com/apis
  39. 39. Developing a Big Data API
  40. 40. Rules of thumbGenerate APIs that only give incremental access, dont shovemore data than needed at a user.For performance reasons, dont allow the user to request toomuch data in one request, and throttle requests.Consider building API against secondary system.Asynchronous APIs: request/queue data, pick it up later.Caches for big data dont necessarily help.
  41. 41. Visualization
  42. 42. Exploring vs. Explaining L. fineartamerica.com/featured/exploring-archimedes-david-robinson.html R. sgp.undp.org/web/projects/10771/environmental_awareness_and_familiarity_with_animals.html
  43. 43. Structure has a purpose. fiveless.deviantart.com/art/Periodic-Table-of-the-Elements-147350318
  44. 44. squidspot.com/Periodic_Table_of_Typefaces.html
  45. 45. michaelvandaniker.com/labs/browserVisualization/
  46. 46. Firefox rulz
  47. 47. It hurts. Make it stop.
  48. 48. Chart junk makes baby Jesus cry.L. www.flickr.com/photos/santo_cuervo/3693877386/R. www.gereports.com/a-good-look-at-the-cost-of-chronic-diseases/
  49. 49. http://jec.senate.gov/republicans/public/index.cfm?p=CommitteeNews&ContentRecord_id=bb302d88-3d0d-4424-8e33-3c5d2578c2b0
  50. 50. www.flickr.com/photos/robertpalmer/3743826461/
  51. 51. It deosnt mttaer waht oredr the ltteers in a wrodare, the olny iprmoetnt tihng is taht the frist andlsat ltteres are at the rghit pclae. The rset can be atatol mses and you can sitll raed it wouthit aporbelm. Tihs is bcuseae we do not raed erveylteter by it slef but the wrod as a wlohe.IT DEOSNT MTTAER WAHT OREDR THE LTTEERS INA WROD ARE, THE OLNY IPRMOETNT TIHNG IS TAHTTHE FRIST AND LSAT LTTERES ARE AT THE RGHITPCLAE. THE RSET CAN BE A TATOL MSES AND YOUCAN SITLL RAED IT WOUTHIT A PORBELM. TIHS ISBCUSEAE WE DO NOT RAED ERVEY LTETER BY ITSLEF BUT THE WROD AS A WLOHE.
  52. 52. The Stroop Effect RED YELLOW BLUE GREEN RED YELLOW BLUE GREEN
  53. 53. Color: function vs. decorationMartin Wattenberg and Fernanda Viégas, Chapter 11, Beautiful Visualization (OReilly Media)
  54. 54. Andrew Odewahn, Chapter 8, Beautiful Visualization (OReilly Media)
  55. 55. Be kind to the color blind courses.washington.edu/info424/Labs/ChoroplethMap.html
  56. 56. Cool tools to try• ManyEyes www-958.ibm.com/software/data/cognos/manyeyes/• Wordle www.wordle.net/• GraphViz www.graphviz.org/• Protovis vis.stanford.edu/protovis/• Tableau www.tableausoftware.com/
  57. 57. Your turn!datavis.tumblr.com/post/2746708037/the-sequel-map
  58. 58. MapReduceOr: How to even store and process that much data in the first place?
  59. 59. how much is "that much"?
  60. 60. Some Numbers
  61. 61. Some NumbersFacebook, new data per day:
  62. 62. Some NumbersFacebook, new data per day:• 03/2008: 200 GB
  63. 63. Some NumbersFacebook, new data per day:• 03/2008: 200 GB• 04/2009: 2 TB
  64. 64. Some NumbersFacebook, new data per day:• 03/2008: 200 GB• 04/2009: 2 TB• 10/2009: 4 TB
  65. 65. Some NumbersFacebook, new data per day:• 03/2008: 200 GB• 04/2009: 2 TB• 10/2009: 4 TB• 03/2010: 12 TB
  66. 66. Some NumbersFacebook, new data per day: Googles processing jobs:• 03/2008: 200 GB• 04/2009: 2 TB• 10/2009: 4 TB• 03/2010: 12 TB
  67. 67. Some NumbersFacebook, new data per day: Googles processing jobs:• 03/2008: 200 GB 400 PB per month (in 2007!)• 04/2009: 2 TB• 10/2009: 4 TB• 03/2010: 12 TB
  68. 68. Some NumbersFacebook, new data per day: Googles processing jobs:• 03/2008: 200 GB 400 PB per month (in 2007!)• 04/2009: 2 TB Average job size is 180 GB• 10/2009: 4 TB• 03/2010: 12 TB
  69. 69. what if you have this much data?
  70. 70. what if its just 1% of what Facebook has to deal with?
  71. 71. no problemo, you say?
  72. 72. reading 180 GB off a hard disk will take ~45 minutes
  73. 73. and then you havent even processed it yet!
  74. 74. todays computers process data way faster than it can be read
  75. 75. solution: parallelize your I/O
  76. 76. but now you need to coordinate
  77. 77. thats hard
  78. 78. what if a node dies?
  79. 79. what if a node dies?does the whole job have to re-start?
  80. 80. what if a node dies?does the whole job have to re-start? can another node take over?
  81. 81. what if a node dies?does the whole job have to re-start? can another node take over? how do you coordinate this?
  82. 82. Enter: Our HeroMapReduce to the Rescue!
  83. 83. olden days
  84. 84. distribute workload across a grid
  85. 85. ship data between nodes
  86. 86. store it centrally on a SAN
  87. 87. I/O bottleneck
  88. 88. 2004
  89. 89. MapReduce: Simplified Data Processing on Large Clusters http://labs.google.com/papers/mapreduce.html
  90. 90. distribute the data up front across nodes
  91. 91. then ship computing nodes to where the data is
  92. 92. share-nothing architecture
  93. 93. scaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaalable
  94. 94. Basic Principle: The Mapper
  95. 95. Basic Principle: The MapperMapper reads records and emits key and value pairs.
  96. 96. Basic Principle: The MapperMapper reads records and emits key and value pairs.Take an Apache web server log file as an example:
  97. 97. Basic Principle: The MapperMapper reads records and emits key and value pairs.Take an Apache web server log file as an example:• Each line is a record.
  98. 98. Basic Principle: The MapperMapper reads records and emits key and value pairs.Take an Apache web server log file as an example:• Each line is a record.• Mapper extracts request URI and number of bytes sent.
  99. 99. Basic Principle: The MapperMapper reads records and emits key and value pairs.Take an Apache web server log file as an example:• Each line is a record.• Mapper extracts request URI and number of bytes sent.• Mapper emits the URI as the key and the bytes as the value.
  100. 100. Basic Principle: The MapperMapper reads records and emits key and value pairs.Take an Apache web server log file as an example:• Each line is a record.• Mapper extracts request URI and number of bytes sent.• Mapper emits the URI as the key and the bytes as the value.Parallelize by having log files per hour, splitting up the files intoeven smaller chunks (by line) and so forth.
  101. 101. Basic Principle: The Reducer
  102. 102. Basic Principle: The ReducerAll values (from all nodes) for the same key are sent to thesame reducer.
  103. 103. Basic Principle: The ReducerAll values (from all nodes) for the same key are sent to thesame reducer.Keys get sorted, and in case of a simple count or sum, you cando a first reduce run on each mapper node once its finished tocut down on I/O (thats the combiner).
  104. 104. Basic Principle: The ReducerAll values (from all nodes) for the same key are sent to thesame reducer.Keys get sorted, and in case of a simple count or sum, you cando a first reduce run on each mapper node once its finished tocut down on I/O (thats the combiner).Apache web server log example to the rescue again:
  105. 105. Basic Principle: The ReducerAll values (from all nodes) for the same key are sent to thesame reducer.Keys get sorted, and in case of a simple count or sum, you cando a first reduce run on each mapper node once its finished tocut down on I/O (thats the combiner).Apache web server log example to the rescue again:• Reducer is invoked for a URI like "/foobar" and a list of all number of bytes.
  106. 106. Basic Principle: The ReducerAll values (from all nodes) for the same key are sent to thesame reducer.Keys get sorted, and in case of a simple count or sum, you cando a first reduce run on each mapper node once its finished tocut down on I/O (thats the combiner).Apache web server log example to the rescue again:• Reducer is invoked for a URI like "/foobar" and a list of all number of bytes.• Sum up the bytes, and we have the total traffic per URI!
  107. 107. Hello, HadoopMapReduce for the Masses
  108. 108. Hadoop is a MapReduce framework
  109. 109. comes with a distributed FS, task tracker and so forth
  110. 110. so we can focus on writing MapReduce jobs
  111. 111. works quite well, too
  112. 112. Big Hadoop Installations
  113. 113. Big Hadoop InstallationsFacebook:
  114. 114. Big Hadoop InstallationsFacebook:• Mostly used with Hive
  115. 115. Big Hadoop InstallationsFacebook:• Mostly used with Hive• 8400 cores, 13 PB total storage capacity
  116. 116. Big Hadoop InstallationsFacebook:• Mostly used with Hive• 8400 cores, 13 PB total storage capacity o 8 cores, 32 GB RAM, 12 TB disk per node
  117. 117. Big Hadoop InstallationsFacebook:• Mostly used with Hive• 8400 cores, 13 PB total storage capacity o 8 cores, 32 GB RAM, 12 TB disk per node o 1 GbE per node
  118. 118. Big Hadoop InstallationsFacebook:• Mostly used with Hive• 8400 cores, 13 PB total storage capacity o 8 cores, 32 GB RAM, 12 TB disk per node o 1 GbE per node• 4 GbE between racks
  119. 119. Big Hadoop InstallationsFacebook: Yahoo:• Mostly used with Hive• 8400 cores, 13 PB total storage capacity o 8 cores, 32 GB RAM, 12 TB disk per node o 1 GbE per node• 4 GbE between racks
  120. 120. Big Hadoop InstallationsFacebook: Yahoo:• Mostly used with Hive • 40% of jobs use Pig• 8400 cores, 13 PB total storage capacity o 8 cores, 32 GB RAM, 12 TB disk per node o 1 GbE per node• 4 GbE between racks
  121. 121. Big Hadoop InstallationsFacebook: Yahoo:• Mostly used with Hive • 40% of jobs use Pig• 8400 cores, 13 PB total • > 100,000 CPU cores in storage capacity > 25,000 servers o 8 cores, 32 GB RAM, 12 TB disk per node o 1 GbE per node• 4 GbE between racks
  122. 122. Big Hadoop InstallationsFacebook: Yahoo:• Mostly used with Hive • 40% of jobs use Pig• 8400 cores, 13 PB total • > 100,000 CPU cores in storage capacity > 25,000 servers o 8 cores, 32 GB RAM, 12 • Largest cluster: 4000 TB disk per node nodes o 1 GbE per node• 4 GbE between racks
  123. 123. Big Hadoop InstallationsFacebook: Yahoo:• Mostly used with Hive • 40% of jobs use Pig• 8400 cores, 13 PB total • > 100,000 CPU cores in storage capacity > 25,000 servers o 8 cores, 32 GB RAM, 12 • Largest cluster: 4000 TB disk per node nodes o 1 GbE per node o 2 x 4 CPU cores and 16 GB RAM per node• 4 GbE between racks
  124. 124. Hadoop at Facebook
  125. 125. Hadoop at FacebookDaily usage:
  126. 126. Hadoop at FacebookDaily usage:• 25 TB logged by Scribe
  127. 127. Hadoop at FacebookDaily usage:• 25 TB logged by Scribe• 135 TB compressed data scanned
  128. 128. Hadoop at FacebookDaily usage:• 25 TB logged by Scribe• 135 TB compressed data scanned• 7500+ Hive jobs
  129. 129. Hadoop at FacebookDaily usage:• 25 TB logged by Scribe• 135 TB compressed data scanned• 7500+ Hive jobs• ~80k compute hours
  130. 130. Hadoop at FacebookDaily usage: Data per day growth:• 25 TB logged by Scribe• 135 TB compressed data scanned• 7500+ Hive jobs• ~80k compute hours
  131. 131. Hadoop at FacebookDaily usage: Data per day growth:• 25 TB logged by Scribe • I/08: 200 GB• 135 TB compressed data scanned• 7500+ Hive jobs• ~80k compute hours
  132. 132. Hadoop at FacebookDaily usage: Data per day growth:• 25 TB logged by Scribe • I/08: 200 GB• 135 TB compressed data • II/09: 2 TB compressed scanned• 7500+ Hive jobs• ~80k compute hours
  133. 133. Hadoop at FacebookDaily usage: Data per day growth:• 25 TB logged by Scribe • I/08: 200 GB• 135 TB compressed data • II/09: 2 TB compressed scanned • III/09: 4 TB compressed• 7500+ Hive jobs• ~80k compute hours
  134. 134. Hadoop at FacebookDaily usage: Data per day growth:• 25 TB logged by Scribe • I/08: 200 GB• 135 TB compressed data • II/09: 2 TB compressed scanned • III/09: 4 TB compressed• 7500+ Hive jobs • I/10: 12 TB compressed• ~80k compute hours
  135. 135. HDFSHadoop Distributed File System
  136. 136. HDFS Overview
  137. 137. HDFS Overview• Designed for very large data sets, transparent compression, block-based storage (64 MB block size by default)
  138. 138. HDFS Overview• Designed for very large data sets, transparent compression, block-based storage (64 MB block size by default)• Designed for streaming rather than random reads
  139. 139. HDFS Overview• Designed for very large data sets, transparent compression, block-based storage (64 MB block size by default)• Designed for streaming rather than random reads• Write-once, read-many (although there is a way to append)
  140. 140. HDFS Overview• Designed for very large data sets, transparent compression, block-based storage (64 MB block size by default)• Designed for streaming rather than random reads• Write-once, read-many (although there is a way to append)• Stores data redundantly (three replicas by default), is aware of your network topology
  141. 141. HDFS Overview• Designed for very large data sets, transparent compression, block-based storage (64 MB block size by default)• Designed for streaming rather than random reads• Write-once, read-many (although there is a way to append)• Stores data redundantly (three replicas by default), is aware of your network topology• Namenode has metadata and knows where blocks reside
  142. 142. HDFS Overview• Designed for very large data sets, transparent compression, block-based storage (64 MB block size by default)• Designed for streaming rather than random reads• Write-once, read-many (although there is a way to append)• Stores data redundantly (three replicas by default), is aware of your network topology• Namenode has metadata and knows where blocks reside• Datanodes hold the data
  143. 143. Task ProcessingHow Hadoop Gets the Job Done
  144. 144. Job Processing
  145. 145. Job Processing• Input Formats split up your data into individual records
  146. 146. Job Processing• Input Formats split up your data into individual records• Mappers do their work, then a partitioner partitions & sorts
  147. 147. Job Processing• Input Formats split up your data into individual records• Mappers do their work, then a partitioner partitions & sorts• Combiner can perform local pre-reduce on each mapper
  148. 148. Job Processing• Input Formats split up your data into individual records• Mappers do their work, then a partitioner partitions & sorts• Combiner can perform local pre-reduce on each mapper• Reducers perform reduction for each key
  149. 149. Job Processing• Input Formats split up your data into individual records• Mappers do their work, then a partitioner partitions & sorts• Combiner can perform local pre-reduce on each mapper• Reducers perform reduction for each key• Mapper, Combiner and Reducer can be an external process
  150. 150. Job Processing• Input Formats split up your data into individual records• Mappers do their work, then a partitioner partitions & sorts• Combiner can perform local pre-reduce on each mapper• Reducers perform reduction for each key• Mapper, Combiner and Reducer can be an external process o Called Hadoop Streaming, uses STDIN & STDOUT
  151. 151. Job Processing• Input Formats split up your data into individual records• Mappers do their work, then a partitioner partitions & sorts• Combiner can perform local pre-reduce on each mapper• Reducers perform reduction for each key• Mapper, Combiner and Reducer can be an external process o Called Hadoop Streaming, uses STDIN & STDOUT  Shameless plug: http://github.com/dzuelke/hadoophp
  152. 152. </BigDataAPIs>
  153. 153. </BigDataAPIs>• Bradley Holt, @bradleyholt, bradley.holt@foundline.com
  154. 154. </BigDataAPIs>• Bradley Holt, @bradleyholt, bradley.holt@foundline.com• Julie Steele, @jsteeleeditor, jsteele@oreilly.com
  155. 155. </BigDataAPIs>• Bradley Holt, @bradleyholt, bradley.holt@foundline.com• Julie Steele, @jsteeleeditor, jsteele@oreilly.com• Laura Thomson, @lxt, laura@mozilla.com
  156. 156. </BigDataAPIs>• Bradley Holt, @bradleyholt, bradley.holt@foundline.com• Julie Steele, @jsteeleeditor, jsteele@oreilly.com• Laura Thomson, @lxt, laura@mozilla.com• Eli White, @eliw, eli@eliw.com
  157. 157. </BigDataAPIs>• Bradley Holt, @bradleyholt, bradley.holt@foundline.com• Julie Steele, @jsteeleeditor, jsteele@oreilly.com• Laura Thomson, @lxt, laura@mozilla.com• Eli White, @eliw, eli@eliw.com• Dennis Yang, @sinned, dennis@infochimps.com
  158. 158. </BigDataAPIs>• Bradley Holt, @bradleyholt, bradley.holt@foundline.com• Julie Steele, @jsteeleeditor, jsteele@oreilly.com• Laura Thomson, @lxt, laura@mozilla.com• Eli White, @eliw, eli@eliw.com• Dennis Yang, @sinned, dennis@infochimps.com• David Zuelke, @dzuelke, david.zuelke@bitextender.com

×