cds5516舵机控制程序_[电力世界]中的应用程序CDS

cds5516舵机控制程序

执行摘要 (Executive Summary)

CDS for Apps VS Power Query – is there a difference? If so, what is that difference? Are they mutually exclusive or complement each other? Later I briefly outline Common Data Services for Analytics no, Power BI Datapools no again, actually Power BI Data Flows. It is difficult to keep up with the correct naming.

CDS for Apps VS Power Query –有区别吗？如果是这样，那有什么区别？它们是互斥的还是互补的？稍后，我简要概述通用Analytics for Data Services，而不是Power BI Datapool ，实际上是Power BI Data Flows 。难以跟上正确的命名。

What I have put together is my impression based on my experience and research from the perspective of a backend data person with a developer background. I try not to draw too direct conclusions so please treat it as what it is at this point: a technical opinion (and not an expert’s testimonial).

我的总结是基于我的经验和从具有开发人员背景的后端数据人员的角度进行的研究。我尽量不要得出太直接的结论，因此请按目前情况将其视为：技术意见（而非专家的推荐）。

In short: my understanding is that CDS for Apps is a subset of Power Query functionality packaged together, something similar to how a SQL Server stored procedure is an abstraction layer of a bunch of T-SQL statements. The same applies to CDS for Apps, you don’t need to understand all the subtleties behind CDS for Apps, it’s like an M stored procedure (that includes connectors in my view though it is not the case in the official documentation).

简而言之：我的理解是CDS for Apps是打包在一起的Power Query功能的子集，类似于SQL Server存储过程是一堆T-SQL语句的抽象层的方式。同样适用于CDS for Apps，您无需了解CDS for Apps的所有细微之处，就像一个M存储过程（ 在我看来，它包括连接器，尽管官方文档中并非如此 ）。

So even without CDS for Apps, we can use all that it offers and even more on the backend side, assuming at least one of the dev team can code M queries (Microsoft plans to introduce M into SSIS/ADF, too so it can be used in enterprise level data load processes, too!).

For some more details, please read on!

因此，即使没有CDS for Apps，我们也可以使用其提供的所有功能，甚至可以在后端使用更多功能，前提是至少有一个开发团队可以编写M个查询（微软也计划将M引入SSIS / ADF中，以便也用于企业级数据加载过程！）。

有关更多详细信息，请继续阅读！

背景 (Background)

Recently I had a chance (thanks to a colleague who came to me with a question) to experiment a little bit with Power Query.

最近，我有机会（感谢一个向我提出问题的同事）对Power Query进行了一些实验。

With all things, Power (true to this one, too) lines become blurry regarding the target audience or the targeted userbase. You hear about a Power [Something], labeled as “self-service” and initially, you (certainly true for me) don’t really know how the pieces fit together and how it is integrated into Microsoft’s enterprise level product roadmap.

总而言之，关于目标受众或目标用户群， Power （也适用于此）内容变得模糊。您听说过被标记为“自助服务”的Power [Something]，起初，您（ 对我当然是真的 ）并不真正了解各个部分如何组合以及如何将其集成到Microsoft的企业级产品路线图中。

My purpose is to share what I have learned in a brief period of time to help you avoid the confusion and misunderstandings that I had about these things. Given my background, I mostly see things from the BI developer’s (if there is still such a thing, please put your own designation here: data engineer, analytical specialist, etc) perspective, so when I write I or we, it is always from that viewpoint. However, being a consultant means I try to consider technical solutions from a wider perspective from two angles:

我的目的是分享我在短时间内学到的知识，以帮助您避免我对这些事情所产生的困惑和误解。在我的背景下，我通常会从BI开发人员的角度来看事情（ 如果还有这样的事情，请在此处输入您自己的称呼：数据工程师，分析专家等 ），所以当我写我或我们的时候，总是那个观点。但是，作为顾问意味着我试图从两个角度从更广泛的角度考虑技术解决方案：

How would management/stakeholders understand the capabilities of a new tool (or a new version of a tool)? – this often drives future tech-investments and has a significant impact on projects
管理层/涉众如何理解新工具（或工具的新版本）的功能？ –这通常会推动未来的技术投资，并对项目产生重大影响
How could end users (on any level) deal with the new tool/version? – this obviously impacts support and its structure
最终用户（任何级别）如何处理新工具/版本？ –这显然会影响支持及其结构

I openly admit that I don’t have a clear picture when it comes to Microsoft’s Power [Something] strategy and roadmap. Bits of news fly around all the time and the scene changes very often. What I write below is my impression and I try not to draw too direct conclusions so please treat it what it is at this point: a technical opinion (and not an expert’s testimonial).

我公开承认，对于Microsoft的Power [Something]策略和路线图，我并没有清楚的了解。几乎所有时间都散布着很多新闻，而且场景经常变化。我在下面写的是我的印象，我尽量不得出太直接的结论，因此请在此时将其视为： 技术意见 （而不是专家的推荐）。

应用程序CDS (CDS for Apps)

I keep hearing about CDS for Apps and how awesome it is, and that we just need to wait for a little as it’s not ready yet or not released with all its features.

我一直在听关于Apps的CDS以及它的强大程度，我们只需要稍等一下，因为它尚未准备就绪或尚未发布所有功能。

应用？什么应用程序？ (Apps? What Apps?)

My first unspoken question was: What the heck are these Apps? Only Power Apps or a more general application concept? I’m still not entirely sure as it seems to be Power Apps but for some reason, Microsoft doesn’t want to explicitly say that so at the same time it’s wider than that, maybe we need to include all the other apps that are part of e.g. D365.

我的第一个不言而喻的问题是：这些应用到底有什么用？只有Power Apps或更一般的应用程序概念？我仍然不能完全确定，因为它似乎是Power Apps，但是由于某些原因，Microsoft不想明确表示这一点，所以同时它要比它更广泛，也许我们需要包括所有其他的部分应用程序。例如D365。

那么什么是CDS for Apps？ (Then what is CDS for Apps?)

My own brief definition for CDS for Apps is the data management layer of Apps.

对于CDS for Apps，我自己的简短定义是Apps的数据管理层 。

On their official site, Microsoft doesn’t define it but highlights what it can be used for. I am not sure if it’s a fully fleshed out product but could still be in the finalizing phase which will be done after releasing it as a preview kind of feature.

Microsoft在其官方网站上没有定义它，但是突出显示了它的用途。我不确定它是否是完全充实的产品，但仍可能处于定型阶段，该阶段将在作为预览功能发布后进行。

Officially “Common Data Service (CDS) for Apps lets you securely store and manage data that are used by business applications. Data within CDS for Apps is stored within a set of entities. An entity is a set of records used to store data, similar to how a table stores data within a database.” – I find it a bit vague and not really clear. My quick definition also doesn’t say more but it is less cloudy.

正式而言，“ Apps通用数据服务（CDS）使您可以安全地存储和管理业务应用程序使用的数据。 CDS for Apps中的数据存储在一组实体中。 实体是用于存储数据的一组记录，类似于表在数据库中存储数据的方式。 ” –我觉得它有点含糊不清。我的快速定义也没有多说，但多云较少。

我们可以用吗？ (Shall we use it?)

After (not) figuring it out the answer to the first question comes the next one: Shall we use it?

在（没有）弄清楚第一个问题的答案之后，出现了下一个问题： 我们应该使用它吗？

How does it fit into the BI/analytics space? My take on that: it doesn’t.

它如何适应BI /分析领域？我的看法是：不是。

Why do I say this? Those Apps (whatever they are) are on the other side of data: when it’s captured. Of course, there is always a “getting data” component to present the user e.g. available values, customized product list, … but the main focus is on capturing data in a form / using an ERP system / … We use the data on the other side when it is already part of the system and we extract it from there usually en masse.

我为什么要这样说呢？这些应用程序（无论它们是什么）都位于数据的另一端：何时被捕获。当然，总会有一个“获取数据”组件来向用户显示，例如可用值，定制的产品列表等。但是，主要重点是以表格的形式/使用ERP系统/来捕获数据 。。。当它已经是系统的一部分时，我们通常从那里大量提取它。

Where do the two worlds come together? Does this mean that CDS for Apps (whatever it does/will include as it evolves) is so cool, but in the backend realm we lose out on it because we want to use it but can’t?

两个世界在哪里融合在一起？这是否意味着CDS for Apps（无论它做什么/将包括它的发展）是如此酷，但是在后端领域中，我们会迷失它，因为我们想使用它但不能这样做？

Be patient, I’ll answer this at the end of a next point ?

请耐心等待，我会在下一点结束时回答这个问题？

ETL (ETL)

We all know what this age-old concept of Extract-Transform-Load (or nowadays often flavored as Extract-Load-Transform) means. But why do I mention it here? How is it related to CDS for Apps? Where is ETL in the current Microsoft universe?

我们都知道这个古老的Extract-Transform-Load概念（或如今经常被称为Extract-Load-Transform）的含义。但是为什么我在这里提到它？它与Apps的CDS有什么关系？当前的Microsoft Universe中的ETL在哪里？

The whole data loading landscape is under serious changes (seemingly fast but things don’t die out that quickly and new technologies (in a production-ready state!) don’t rise that quickly either) highlighted by the followings (this is purely just based on my experience and readings) – please note that I exclude the big data world on purpose for now:

整个数据加载格局正在发生重大变化（看似很快，但事情并不会很快消失，新技术（处于生产就绪状态！）也不会很快上升），重点是以下几点（纯粹是根据我的经验和读物）–请注意，我暂时不考虑大数据领域：

in the Microsoft world on premise versions are losing space against Azure
Microsoft本地版本中的产品正在失去针对Azure的空间
or real servers) 或真实服务器 ）开销的情况下转向平台即服务
SSIS is way past its heydays and, my opinion is that it will go away in a few years, it doesn’t really get any new components/features (just those that are used for other software products and get ported, so they can be used in SSIS)
SSIS已经过了鼎盛时期，我认为它会在几年后消失，它实际上并没有任何新的组件/功能（ 只是那些用于其他软件产品并已移植的组件/功能，因此它们可以在SSIS中使用 ）
or will be soon) because even though you can get SSIS in the cloud but ADF is designed with the cloud in mind from day 1. 或即将推出 ）的基于云的ETL平台，因为即使您可以在云中获得SSIS，但从第一天开始，ADF的设计便考虑了云。

A few days later after writing this paragraph, I skimmed through an official Microsoft entry about the new features of SQL Server 2019 and – sadly or not – this part seems to support my opinion:

在写完本段后的几天后，我浏览了Microsoft的一篇有关SQL Server 2019新功能的正式文章，而无论是否可悲，这一部分似乎都支持我的观点：

old-school T-SQL doesn’t go out of fashion in the near future 老式的 T-SQL在不久的将来不会过时

电源查询– MMM，好吃… (Power Query – MMM, yummy…)

How does Power Query come into the picture? It is (again!) a completely different language (or frontend for the M language which is the informal /short/ name for Power Query Formula Language) though if you are lucky you can use the drag & drop interface embedded in Excel or Power BI and at other places.

Power Query如何进入画面？（ 再次！ ）它是完全不同的语言（ 或M语言的前端，它是Power Query公式语言的非正式/ short /名称 ），但是如果幸运的话，您可以使用嵌入在Excel或Power BI中的拖放界面在其他地方。

However, the graphical UI has its limitations as not every functionality of M is accessible. The gap is getting narrower at a steady pace but for the very tricky tasks, handcrafting M code could be your only option. And no matter what the marketing guys at Microsoft say: it is not easy or straightforward to use, it is not that similar to Excel’s expression language. Just see this reference website if you need convincing: https://www.powerquery.io/

但是，图形用户界面有其局限性，因为不是M的所有功能都可以访问。差距正在稳步缩小，但是对于非常棘手的任务，手工编写M代码可能是您唯一的选择。而且，无论Microsoft的市场营销人员怎么说：使用起来都不容易或直接，它与Excel的表达语言并不相似。如果您需要说服力，请访问此参考网站： https : //www.powerquery.io/

编码–现代云时代BI开发人员的生活 (Coding – life of a BI developer in the modern cloud age)

How many languages can a BI developer/data engineer/[future naming of such positions] have the need to use depending on source/target systems? No, despite how it starts, it’s not a joke