| 导语 云原生时代，微服务业务众多，数据在一个个孤岛中，作为云平台研发人员，我们怎么快速支持纷繁多彩的运营需求？对于 TCE，我们又怎么在私有云的场景下从根本上解决这个问题？本文为你揭开神秘面纱
✦
✦
没有数据可视化算什么数字化...
云原生时代业务通常会拆成多个细小的服务，这样业务间各司其职，耦合低，迭代快，这是微服务的优势，但是也为横向运营运维带来了难度，想要运营的好，我们不能等到出问题的时候才去补救，这就要求我们能够及时准确地感知观测到这些散落在各地的服务，这就是各种运营可视化页面的作用所在。
而具体到到私有云平台来说这个问题更为复杂，一方面云上应用种类繁多，IaaS、PaaS、SaaS，复杂度和纵深各不相同，运营指标天差地别；另一方面私有云跑在各类客户现场，我们需要从根本上解决需求各异、指标不一、展示灵活、难以标准化的难题，让客户最终在界面上按需自行运营可视化。
说起来容易做起难，高大上的大屏在哪里？
我们就从这个“普普通通”的需求来入手，它要展示的是 CVM 不同维度下的各类资源指标以及运营的趋势。它通常反应的是一类指标 S 随时间 T 的推移而发生的变化。指标 S 来自于一个接口的字段 A；T0、T1、T2……TN 具有相同的时间间隔。
针对这个需求，我们一般的处理模式是：
1、需求方(客户)提出诉求；
2、开发一个定时采集服务负责周期性的调用接口，并打上时间戳保存到数据库当中；
3、再开发一个接口服务，它会根据需要把一定时间跨度的 A 以一定间隔聚合求取平均值，装配成列表，返回给前端；
4、前端同学，设置折线图控件绑定接口模型，配置x轴y轴到模型字段的映射关系；
5、...
这里的问题是，在 TCE 我们有几十上百诸如 CVM 的产品，每个产品都能从各个维度衍生出各不相同的运营需求，然后还要乘上各种侧重不同的客户诉求。
按照传统的方式，我们只能不断投人、投时间、排期。。。来应对这些无尽的技术重复工作，很不“降本增效”，甚至不可行。
搞定可视化，这几步就够了
那么，怎么才能从根本上解决问题呢？或者说问题在哪里？
问题在于，运营类可视化需求充斥了大量的重复、“低端”、重复的编码工作，而且这些工作极大地妨碍了真正业务的落地。我们要做的自然就是
从数据的流转角度，我们期望一站式、系统性地解决这些阻碍性的工作。
- 采集难？：数据采编平台（Flakeminer）来收取信息—可视化编辑采集作业，一站式采集，加工，清洗，入库；
- 接口麻烦？：数据中台（Flake）来分析及预测—文档式数据系统，统一且灵活的数据查询语言 FQL，甚至提供算法预测；
- 海量页面？：可视化中台（神工）来自由组合搭配—拖拽式页面装修搭建，各类控件自由装配，所见即所得；
Talk is cheap, 下面我们就来看看怎么从零一步步搭出上面的可视化页面。
1、需求分析
我们不妨以展示 CVM 宿主机内存、磁盘、CPU 使用量状态这一资源容量平台的真实需求为例。
除了需要展示内存、磁盘和 CPU 的当前状态，还要展示历史7天的趋势记录和未来7天的预测。
我们现在有的只是 CVM 业务的云 API、DescribeHosts 可以查询到 CVM 宿主机信息。
问题在于:
1、一次只能查一个地域的宿主机，我们得先调用一个 DescribeRegion 接口获取所有 Region 和 Zone 信息。然后才能去调用 DesribeHosts 接口；
2、分页，考虑不能对业务影响，一次不能拉太多；
调用之后，我们有了全部 Region 的 CVM 信息。通过 ZoneId、IsOnline、HostStatus 来求和 HostResource 字段中的 CPU、Mem、Disk 等相关数值，便可以得到我们需要的指标信息；别忘了时序趋势数据，我们需要对 CVM 接口周期性的采集。
2、可视化编排采集任务
简单来说，我们可以把数据的采集，分为数据获取(云 API)、数据处理(无码/低码)、数据入库这三种类型的任务组成的 DAG 图，而 Flakeminer 提供了可视化的逻辑编排工具，来让你轻松拖拽实现。
对于刚才的问题，
1、拖拽实现前后接口的调用：DescribeRegion -> DescribeHosts；
2、循环，更是简单配置即可；
最后的 unwind 节点代表我们把 DescribeHosts 的结果按照其中的 HostResource 展开到外层属性进行属性拍平。
如此设计完采集流程，交给采集平台执行，我们就会得到全部 Region 下 CVM 的 CPU 等信息了。
3、会 SQL 就能查数据，FQL 让你查的更爽
实际上我们上述采集入库的是 MongoDB，我们是不是可以直接去拖页面了？
是，也不是～
我们可视化低码系统神工装修页面，拖拽控件并使用 FQL 为控件绑定数据模型。
但是，我们现在这里缓一缓，来聊聊我们为什么不直接使用 MongoDB 的查询语言，而是 FQL —— 这种我们创造的类 SQL 的方式。
实际上业界经过 Mongo 的 JS 接口语法洗礼之后，发现还是 SQL 这种声明式的语言更有表达力和更低的门槛，即便没有任何编程经验也很容易在了解基本规则之后快速上手。我只需要表明我在什么条件下要什么样的数据，系统程序理解这些意图自动化完成的查询和组织方式返回就好，而且 SQL 也更适合我们运营类对数据灵活多变的查询需求。
那 FQL 又是什么？
尽管 SQL 能在大多数条件下完美地解决 TCE 的数据查询需求，但 SQL 天生是为关系模型设计的，由于文档模型的结构通常并不像关系模型那么平坦，字段类型也不确定，如果又希望包括子属性在内的任意属性都可以参与计算，SQL 此时就不能很好地工作，加之针对运营类数据可视化场景，又有时序，甚至预测这种复杂场景，我们需要创造我们自己的语法——FQL。
3.1、时序查询
还是这个图，Flake 通过扩展的 “GROUP BY EVERY” 语法糖则助力了时序数据场景下查询，这才造就了“运营趋势”。
SELECT STRFTIME(ctime) AS ctime, AVG(TotalCpu) AS Total, AVG(UsedCpu) AS Used FROM rov_cvmWHERE Region='chongqing' GROUP BY EVERY 2*hour(ctime) # 注意这里通过此语法，可以很容易的写出诸如下列任意尺度上的时序数据聚合。
EVERY day(ctime) #每天EVERY 2*hour(ctime) #每2小时EVERY 15*minute(ctime) #每15分钟3.2、高阶能力：预测
还记得我们的初衷么，我们需要掌握又快又准的运营数据才能帮我们做好业务的运营。
如果，我们提供预测，让你能够未雨绸缪？
针对刚刚通过时间聚合出来的趋势数据，进行数据预测，向后预测7个点位并保留原始趋势数据中的末尾7个点位则可以通过如下语句实现。
ALGO my_forecast(y=cpu, date=ctime, forward=7, keeptail=7)USING SELECT avg(UsedCpu) AS cpu, ctime FROM rov_cvm WHERE region='chongqin' AND ctime>strptime('2022-01-01') GROUP BY EVERY day(ctime)当然，FQL 扩展的语法远不止上述提到的两个。这些扩展出来的语法，都是经过 TCE 众多数据看板类需求的沉淀和归纳而来。
4、低码神工——动动鼠标就能拖页面
有了数据，也有了查数据神器 FQL，终于来到了最后一步，让数据可视化出来。
运营类许多数据大屏、数据看板，这些页面当中的控件往往是相同的，不同之处仅在于排列和布局。这其实是组件化页面搭建场景落地的绝佳机会。为此，我们提供了可视化低码系统神工。
不需要懂 React、Vue，甚至也不需要前端仔。
1、从左侧的物料中选择合适的图表组件;
2、绑定数据, 神工抽离了图表的数据源为单独模块，支持上述数据中台的FQL，也支持普通云API等;
3、配置相图表属性，绑定我们录好的数据源;
4、Done !!!
