 And welcome, my name is Shannon Kemp and I am the executive editor of Data Diversity. We would like to thank you for joining today's Data Diversity webinar, Data Exploration and Analytics for the Modern Business sponsored today by Looker. Just a couple of points to get us started due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them via the Q&A section in the bottom right hand corner of your screen. Or if you like to tweet, we encourage you to share highlights or questions via Twitter using hashtag Data Diversity. As always, we will send a follow-up email within two business days containing links to the slides, the recording of this session, and additional information requested throughout the webinar. Joining us today are Greg Jones and Scott Hoover. Greg is a lead developer at Smartling where he is responsible for reporting and analytics, as well as for the Smartling API that enables access to Smartling translation functionality from other applications. Prior to Smartling, Greg was lead software engineer at thelatters.com, a leading mobile career network and served in various management and consulting roles in the software development realm. Scott is a data scientist on the Looker implementation team where he helps clients build models of their business data and has authored SDKs that extend Looker's functionality through its API. Before joining Looker, Scott worked as a statistician and academia and later consulting. And with that, I will give the floor to Scott to start the presentation. Hello and welcome. Good day everyone. Again, this is Scott Hoover. I work at Looker on the analytics team. Here is a business intelligence software and more to the point, it's a data exploration solution that operates in database and it enables organizations to explore data in all of its detail. Looker has about 100 clients at the present, which one is Smartling. And then we're gonna be hearing about the, you know, the UK's Smartling has with respect to Looker. And so we're just gonna turn it over to Gray Jones, who's their lead developer at Smartling. Greg? Thank you. So I'm gonna talk about data exploration and how we're doing at Smartling. I'm one of the lead engineers at Smartling. I'm in charge of the reporting analytics as well as the API. Let's see. What about Smartling? So we're a translation management platform. We enable companies to bring their content to an international audience. Essentially, we want to speed up the time to market it takes for a client to bring content out to the rest of the world. And you do that for a number of different pieces of content, whether that is your mobile applications, your dashboard, your marketing website, any business documents that you may have. We basically have any number of ways that we can take content and trend it and get it back to the end client and eventually the users of your system. So first we have an API to get content in. So if you have internet XML files or iOS string files, we have an API to allow that content in. We also support various CMSs such as Adobe CQ, Sitecore, Drupal, and all these enable clients to bring content into Smartling where we can translate it. We focus on professional translation. We do allow machine translation, but are to provide a great timely quality translations and we get that best with human translations. And at the end, we're going to deliver the content back to our clients in its translated form. The perspective of our business is something we call the global delivery network. This is a way where we can enable clients to drastically cut down the time to market that takes to bring content to an international audience. SurveyMonkey is a customer of ours and we actually have their site in German, French, and Spanish and numerous other languages. And we do that through what is known as a proxy in which a request for say a Spanish site survey would come in. We make it to the original SurveyMonkey, we get that content in English. Parsit, look up the translations that have been provided by our human translators and return that translated content back in all about a number of milliseconds. So we can do this and drastically cut down the time to market. So instead of something taking a couple of a year or two years to actually go and redevelop your site, your application to get it to an international audience, we can do that in a matter of weeks. We do little to no development required. We have a number of data needs. So we also provide translations back to our clients within a 48 hour time period. That's the SLA that we strive for. So to do that, we need to constantly be monitoring and looking into how well is our translation workflow working. So quickly our translators translated the content, how quickly we move into the next step, how quickly are the views and the edits taking place on it before it eventually gets published. So we want to look at that across a number of different ways. We want to look with it for a customer, for a given language, for an agency who's working with us. There's many ways we have to slice and dice the data. And we want to give our business leaders control over that data. We want them to be able to look at the data and get the data out that they need. And what we want to do is, while reducing development, for the more we also want to provide a single view of the data, before embarking on this, we would be up to a developer to come up with his own query about how this data would look, or a business user writing their own SQL to get this data. And they can get different results. So we want to provide one centralized view of the definition of what this data is. So some of the practical needs challenges that we have. So we do an enormous amount of volume. We serve upwards of 3 billion pages views a month. There's 84,000 metrics for a challenge. And we're monitoring it at a given time. There's a huge amount of data, and we need to process that data and do it in a quick and efficient timeline. We also have our data spread across three different databases. Joining that data, at first, was problematic. We want a simple API to add that data, without having to go through a lot of development work to get it. So first, we used Amazon Redshift as our data warehouse. We used it as a copy or replica of our transactional data. We stored it there nightly. And what we found with Redshift is that it's extremely high format database. The query that would take hours to run in our SQL would take seconds to run in Redshift. We also decided to look for our exploration platform. We found that they were a great way to get data from the front of the business users and let them get to the data that they need. For the looker, well, first it was strongly aligned with the Smiling Principles. Continually to improve their product and deploy new features. We have a web company, so everything is done in the web. There's no console applications to install. They made things incredibly easy to do. Working with Looker, their support is excellent. It just takes a matter of seconds to get in touch with them and to be able to resolve the problems. They were extremely easy to use. A number of our developers have built out models using Looker as Scott will demonstrate later. And then our CTO, who hadn't done much development work lately, was even able to build a report in Looker. As I mentioned before, one of the things we wanted to look at was how well are translations moving through the system? We wanted to be able to analyze our workflow and our velocity, how quickly things move that workflow, identify bottlenecks. We wanted to see that because we didn't want SLA that we wanted to maintain. We wanted to make sure that if that is not occurring, that our clients are able to recoup money in such a case. So how smartly is improving the process? If we weren't using smartly, a lot of times a 40-hour turnaround would not occur. So we wanted to show that smartly is able to speed up the process. So here's a sample of a report that is taken out of Looker. This is translation velocity, how quickly strings were able to move from approved, get translated, go through a two-step review process, and eventually be published. As you can see, there's a number of languages for this particular client. We were able to meet our 48-hour SLA. Sometimes well before the 40-hours even up. There were two languages that, well, they didn't quite meet the SLA. They were just a few hours over. And then there were six languages in which the 40-hour turnaround did not occur, and even one language, Turkish, here, that far exceeded what we consider an acceptable time frame for turnaround translations. So this isn't indicated to our business users that there's some issue here. It needs to be looked at to find why are things taking too long? Is this that there's not enough context for translation, and therefore things are slower in the translation process? Are there issues being raised that are not addressed? There are things going on here that need to be evaluated. And right now we don't have the ability to go and look into the details of that, but that's something we'll be providing on the road. But this is a first step in identifying that there's a problem here. We need to do something to correct that. So another aspect of this is we want to see how well we're leveraging translation memory. I don't want to explain that a bit. When a piece of text is translated, we store that text in SmartLink to serve a translation, but we'll store it so that we can refer to it later in case a similar piece of text needs to be translated. So if I've already translated the color red, and then the color of the blue comes in, we want to show that previous translation to a translator so they can give it, they can translate it quicker. They can use same context or same tense as a previous translation, so it has a uniform look to it. We do that, and we can also charge less money, we'll pay less money to the client than charge less to the translator. We can reduce software costs. We can reduce the cost that the translator is giving to the translator. So that's a view of our translation memory. For this particular client, we want to match content 20% of the time. So 20% of the time, we had a similar upstream translation in which we aided the translator in the translation they were providing, and we're saving money to the client because of that. And so it range from anywhere from 20% to 50%, and lately there's been a decent upward trend aside from this last month. Now in a deeper dive into the data, we actually see kind of what type of things are occurring here. So for example, we have close to three million words translated. Now if there were no matches being done, we weren't doing that matching to save time and money. It would cost $421,000 for the translations. With charging a lower cost for that translation, we're going to reduce that cost to $321,000. So a savings of nearly $100,000. For this 18 month period, $5,500,000 a month that the server can save through our leverage of leveraging translation memory. The aspects we're using, Looker and Data Exploration 4, we're trying to apply at-risk customers. Those customers who have not logged into the system recently. That can be an indication that the client is not satisfied with smartly at the time, so we want to find out if there's an issue there. If they're not utilizing the full benefits of smartly, we want to know about that. This is a preemptive way to make sure that a client is satisfied. We also use different financial analysis as we show in the charging translation memory report. We want to see how is the software giving us money? How are we providing a benefit to the client? Furthermore, we've cut down on development time. We've done that. Before ad hoc queries were done, and each time a business user needed a report, it had to go to a developer to produce that report. Now that we've defined models in Looker, we've given the business users a way to access that data without needing development time. And we've provided one view of the data as part of that. Now we're still in our adoption phase, but we are proceeding with that. So we now have Looker being used by our customer support, our account managers, sales engineers, product managers, developers, our CEO who developed a report and even our CEO. We're at work with the option, but that's so far we have a pretty good amount of users who have started using Looker and exploring their own data. One of the things we've tried to do further in our weekly release notes, where we talk about the products or the new features that we've developed, we really include interest facts that we've discovered through Looker and through our data exploration. And so we include that as kind of a hint or a way for our end users to get into Looker and discover this data for themselves. And we're also starting to broadcast this data out so that it's in the office, on a wall board, you can see various metrics that we're tracking. So some future plans. So now that we've put data users in front of our business users, they're only open for more reports and more analysis at this point. So we can continue to develop our digital models in Looker to have different metrics that we can look at. Ultimately, we want to expose our data to customers. Right now, we're focused on our internal business users, but we will bring that data to customers in the end where they can view the data as they want and accept it on their own. And we basically want to do this so that we can show the value that smartly is providing them. They can see a report that would show them how we're smartly saving them money. So thanks for having us. Scott's going to give a demo of Looker. We're going to go into the context by just kind of giving a high level overview of what Looker is precisely. First of all, Looker is a web application that connects to any relational database, you know, any SQL compliant database by way of a JDBC connection. Having a connection to a database, Looker allows users, developers to build a data model using our intermediate modeling layer, which relies on a proprietary language we call LookML, the YAML-based language. This extracts and simplifies SQL generation. Basically, developers define the relations between tables in LookML. They introduce Looker to intrinsic columns or attributes within their relational tables. And then they can even build metrics or KPIs. And basically what they're doing is through LookML, they're writing LookML, they're teaching Looker how to jsql on the fly. Having this, having had the Looker analytics team and developers on the customer's end sort of build out a data model in our intermediate layer, business users and people who are interested in doing data exploration have a user-friendly web-based user interface that they can explore their data with. Three things in my demo of Looker. First, the Explorer section, and this is how users go about building queries and building queries against the database. Also, dashboard and visualizing queries. I'll also talk about LookML and embedding SQL, which Smarling makes great use of. There's actually a, we have this drive table, it's actually common in SQL kind of terminology. But basically, developers can write any sort of SQL they can think of within the mailing layer and exploit that within the Explorer section. Smarling makes great use of this and this is how the translation velocity report was created. And if time, you know, if time, I'd like to show some examples of LookML and demonstrate that it's rather expressive and lightweight, and so they turn out on introducing new KPIs or relations between tables. It doesn't take a lot of time or effort. All right, so I'm going to share my browser. So this is demo.looker.com, this is our demo instance. And for today's demo, I'm actually going to take a look at the look, which is the simulated e-commerce store that we have, but let me just give you a high overview of what you're seeing here. There are four main components of Looker, the first of which is the Explorer section, and this is where users go to do all this ad hoc querying against the database. Within the Explorer section, you can have a connection to any number of databases across dialects. So in this case, you know, we have five database connections here, and this varies across dialects. With any e-base connection, you can have any number of base views. And I'll dive into a base view and explain what is meant by this, but basically it's just a facet of your data or your business that you want to ask and answer your questions. The second component is dashboards, and this is pretty straightforward. These are just visualizations of queries that people have constructed within Looker. So after we go to our business pulse, which is just a look at what's been going on in the past 90 days for this simulated e-commerce store, you can have any sorts of, you know, visions all within one area. And our visualizations and dashboards also facilitate data exploration, as you'll see within the modeling layer, because you can actually, you know, apply filters which pass through all these tiles, and so all your visualizations update, and there's a drilling aspect to any of our visualizations or dashboards. More on that later. The third component is the looks page, and actually that's the page you're seeing now. These are just analogous to reports. So these are queries that, you know, are my coworkers have built in sync because we want to access them on a regular basis. You can also click and see, you know, what sort of reports your coworkers are building and collaborate, and the page, you can also manage the scheduling female, as well as the sharing of any look that you've built within Looker. There's the modeling layer, and I'll go into greater detail after I kind of demonstrate the explore section, so we'll get a good look at that in just a minute. But first let me go to the look and to our order items base view really quickly. So this order items base view and we have our empty or blank query canvas. And so this is the base view is this. Within the modeling layer, we started from a single table of interest. In this case, it's order items. And so we're gonna build queries to answer questions about order items. So we're gonna single table, and we find in others that relate to it. So for instance, each row represents an individual order item, but an item is associated with a parent order. So we're going to join in the orders SQL table and all the attributes that reside within that table to sort of slice and dice our queries by. Similarly, users place orders so we can join in the users table and use all the attributes about users. So if I'm interested in seeing facts about order items broken out by demographic or geographic information, this is how I'd go about answering questions like that. On the end, there are an order maps to a product as well as an inventory item. And so we've joined these tables in. Again, it's basically a denormalized view of order items where each row represents an individual order item. And we've joined all these tables and we have lots of attributes to slice our queries by. As suggested, there are two components of a query with a looker. Dimensions are basically just columns that are intrinsic to your SQL tables. So for instance, I can take an order items ID and run this. And basically, this is just the primary key of this table. Dimensions can also be calculated. So within the modeling layer, developers can write custom SQL or do arithmetic between existing dimensions or measures and create custom metrics. So for instance, this margin percentage is not an intrinsic column, but longer knows how to build this or construct this metric because a developer or a looker analyst has built this into the modeling layer. So the looker knows how to write the SQL in order to create this metric on the fly. So if any query within looker would be a measure and these are the aggregate functions applied to the above dimensions. Think of this as summing or counting or taking an average of any column within the database. Or rather, within this base view, any table that has been brought into this base view. So I'm going to start with some kind of basic principles and move on up. So I'm going to start with a rather basic query here and I'm just going to do a series of aggregates. So I'm going to take a look at orders count, order items, products, orders, users, brands and categories. So I've added these measures to my query canvas and now I need to run it. So what I'm doing is it's being told that the user wants to see these aggregate measures. It's going to construct the SQL, send it to the database and return the results that to the user. And I also noticed that when I ran this query up on the left hand side here at the top, it threw up a filter. So what we're seeing is orders or rather, aggregate results provided that the order was created in the past 30 days. So they originally set up this model thought it would be a good idea to do this to return recent and relevant results. Our date filters are also, you know, they can be changed on the fly. So what we're doing here is results that for today and the 29 days prior, come tomorrow, it will be tomorrow and 29 days prior. We can update this to reflect something else. So something like, suppose I want to see the past 90 days. I can just type in 90 days. So for business or people who don't write SQL on a regular basis, it's rather convenient to use natural language. And it's very intuitive too. So if I want to do something like 60 days ago or 30 days, I can isolate this 30 day block that began 60 days ago. And of course, this will be on a rolling basis. It's relative. And the answers have autofill. And in this case, the dates there will kind of give us some insight on what we can do, you know, what we can apply as a filter. So this query, I'm just gonna stick to this month. So this, there have been roughly 1,500 order items representing 1,400 products. This amount came from 895 orders made by 798 users. This represents 666 brands and 26 categories. I'm gonna break this out by some dimension. This is basically just group by in SQL. So suppose I want to see how this differs over some geographic attributes. Let's take a look at user state. I want to associate with the largest number of orders or order items or products. We can get any dimension or measure by just clicking on its name. So if I want to just sort this alphabetically by state, I can do so. I can also choose, you know, how about orders count and see which state is associated with the largest number of orders. I did that. The order was placed this month. We see a lot of California. So I want to isolate California and maybe build a report around this. I click on California. And what that will do is it'll actually throw up that value into a filter for me, such that any subsequent query that I run with a looker will be limited to orders created this month provided that the user who placed that order was in California. I'll see how I alter this filter at the top. I'm gonna go ahead and remove the state because we're always talking about California. And maybe now I want to break this out by time. So I have two ways of doing that because I want to break it up at the day level. I can go to filter, which is already in my query canvas and add this to the table. Alternately, I can just go to the left-hand panel where all my dimensions and measures reside and I can just search for it. So I want to see created date, order created date and I'll add this to my query run on it. I'll sort in a central order. There we go. So this bike or let me filter this and see which days is associated with the largest number of orders. I see that it was part of me. Yeah, May 20th. So suppose I actually see what's driving this. Looker is all about facilitating data exploration and this is allowing users to drill into the raw data. So any account within Looker is drillable. So I want to see the 13 categories represented by these 10 orders on the 20th of May. I can simply click on that 13 and I'm taking this user-defined drill set. So the value of the count was 13. Intuitively, when I'm taken into this new window, I'm going to see 13 rows that represent, which row represents the values captured by that count. So the categories represented here are the results that we have 13 rows with each category there. And we have a number of measures or dimensions that the analyst or developer thought would be intuitive for the user to see whenever they click on accounts. These results are not static though. I can always update them. So suppose that I wanted to add gross margin to this. I can just add gross margin and rerun this. That Looker isn't moving your data. It's actually piecing together SQL and not against the database and returning it for you. So I'll actually jump over to this query SQL tab here. To demonstrate the necessary SQL one would have to write in order to reproduce this query by hand. Pretty quickly, things can get intense. So you see that there's a lot of value added if you're in a case where analysts are using requests from business users to get to certain data. Now you've actually empowered, or rather Looker, empowers business users and analysts to actually go out and ask the questions themselves. And then you have to write the SQL, which could be rather tedious. I want to demonstrate our ability to pivot within the user interface because it's rather useful. And then I'll transition to visualizations and lastly the modeling layer. So I'm going to enter this query and start again. I want to actually ask the question, or rather answer the question, how do users behave with respect to their ordering depending on the month in which they signed up? So this would be a rather straightforward analysis. This is just a cohort analysis. To do it within Looker, it's actually fairly trivial. So I'll take a look at a couple of time attributes. I want to see order created month. I'm going to apply a filter here. I want to see the user created month. I'll match on this one as well. And then I want to see the number of users who placed orders and the corresponding number of orders. So that's past eight months. I'm going to hide the left-hand panel, and I can sort these so they're a little bit more intuitive here. The whole set is what we might get in SQL. What we have is every pairwise combination between user created month and subsequent order created month. We have the number of users who placed those orders. It might be a little bit easier to actually kind of consume this data if each cohort was represented by its own row. And to do that within Looker, all we have to do is pivot one of these time attributes. And in this case, I'll choose order created month, I'll pivot it, and then rerun this query. And that would be kind of easy to consume matrix or tabular results that, or each row represents the cohort, and the pivoted time dimension represents their subsequent behavior with respect to ordering. So that's what we have to do. For those of you who signed up in October of 2013, 18 users placed one or more orders in that same month based on this pivoted time dimension. We see that they placed 90 orders. Of that cohort who signed up in back in October of 2013, 130 users placed one or more orders in the following month based on the time dimension pivoted here. And we see they placed 148 orders in the same way. And then we have some null values here for subsequent rows indicating that cohort up in November or December could have placed orders in the month before they signed up. We can always add stuff to this. So suppose that I wanna see profit per user, I could run this, and now I've just updated my result set to have this metric, and we can look at the value of these customers that are basically our strong repeat customers. Again, we can also drill in. So if I wanna see who these customers are, I can actually click that 43, and I have this user defined drill set. So now I have my list of our most loyal customers, and perhaps I can do some further analysis and glean some insights about attributes about these users who return to the store often. Let me demonstrate creating a visualization on Looker. It's rather straightforward. All I want to do is construct a query of interest and then jump over to our Visualize tab. I'm actually just gonna build a bar chart of orders by state, something rather simple here. So I'm gonna do orders. How about a break this out by user state. So here's the result set. It's actually for the past 30 days. That's fine, I'll leave it at it as is. We can see California is the top state with respect to the number of orders, whereas Nevada is the top state with respect to average gross margin, but we're talking about two orders here. Anyway, let me sort this. So suppose I visualize this. Here's that SQL tab. So this is the query generated by Looker. And then I jump over to this Visualize tab. I can just choose the most appropriate visualization for this particular query that I've built. So we have the area charts. Bar chart might be very appropriate for this one. And this is actually kind of how the smartling team went about visualizing their translation velocity. So all the developer had to do was come up with a way to measure translation velocity, which would appear as a measure. And then they brought it up by client and then visualized it just using this visualization tab. We're gonna call them line charts in the event that you want to do a time series. Starts high end tables as well and a single value in the event that your result set is just a measure with perhaps some filters applied. So again, just a collection of these visualizations. So unless developers and business users have gone around querying, identifying result sets that they want to see on a regular basis, they can see them as looks or they can add them to their dashboard. So I'm gonna return to this business pulse, which is just a collection of these visualizations. So in the previous part of me, 90 days, we can see that in this simulated e-commerce store, there have been about 3,100 total orders with an associated average order profit of $55. And we have 1,000 first time purchasers. Again, the looker is that much like it's tabular result sets, you can drill in. So if you're in a time series and you see a spike or perhaps a big dip and you wanna see what's going on beneath the scene, you can always drill in. If I wanna see the seven sweaters that sold back on March 26th, I can click on that seven. I'm gonna use this user defined real set. Because in between queries, it's as simple as using the back button, so that's rather convenient. And we have visualizations too. So we have geographic plotting, so we can have zip represented. And again, we can drill in, see the order items or orders associated with any given zip code or a PUS, donut charts. And then there's that actually any dimension definition can include embedded HTML. So notice that from the sync board, we have a brand name. It's just the top 10 brands for the past 90 days with respect to various metrics here. Suppose you see a summary about our top brand. This little spark line to the right will actually jump me to a new dashboard and automatically apply the filter Allegra, rather within the name filter, it will pass the parameter Allegra K for me in this default through orders in the past 30 days. And basically I have a summary of that brand for the past 90 days. Again, I can demonstrate it with Calvin Klein. This is in other definitions of dimensions. So actually, if I return to this result set, where I order items, we have a user history field. And so this is not an intrinsic column in the table, rather what it does is it jumps us to the orders base view and automatically applies a filter, maps to the user that I was clicking on. So I clicked on an order item associated with Jasmine. I wanted to see her a complete order history. I click on that order history and I jump to the order space view and a filter is applied for me. We can go with the items. Actually, you can get quite creative with this. So I think this is to transition to our base view, rather our modeling layer. I'm gonna go to the model section. I'm actually gonna jump into developer mode here. And then I'm gonna go to the look model, which was what we were playing in. So, primary file types that we focus on when we're developing a model. There's the model.look.ml file. And this is where all the joins are made explicit, such that Looker knows how to piece together joins on the fly when users are calling from various tables. The second type is a view file and this maps directly to the SQL table. So for instance, the order.view file has all these dimensions, which basically map to the intrinsic columns in the table. But you'll notice that I have embedded SQL within this file and there's also arithmetic between existing dimensions. This is how developers and analysts can sort of embellish the default model. That is, they can use intrinsic columns and then build upon those, such that while users are exploring in the user section, they can use all these custom metrics that may be pieced together around complex SQL, but they may be unaware that it's actually doing that for them. This is the model file. And I just wanna walk through the definition of a base view. You should have an SQL example as well. So, just turn your attention to line 10 here. We're just declaring a new base view. So actually, I'm gonna go back to between the SQL and the Looker.ml. Basically, when we declare a base view inventory items, this is the table made reference to in a from clause in a select statement. We're also gonna be able to select any sort of combination of dimension and measures from the base table as well as any tables that we join in. But that's beyond the scope of this call. Or this webinar part of me. Next line is just declaring a list of joins. So, I'm gonna join in the following tables, the first of which is products. And then all I do is make reference to the foreign key in the table, in the base table. So, basically, what this implicitly is doing is it's mapping the foreign key within the inventory items table, and it's setting it equal to the product ID, or the primary key of the table that we're joining in. There are other custom join types that Looker has, but Looker really plays well with data stored in third number form, and by default, we're talking about F joins here, but there's a high level of custom, you can customize any sort of join here. So, we have SQL on arguments, where we can specify shared columns, or conditional joins in the event that you have polymorphic tables, and we also have just the ability to write custom SQL here, and so now, you can really just write any sort of SQL that comes to mind, so you can do joins, full outer joins, with all sorts of interesting conditional or join logic. And then below, this SQL is basically, or yes, this SQL is basically kind of what we'll get when we declare a base view. So, we're selecting dimensions and measures from the combination of tables that we've joined in, the base view itself is the table in the from clause, the join in are left joined, so we're going in products. The foreign key maps the foreign key in the base table to the primary key of the table that we're joining in, and then in square brackets, I have all these optional SQL clauses, so a where and a having clause map to filters within the explore section, and a group by would be just a dimension in the event that you have a combination of dimensions and measures, and an order by just, you know, click on the dimension or measure name. I'm gonna show you orders, oh, I should comment this out. I'm gonna show you a review file, and again, kind of just quickly go over what makes a view file or a base view. So, a base view has to make reference to a view file, and a view file will map directly to an intrinsic SQL table, but they could also be a derived table, which actually is beyond the scope of this webinar. But basically, it's analogous to a materialized view or some sort of SQL that you're writing on the fly, and it's transforming your data into some table and exploits, and anyway, I'll let that. Anyway, so as I've mentioned, basically maps to a common in the table. So in this case, there's a primary key of our orders table, it's the ID, and so we're gonna bring you this in, or rather make reference to that table or that column in that table by just declaring a dimension ID. It's the primary key, so we're saying primary key is true. It can specify the data type. So in this case, the primary key is integer, and there's this SQL argument, and what we're passing as a parameter is basically what I kind of say is like a handshake between looker and data. So it works, whenever a user calls the orders ID within the explore section, look to the online table, in this case it's orders, and look to the column ID, and it knows which data to kind of pull in and display it whenever they're poking around and choosing various dimensions. This created time attribute. In this case, we're looking to the orders table and the data at the date time field. That's actually interesting. What we're doing is we're creating a number of dimensions kind of in a bulk process. What we're doing is we're actually extracting various time attributes from the single time or time stamp. So we're looking at the created time, the created date, the created week, the month, the month number, year, and the date and week number. All from the single time attribute, we can kind of parse out these other aspects, these other attributes of time. There's license types of data by. So if we wanted to see the number of orders at the week or month level or by day of week, we can do that with this single time attribute, really. Also, we have embedded SQL. So for instance, total amount of orders in US dollars, this is not an attribute that resides or that is intrinsic to this orders table. This is actually calculated by doing a correlated sub-select between the orders table and the order items table. So basically, we're summing up the order items sale price, provided that the order ID in the order items table is equal to the orders die-die-die-die. So, not only does SQL dialects have this capability, and you'll notice that Looker actually plays well with all sorts of dialects. So you can write SQL that is dialect specific. So in the event that you have a PSQL dialect or something along those lines, you can utilize, or TSL, you can utilize window functions or something along those lines. If you have myQL, you can utilize correlated sub-selects and all that great stuff. And this is all specified within the admin panel. When you make a connection to a database, you specify the dialect, and it's that simple. So I'll wrap it up for the demo and then I'll transition to a Q and A. So I'm gonna stop sharing my browser. And I'll just return to my slides here. So I'm gonna ask the questions here. We're not able to share dashboards or data with people who don't have a Looker login. We do have the ability to share dashboards and queries, tabular results sets with people who do not have a Looker login. I did not demonstrate that in the demo. And this is a rather important component of Looker. Scheduled emails or scheduled looks, rather. You can email out tabular results sets. You can also send out dashpiles or entire dashboards. And we also have read-only dashboards or embedded iframes to present visualizations to people who do not have a Looker login. We also have an API. So we have a number of ways of getting Looker out, I mean, sorry, data outside of Looker and getting it into any sort of dashboarding system you have, and we also have integration with Google Docs and Excel spreadsheets. So you can actually take a public look or public save query and kind of pipe to a spreadsheet and then that spreadsheet around. And the great thing about that is that that result set is actually basically a live query against the database. So you can, it will all reflect new data as that data has changed on the database. I have a question for Greg. He covered this, but I think maybe he can speak more to it. Greg, what is your infrastructure or database? Do you have any other systems that are connecting to Looker? I don't know, it is simply Redshift. We could bring in our MySQL transactional, but pretty much we'll do a data copy one today to Redshift and use Looker off of that. Do Looker's documentation or reference guide users to refine data intake and analysis, i.e., what are noises and what are early warning? I don't think I've seen that question. If that was your, if you ask that question, what are noises and what are early warning? If you know how, if you would elaborate on that question, I'll, I could circle back to that one. We also have a question, how does Looker deal with non-relational data? So, you know, like we can talk like no SQL. Looker is first and foremost is like a, you know, a tool for relational databases. So it's basically all SQL compliant databases. However, we recognize the importance of SQL, it's actually, you know, the importance of the day and age. And so we're working on builds for Impa, Spark, or Shark. And so these will be basically HiveQL. We're looking for engines that, you know, increase query performance for HiveQL. So we build and we don't have customers on it right now. We're still in the kind of the development phase, phase in testing it, because we want to make sure that it's as performance as our relational solution. I speak to this and I think Greg will be able to speak to this one as well. What kind of training is required for this type of analytics? Based on the answer, well the answer is it depends. So, you know, users who are using, predominantly just using the explore section as well as dashboards, they just have to be data curious. They don't have to have a superb understanding or actually rather any understanding of SQL or relational databases. They just have to, you know, have questions in mind and have the curiosity to sort of answer them and poke around and build queries within the explore section. From a different standpoint, we like to identify someone who can own the model and that typically is someone who has experience with SQL. So, they're DAs, they're developers, they're analysts or data scientists who all, you know, all of whom write SQL on a regular basis. So, you manage by people who aren't SQL experts, look at them as themselves in abstraction of SQL. And so, it's best if one has an understanding of SQL going into, you know, model development and look at her. I don't know if you can, you know, add to that, Greg, if you have any perspective on it. I'd say that we did our training much how you describe. We had a couple developers and they received the handle modeling layer and they did all of the defining of models and our end business users, they weren't involved in the model creation but we did a number of training sessions just to kind of get familiar with Looker, how to use it. Excellent. How can I incorporate Looker into existing web app? And in friends, we have ASP.net. So, Looker to have an API and we have a number of SDKs. We have Ruby, Python, Node.js and we also have an R package. But basically, you can utilize the API to sort of, you know, core existing data model and take, you know, result sets and they'll be JSON blobs and present that however you like within your application. We have a number of clients that do that. It's kind of one component of how they use Looker and we have a couple of clients that all buy entirely on the Looker data model in conjunction with the use of the API and they get a great deal of value out of it and they actually don't use the Explorer set all that much, it's actually rather interesting. So we see different kind of configurations or use cases for Looker. So, here you have the API data in SQL Server. How many Windows as you are? Yes, yes. Any SQL compliant or relational database that can, you know, by way of a JDBC driver, we can handle and actually we use, we connect to the SQL or, you know, SQL Server all the time. Let's see, other questions. So there's that first question about Looker documentation and I was not quite sure on the question but, you know, going off the first half of the sentence, do you guys have Looker documentation or guides for users? The answer is yes. Within Looker, the Looker instance itself, there's a link to the Doc section and the Doc section is an entire site on getting this users and analysts or developers up to speed, either checking data in the Explorer section and creating dashboards or the developer kind of paths, you know, how to get up to speed developing in LookML. A reference section for, you know, API operations and security, drive tables and then just a kind of a LookML or dashboards reference section. And lastly, a video library, which is actually really important in the event that you learn visually. We have a solid kind of training section for our video library. Okay, this is the last question. How long does it take to implement? That's a good question. It depends. So it depends on the complexity of the data. It depends on how much ownership did it on your end take when on the model. With that said, I actually work on the implementation team, so my job is to sort of fit out and deliver a model that is very much workable to the client. And again, that it varies on how long that takes. With that said, Looker generates a great deal of the model obviously for itself or programmatically. So I'm actually not sharing my browser anymore, but there is a section where you can actually just generate a new model. And what the generator does is it takes a view of the database that we're connected to, all the tables that are within that database, and it will generate individual view files for each one of those SQL tables. It will apply all of the intrinsic columns in that table and interest them as dimensions. So all the lines of codes where we were declaring dimensions, unless it's a calculated dimension, that is all done programmatically at the outset of a trial or implementation. And then actually Looker is smart enough to do a lot of the joins and the creative base use by itself. So prior to that, foreign and primary keys are named intuitively, and there aren't like table prefixes in the event that you have a jail or something along those lines. Our generator is smart enough to actually make these joins and declare these base use for you. So we actually just spin up an instance or spin up an instance of Looker, generate a model once the database has been connected to, and users are actually a rather workable model that they can use right out of the gate. And then Looker analytics team, as well as the developers on the client side, they just take ownership of updating the model and adding any custom metrics that users want to see when they're exploring the data. I think that's it. So I'm going to pass it back to Shannon. Thank you all for your time. Perfect. Greg and Scott, thank you so much for this webinar and the information education and the demo of the product. Always good to get some demos in for our subscribers and thanks, of course, to our attendees who always submit and are so engaged in submitting some great questions for our speakers. Hope everyone has a great day and just a reminder as everyone that we will get a copy, a follow-up email for the webinar within two business days. So for this webinar, by end of day, Monday, with links to the slides, links to the recording, and additional information so you can take a look at Looker yourselves and what they're doing. Hope everyone has a great day and thanks again for your time. Thanks, Greg, and thanks, Scott, for another great presentation.