PowerPivotGeek » A Peek Inside

A Peek Inside: Updating data in your embedded PowerPivot workbook

powerpivotgeek — Thu, 13 May 2010 04:02:27 +0000

Recently I have been seeing some threads about how data is updated in a PowerPivot workbook. As it turns out, this can be a pretty complicated technical situation, so lets start off with a general statement: There are only 2 ways to update the embedded data contained in a PowerPivot workbook:

Bring the workbook down to the client machine, use the PowerPivot Excel add-in and click on “refresh”, then republish the workbook back to SharePoint (which implies certain SharePoint rights to enable)
Use the build-in PowerPivot data refresh facility (which also implies certain SharePoint rights)

That is it.

But as you guess, there is more to the story. So let’s start a ‘geek session’ and drill down into the type of data source. The update story really depends on if the user has defined a data source using a trusted connection or a SQL login connection. So let’s take them one by one.

If using trusted Windows authentication against the data source, let’s look at this sequence of events:

User A creates a PowerPivot document that access a relational DB using user A’s interactive credentials.
User A publishes to SharePoint.
As User A has contributor rights against the document, she can set up a data refresh schedule. As part of the schedule, she specifies what Windows credentials to use for the data refresh. The creds are stored encrypted in SharePoint Secure Store. This is specified once for the entire job (as this is the Windows environment that the job runs in).
When data refresh runs at 2am, the data is updated using the schedule’s credentials. The Windows creds must have contributor rights to the file because we read and write the file using the job’s Windows cred’s SharePoint rights.
If User B is allowed to copy down the document (which he can do if he has READ rights, but he cannot do if he has VIEW ONLY rights) and he refreshes the connection using the PowerPivot Excel add-in the DB accessed with User B’s interactive credentials.

If using SQL logins against the data source, the sequence is slightly different:

User A creates a PowerPivot document that access a relational DB using the data source creds specified in the connection – it would likely NOT be User A’s Windows uid/pwd.
User A publishes to SharePoint.
As User A has contributor rights against the document, she can set up a data refresh schedule. As part of the schedule, she can specify the non-Windows data source credentials to use for the data refresh. The data source creds are stored encrypted in SharePoint Secure Store. This must be specified on a data source by data source basis. The Windows creds specified for the schedule must have contributor rights to the file because we read and write the file using the job’s Windows cred’s SharePoint rights.
When data refresh runs, the data is updated using the schedule credentials by modify the connect string to include uid/pwd.
If User B is allowed to copy down the document and he refreshes the contents using the PowerPivot Excel add-in, then he may or he may not be prompted for the password. The default setting is to re-prompt for the password, but if User A wanted to, she could have embedded the non-Windows auth password in the connection and User B would re-use it also.

I hope that clears things up a bit.

Enjoy.

A Peek Inside: Allocation. What is it? Why is it important?

powerpivotgeek — Fri, 02 Apr 2010 20:49:30 +0000

Recently I have been getting some questions about an earlier post that I did around how the PowerPivot inactivity unloading is done. see http://powerpivotgeek.com/2010/03/04/a-peek-inside-unloading-powerpivot-data/ for more details. Surely there must be a faster mechanism for unloading data – and there is – but to fully discuss that aspect of the system we need to take a step back and talk about how databases get loaded in the first place. I don’t mean the actual loading process (that is another interesting post that I’ll do later on), what I mean is how PowerPivot decides to load something to begin with . . . and where it decides to load it.

PowerPivot provides on-demand loading of embedded databases. What this means is that when a client application makes a connection to a workbook (by placing “server=http://sharepoint_server/site/subsite/doclib/workbook.xlsx;” or “data source=http://…/workbook.xlsx;” on the connection string), then the system looks to see if the workbook’s embedded data has already been loaded. If so, the connection request is routed to that PowerPivot app server. If the embedded data has not yet be located then the system has to go through what we call Allocation. Allocation is the process of deciding which app server to use to load the data and to load it into that machine’s AS Engine instance (we only allow one AS instance per machine – called \GeminiBI in CTP3 and \PowerPivot in RTM).

PowerPivot ships with two algorithms:

Round-robin – where the system just picks the next server in the PowerPivot System Service instance list (using the SP object model – remember PowerPivot is a shared service in SharePoint).
Health-based – where the system polls all of the PowerPivot System Service instances to determine their health and uses the healthiest server as the location for the ‘to-be-loaded database’.

Notice that round-robin is the default. Round robin is particular good if need to minimize the number of messages flowing through your system as it does not poll any of the servers – it just picks the next one and uses it. Since it does not check to see if that system is the ‘best’ from a memory or CPU perspective, round robin is best used when there is no memory pressure on the servers. It is NOT a good algorithm under heavy load. The heavy load use case was the design point for health-based allocation.

Health-based uses the current CPU and memory usage of the AS instance on each machine to determine the healthiest. But for our purposes the other thing that it does, if it cannot find a server that has memory free (CPU is only used as a tie-breaker), then health-based looks to see if there are any inactive databases that can be unloaded to make memory available for the target database (the embedded data in the workbook). An ‘inactive’ database is those that have no currently opened connections to it. Health-based scans the list of inactive databases in oldest-to-latest last accessed order; until the target amount of memory (1.5X the size of the workbook) is found. Thus multiple databases may be unloaded. The PSS sends XMLA DETACH commands to each database, it loads the target workbook, and then the connection request is forwarded to the right server.

So . . that is what happens. But who is actually doing this work? That is the “geek’ie” part of this post. Rather than using the PSS and having to create a “master” PSS (which would give us a single failure point), we elected to do this work in a distributed manner. Here are the components:

The allocation algorithms run in the WCF proxy code. When a request comes in (a remote procedure call to a method in the PSS), the proxy looks to see if it knows where the target database is located. If the proxy has seen the database before, then it forwards the request to the PSS for that respective endpoint. If the proxy has not yet seen the target database it picks one of the PSS web services at random and invokes a method on it to see if the database is located in the PowerPivot service application database (the so-called instance map, which is a record of what databases are loaded and cached (detached) on each AS engine. There is a 10-minute background thread in the PSS that keeps the local AS engine in-synch with the instance map. The randomly chosen PSS returns the instance map information. If the target database is in the instance map then the proxy forwards the request to that PSS endpoint. And everything is good.

If the target database is not in the instance map information, then the proxy looks to see what allocation algorithm to use. If it is round robin, then the proxy just picks the next server in the PSS instance list. Since there could be many PSS proxies in the farm (e.g. many WFEs, many web applications that might have different IIS application pools, ECS transports, and other backend services that access PowerPivot via msolap, ADOMD.NET, AMO which in turn use the Channel Transport), the actual allocation of servers is likely to appear random or heavily favoring one server. We purposely did not synchronize the picking of the ‘next’ server because that would have placed a hot spot on that particular resource. Round-robin is supposed to be a fast, minimal algorithm – so having it become random over time is considered OK.

If the allocation algorithm is health-based, then the proxy polls each PSS gathering information about CPU, memory and the status and size of memory taken by each database on the servers. The proxy then decides which is the ‘best’ server and what databases to unload (detach) to be able to load the database on that server. The proxy then calls the server to perform the load and forwards the request to that particular machine’s PSS endpoint.

At any point, in the entire algorithm the proxy is prepared to handle that the ultimate target endpoint that it is given, for example, from its own cache, or from the instance map information, might be wrong and the RPC call may return that the database is not located where the proxy believes it to be. If this happens, the proxy reties. It keeps retrying the number of PSS instances are on the farm. If the proxy is still chasing its tail through all of the pointers and caches in the system, then it gives up and returns an “unable to load database” error to the caller.

So, in summary, i wanted to go over this not to explain allocation itself, but more to make the point that rather than say one simple thing — “When in doubt, turn on health-based allocation – and let it proactively unload databases.” While not directly tied to inactivity, it is the single biggest ‘tuning’ option that you have to clearing resources in a high memory use configuration.

Enjoy.

A Peek Inside: Unloading PowerPivot data

powerpivotgeek — Fri, 05 Mar 2010 05:58:18 +0000

Ok folks. Here comes a cool one.

As I am sure that everyone is aware by now, one of the most powerful new features of PowerPivot is that we do on-demand loading of embedded data. Well, if you are going to load it, then you had better at least think about unload it at some time. There is probably some law of thermodynamics that applies here.

First rule for deleting data is that we don’t touch data if there are users currently connected to it. But other than that, any databases loaded or cached by the PSS (i.e. their database folder is contained in the SSAS Backup folder tree) are candidates for being unloaded.

There are two ways that databases can be unloaded in PowerPivot:

a) Inactivity

If a database has not been accessed for a long time, then it is a good idea to start to free up resources for it. However being too aggressive means that you may have to re-read content which places a larger load on SharePoint. One of a farm’s most critical resources is the amount of traffic that has to be moved to and from the content database. So we want to minimize its load as much as possible. This is particularly true if the content is large – which is likely for PowerPivot workbooks. We have designed PowerPivot so that inactivity checking is a two stage algorithm. Every 30 minutes the PowerPivot System Service (PSS) scans the databases in the instance map assigned to the server’s service application looking for:

A loaded database with its ‘last accessed’ timestamp longer than 48 hours (2 days). If it finds one, the PSS detaches the database from the SSAS instance. The database remains in the cache (a collection of detached databases on a server) so it is available for quickly coming back if a user accesses the database. If this happens, all the PSS has to do is to issue an Attach XMLA command – it does not have to go back to the SharePoint content database and re-read the workbook.
A cached database with its ‘last accessed’ timestamp longer than 120 hours (5 days). If it finds one, the PSS deletes the database from the cache by deleting the database folder (and all its files) from the hard disk. If a user accesses the database after it was deleted from the cache then the data has to be re-read from the workbook (which is stored in the SharePoint content database).

b) New Content has arrived

If a file is updated in SharePoint (whether or not file versioning is enabled or not), then the any databases loaded or cached for that file can be unloaded from memory and deleted from the server cache immediately. Ordinarily you would think that it would be over aggressive to delete all old databases.

Every 30 minutes the PSS scans the databases in the instance map assigned to the server’s service application looking for content that is newer than the content loaded or cached. The instance map contains the SPFileVersion.Created property of the file version that is loaded. If the ‘latest version’ of the file has a SPFileVersion.Created that is later than the instance map then we know that new content has arrived. If the database is loaded, then we delete the database from the SSAS instance by sending an XMLA Delete command. If the database is cached, then the PSS deletes the database from the cache by deleting the database folder (and all its files) from the hard disk.

Note that we cannot use the SharePoint versioning system to determine if a version has changed. We have to use this timestamp method because the SharePoint versioning system can be disabled. In fact it is disabled by default. When it is disabled all files look like version 1.0. We are able to use the file version “Created” property because files in SharePoint are read-only. There is no in-place editing. If you edit a file, then behind the scenes you are creating a new version and it has the “Created” timestamp of the save operation.

—————————-

Being a geek, you are probably asking if you can change any of these thresholds or behaviors. The answer is “Sorry, No. Maybe next version.”

Enjoy!

A Peek Inside: Why no cross-farm support?

powerpivotgeek — Thu, 26 Nov 2009 05:38:17 +0000

From time to time, particular from knowledgeable SharePoint users coming up to speed with PowerPivot, I get the question: “PowerPivot have ‘cross-farm’ support”. As you can see from the title of this post, we don’t support it – and in this “A Peek Inside” I hope to explain why.

First, what is SharePoint ‘cross-farm’ support and why is it important. In large, complex SharePoint configurations a common requirement is to specialize servers or farms of servers to specific services. A good example of this approach is to have a separate farm dedicated to Search. Rather than having each end-user farm host its own Search service, the idea is to get better scale through specialization. Content crawling is done remotely; the indexes are kept remotely; and the Search results are calculated remotely. End users connect to the content farms (so-called because that is where the content is stored), but the content farm reaches out to specialized servers/farms for other services. Example of these services is: Search, Personalization, Business Data Catalog, Portal Usage reporting – coming in SharePoint 2010 are lots more . . .

Here is an example:

So why can’t we put PowerPivot out on one of the specialized farms. At a cursory level this sounds like a good thing. You can could share PowerPivot servers across the whole enterprise rather than having to replicate them within each of the content farms (where the workbooks are stored). Sounds like a great idea. Unfortunately however, it isn’t technically possible. For those services such as PowerPivot and Excel Services that rely on on access to the content, there is no way for the remote service to reach back into the content farm to access data. That is OK as far as it goes, but let’s get geekie and dig a bit deeper.

If you take a look at the kinds of services which can be spun out to specialized servers. These have several interesting characteristics, i.e. they are self-contained, and independent of the content itself.

BDC –> Obviously getting access to transactional systems is totally unrelated to the content (.docx, pptx, xlsx, etc.) that is stored in the content farms. Typically you are using BDC servers to lookup line of business reference data, e.g. customer master lists, product catalogs, transactional data, etc. None Typically this means lookups based on keys, e.g. give me the reference data for customer #42, or give me the reference data for product “abc”, or give me the POS data for transaction #291129211. As there are no references to the content, the BDC service can easily be deployed in its own server farm where it acts as a front-end to underlying corporate databases.

Personalization –> While personalization is related to a certain kind of content, i.e. the SharePoint People and Groups that would be used across various farms, it is also very self-contained. The keys are passed into the service for data lookups, but the actual personalized information is fully contained within the service itself and it has no dependency on the content.

Search –> At a first glance, it seems like Search should not be a good candidate for server farms. After all, Search is all about the content. Isn’t it?? As it turns out, it is about the content, but not during the actual lookup process. The Search farm contains the crawlers that are indexing the various SharePoint content farms (and from that point of view, it is all about the content), but it also crawls other sources as well. As it turns out, what the Search really needs at runtime isn’t the content – it is the indexes about the content. As these are kept self-contained within the Search farm, it turns out that Search is a good candidate for a server farm because at run time, what is used isn’t the content itself (there is no need for Search to reach back into the content farms), but rather access to the indexes that matters.

So when we were deciding if PowerPivot would be a candidate for cross-farm specialization, we had to look at the need for access to content. And this brings us to the “geek’est” (is that a real word??) part of the post. How do you programmatically access content in SharePoint. There are two different aspects to the problem: getting access to content if data is within the farm; and getting access if data is outside the farm. If the data is outside the farm, then there are 3 ways:

Using the web services APIs that SharePoint exposes (flexible but very inefficient at large data sizes)
Using a standard HTTP GET against the SharePoint URL for where the content is stored, e.g. (this is what Search crawlers use)
/site/subsite/doclib/file.xlsx">/site/subsite/doclib/file.xlsx">http:///site/subsite/doclib/file.xlsx
Using WebDAV that allows you to access content from the SharePoint farm as if it was a large, single file share, e.g.
\site\subsite\doclib\file.xlsx">\site\subsite\doclib\file.xlsx">\\\site\subsite\doclib\file.xlsx

Unfortunately none of those techniques work if you are within the farm because firewall rules do not allow backend servers to loopback into the front-end servers. If the data is within the farm then there is only one way to access content: use the SharePoint object model (aka SP ‘binary OM’) , e.g. SPFile.OpenBinaryStream. This is the preferred way of getting data as it is very efficient and accesses the SharePoint content databases directly. It is an order of magnitude (or more) faster than using the outside the farm APIs, even if loopback was allowed.

Now here’s the problem. The binary OM only allows you to access content from within the farm. You cannot reach out an retrieve data from a different farm. In the case of a remote PowerPivot server farm, it cannot use the binary OM to access the content farm – except if using the ‘outside the farm’ APIs – which is very inefficient and would not perform anywhere near fast enough. Thus for those services that are “content focused”, such as Excel Services and PowerPivot, you have no option but to build their app servers as part of the content farm; cross-farm support is not possible or feasible until there are considerable changes made to the SharePoint binary OM.

A Peek Inside: Why are domain accounts needed?

powerpivotgeek — Thu, 19 Nov 2009 04:39:40 +0000

Have you ever had to do something that you knew (you just KNEW) that lots of folks were going to scream – and scream loud – about? This is one of those cases – I can just feel it!

Ok, here goes. There have been several recent newsgroups postings concerning why we require domain accounts to install PowerPivot for SharePoint. Why must the farm account and the various service accounts be domain accounts. This causes lots of heartache for users that want to install demo or evaluation servers because we don’t support a standalone server. Well, we do support standalone, but it a different kind of standalone. Let’s get right into it.

First, let’s compare and contrast this requirement with SharePoint. SharePoint has two types of installations: standalone (which they do NOT support in production) and complete/farm. The standalone installation is for demo and evaluation purposes only. It has uses NETWORK SERVICE as the service account for many of its internal processes. It is right up front that it is NOT expandable into a production system; it has security issues acting across servers; etc. However, it gives you a nice “toy” to play with. Let’s be right up front about it – PowerPivot does not install nor does it support a SharePoint standalone server installation. And, oh while we are on the subject, SharePoint does not support local machine accounts within a farm configuration. In the SharePoint world, once you go to domains – you go all of the way with domains.

PowerPivot’s philosophy for the NEW FARM case is that it is a complete farm that just happens right now to be on a single machine. We take a production-view of the single server. We would expect that it would natural that at some time in the future that the SharePoint administrator would move the content and config databases off of this server and put them on their own dedicated SQL Server machine. After all, this is a best practice for SharePoint to have a dedicated (or consolidated) SQL resource off of the WFE and App Servers. And just as the RDBMS traffic is very likely to grow beyond a single combined “all-in-one” server; so would the app server requirements continue to grow and it is perfectly natural for a second, third or more app server to be added to the farm; likewise as the server becomes more main stream, there is a high-availability requirement that will become more important and multiple WFEs will be come important.

The bottom like is that proper capacity planning begins with your first installation. And thus we require domain accounts right from the very beginning.

Yes, this does impact those folks who are doing demos and evaluation. You have two options: (1) install a domain controller on your image and thus local accounts are domain account; or (2) install the server into a domain and possibly then disconnect from it (see an earlier posting from me on this topic). Approach #1 is what most users do. If you look at all of the “All-Up” VMs that Microsoft produces for other products, you will see that a self-contained domain within the VM is the way that most folks go. I personally use technique #2 because I do demos in a very constrained environment and having to modify the workbooks that I am demoing with is fine.

< OK – Let the screaming begin >

A Peek Inside: The client architecture

powerpivotgeek — Wed, 11 Nov 2009 08:15:00 +0000

Well, I have a fun one today. We get asked all of the time about how the PowerPivot add-in works. Particularly how it relates to the SSAS components that BI Pros are used to, e.g. making connections to SSAS. As I am getting ready to write an architecture overview blog posting for the PowerPivot team blog, I decided to take the client architecture out for a spin and attempt a more detailed drilldown here . . .

Here is a block diagram of the PowerPivot client component architecture:

As this is a geek discussion, I will spend a bit more time on how some of these components are implemented. As most of these components (with the exception of the ‘transports’ in the msolap OLEDB provider) are likely already known to you geek’ie SSAS pros, I will just make a few observations:

Notice how the addin interfaces with the VertiPaq engine – it uses AMO and ADOMD.NET. This is one of the most powerful aspects of PowerPivot. While we expose a tabular interface to end users, the underlying model is multidimensional. It is based on the UDM and well-known and established SSAS interfaces. We use AMO and ADOMD.NET (and their resulting languages, MDX and XMLA) as the components to implement the multidimensional objects.
As the addin is written exclusively in C#, we use the managed libraries to interface with the VertiPaq engine. Excel itself is still native code, so when Excel pivot tables want to ‘speak’ to PowerPivot, they use the msolap OLEDB provider.
Inside the msolap OLEDB provider are four transports. A transport is a module that provides the physical channel used for sending messages back and forth to the server. In the case of the client addin, there are three possible transports:
1. TCP/IP – this is used for normal client-server connections. In this case, the SERVER= is used in the connection string.
2. HTTP – this is used for http access, e.g. using the data pump in SSAS, or making a connection to the PowerPivot for SharePoint PWS component (PowerPivot Web Service) – more on the PWS in the full architecture blog posting coming next week. For the data pump, the connection string is SERVER=http://server/virtual_directory/msmdpump.dll. For the PWS, the connection string is: SERVER=http://sharepoint_server/webapp/site/subsite/doclib/file.xlsx
3. INPROC – this is the transport that is being used here to make a connection to the in-memory VertiPaq engine. The key that indicates that this is an in-proc connection is the SERVER=$EMBEDDED$ or DATA SOURCE=$EMBEDDED$ value.
4. There is a fourth transport, called the CHANNEL transport, but it is used on the SharePoint farm to route requests directly to the PowerPivot System Service (PSS) – so I will put off a detailed discussion of it until we talk about the midtier architecture (likely next week).
AMO and ADOMD.NET have a similar transport mechanism inside the http client, but it is much more straightforward as it is written in managed code and has a less complexity as the msolap provider does.
Notice that the entire component stack is in-proc within the Excel process – Excel, the msolap provider, AMO, ADOMD.NET, and even the VertiPaq engine are all together. Can you spell 64-bit?
Not to point out the obvious, but a downside to this approach is that we have no process little separation between the components, i.e. a VertiPaq crash is also an Excel crash and the reverse. We are all one happy or unhappy family (together).
As a dev team – and a supportability champion – the beauty of this architecture is that we were able to get a ton of reuse from the existing SSAS infrastructure (for example, the client libraries, and the in-proc code path is similar to SSAS local cubes).
The transport mechanism makes it transparent to the pivot table how the actual messages flow – everything is driven by the format of the SERVER= (or DATA SOURCE=) parameter on the connection string. So, in a way, the user does control the message flow – because he or she is the source for where the SERVER= parameter points to.

So, I hope you enjoyed the slight detour in to the client ‘realm’, I hope to get back to the midtier and the server soon but then it was fun. So maybe I will stay here for a while. You never know . . .

A Peek Inside: Where’s the beef?

powerpivotgeek — Tue, 10 Nov 2009 06:48:54 +0000

You have seen all of the cool demos – millions of rows of data in a single workbook. It is the hallmark of many PowerPivot keynote and session demos at conferences these days. It is way cool to see that much data being moved around so easily. The obvious question (which us technical geeks get all of the time) is: “Wow! That is way cool. So where is the data?“ In this “A Peek Inside", we will show you. The answer is that it’s in there — and by “there”, I mean in the workbook. Really? How can that be true? That seems very strange. This is a database, right?” But it is not; it is part of a new way of looking at data that we feel very passionate about here in PowerPivot-land. We call it: “a document-centric view of data.” By this we mean that the workbook is the data; the data is the workbook. There is no hidden database out in the world that contains the data. It is all there in the workbook. There is no ‘delete’ operation on the data – if you want to delete the data, you delete the workbook. If you want to archive the workbook along with its matching other Office documents, such as a project plan, or MS Word specification, or whatever, you just copy and archive the workbook and you have the data at the same time. PowerPivot has a document-centric view of the data.

As I was getting ready to show you all of this in a series of screen shots when I noticed that Denny Lee has already done that. Take a look at his posting here:

http://powerpivottwins.com/2009/11/07/for-excel-powerpivot-the-database-is-in-the-workbook/

He also shows a cool trick to find out which columns are taking the most amount of space in your database. I’ll add a link to that as well.

http://powerpivottwins.com/2009/11/07/understanding-why-an-excel-powerpivot-workbook-is-so-large/

So we come to the end of the story – and we had geek’ie fun doing it

Till next time.

A Peek Inside: The message stream between the client and the PWS

powerpivotgeek — Sun, 08 Nov 2009 05:15:56 +0000

In the first of our “A Peek Inside” articles, let’s take an easy one. When using a client makes a connection to a PowerPivot workbook that is stored inside SharePoint, how do you suppose the connection is made? If this was a regular SQL Server Analysis Services database then there are two options: either a TCP/IP connection (typically at port 2383; although the default port number changes from version to version) or a http connection. For PowerPivot we use http connections exclusively. All communication between the client and the front end web server (in SharePoint terms, it is called a WFE for Web Front-End) is done using a http connection.

The PowerPivot component that accept an in-bound connection is called the PWS, for PowerPivot Web Service. The PWS is a WCF web service that is invoked in the context of the web application for where the workbook is stored. The context includes not only the URL but also the http port and all of the other characteristics that IIS and SharePoint have setup for the web application. As the PWS is logically based on the SSAS data pump message flow (for all of you SSAS geeks out there), it does not use normal WCF remote procedure calls, instead it looks at the raw stream directly and interprets it as an old fashion SOAP call from the client libraries to the PWS.

Thus, unsurprisingly, if you were to look at the http traffic between the client and the PWS with a network monitor, you would see that the message flow is extremely like the messages that SSAS sends and receives.

Look for a series of ‘A Peek Inside’ articles coming soon

powerpivotgeek — Sun, 08 Nov 2009 04:56:47 +0000

From the recent Q&A that I have been having with customers at the SharePoint Conference last week in Las Vegas, and this week at SQL PASS in Seattle, it is clear that there is a lot of interest in how PowerPivot works inside. Thus from time to time I am going to post a series of short, “to-the-point” articles about interesting topics that talk about how PowerPivot works inside.

To differentiate them from my regular postings, you will find them titled “A Peek Inside:” and they will start with an icon like this:

(obviously I will also create a separate category for them as well)

I hope you will find them useful and entertaining.