趁着周末塞娃进学而思继续“深造”，自己就随笔一篇吧！
今天的话题就聊聊互联互通。大到国家战略“一带一路”要从互联互通做起，近到即将启航的“深港通”实现金融通道的互联互通。于是，在信息爆炸的年代，已经很少有一个业务能够独立孤存，所以数据是必须实现互联互通，只有疏通经络、畅通血脉，才能充分发挥Daa（数据即服务）的真正价值。
可是MongoDB偏偏是个“异类”，说“异类”是因为对于占据绝对市场的SQL平台来说他毕竟是后来者，所以想要和他们互联互通是不能指望大哥们会来拉一把的，否则大哥会担心饭碗被砸了。于是MongoDB需要自强一把，自建桥梁，让懂SQL却又不想学MQL的也能和文档直接对话，这就是今天的主题MongoDB BI Connector--- MongoDB的互联互通2.0版。
开篇之前，需要先声明两点：
-
MongoDB BI Connector功能属于企业版功能，企业版订阅用户可以任意畅游。
-
这并非对社区版用户进行封杀，事实上，对于非企业版用户而言，也是可以免费试用的，试用时功能一个都不少噢。
架构浅析
先来简单聊一下整体BI Connector的架构。简单来说，BI Connector在SQL客户端和MongoDB之间架起了一个互联的桥梁。当SQL客户端发出SQL请求时，实际上是发向BI Connector的，BI Connector对SQL请求做了三步操作，包括Query Planner（查询计划），Query Translator（查询翻译）和Query Executor（查询执行），最终把SQL转换为优化过的MQL，并将请求转发到MongoDB服务器。查询结果呢？自然先返回到BI Connector，但是数据并不真正存放于BI Connector，而是做了一个存储转发的动作，最终返回到SQL客户端发起处。所以每次操作尽管经过BI Connector，数据是不会被保存在BI Connector中的，不考虑延迟的话，基本上数据流是实时的。
通过企业版这么一个互联架构，用户就不用再担心无法用SQL去和MongoDB沟通了，因为BI Connector翻译机器人随时同声翻译处理，无论您用的是大牌Tableau、BO还是小众开源类型，只要会用SQL说话，那就“通杀”。
华丽转身
了解了架构后，我们就来看看BI Connector工作的三部曲，如何进行华丽转身？
三部曲之一：变身
由于MongoDB是文档数据库的鼻祖，其特有的文档模式对于传统关系模型是无法辨识的，因此为了能够让BI工具认识它，首先需要进行脱胎换骨。在MongoDB BI Connector里，内置提供了一个工具mongodrdl，来将需要转换的数据集合或库转换成一个yaml格式的drdl文件。Drdl全称是Document Relational Definition Language，文档关系定义语言。如下图所示，可以指定数据库所在的主机，需要转换的库名或是集合名以及导出drdl文件名，当然还有更多的参数，这里不一一列举了。
一旦变身完成，就看到了下图中后半部分的内容，包括转换后的关系型数据库表名、源MongoDB集合名、每个MongoDB字段和类型以及映射到SQL后了列名和SQL类型。
具体使用中，可以根据导出的结果进行自己修改，如修改导出后SQL列名，或是因为分析并不需要某个字段，就直接编辑删除那个字段。虽然目前还没有图形化编辑drdl工具，但是这种简单操作对大多数专业IT人员来说想来是小菜一碟。
以zips.json为例，我做了一个简单的实验来进行映射导出，结果drdl文件输出样例如下图。
三部曲之二：合体
一旦导出映射定义文件，并进行二次加工处理后，之后的工作就变得非常简单。只需要让BI Connector核心部件将drdl纳入后一并提供服务，那么外围SQL客户端就可以直接和BI Connector进行通讯并获取数据。
这部分合体工作当然不让由mongosqld来完成，通过启动mongosqld服务，提供连接mongodb服务器字符串以及需要合体的映射定义文件就可以了。如果有很多drdl文件的话，也可以指定模式目录，mongosqld会遍历目录下的所有drdl文件并进行一一合体。
合体完毕后那当然就在3307端口处于等待服务状态，等待外围BI工具通过SQL客户端发出的请求。
具体继续对上面导出的danielzips.drdl进行关联合体，得到如下结果：
三部曲之三：游刃
强大的BI Connector一旦成功辨识映射内容，对于BI工具来说，面对mongosqld所在的端口就如同完全面对一个关系型数据库。可以查看数据库，也可以切换数据库查看表，更可以进行标准SQL操作进行查询分析。例如，下面我们通过MySQL客户端连到上面捆绑danielzips.drdl的mongosqld进行一系列的操作：
在上面的操作中，我们可以看到通过MySQL客户端以tcp协议连接到3307端口上进行操作，首先列出了所有数据库。然后use daniel，列出daniel库中所有的表，包括我们映射过去的那张zips表。
然后我用select * from zips，并列出第1行。
再加入条件，select * from zips where pop=55。所有操作和我们平时进行的SQL操作毫无区别，所有对于熟悉SQL的操作人员来说绝对是游刃有余！
要素处理
不知道看官有没有注意到，这个变身---合体---游刃中最有趣的部分在哪里？事实上作为文档模型的MongoDB，有些模式是关系型数据库所不具备的，例如嵌套和数组。那在变身过程中到底是如何处理嵌套和数组的，这部分还是有必要做个简单说明的：
嵌套处理：
关于嵌套实际上在前面zips文档里面已经有体现，地理位置就是一个二维向量嵌入在zips文档中的：
在变身中，所有的嵌入会另建一个新的column而被拆开，也就是变成在关系型表中的loc.y和loc.x两列，这样简单的分拆就解决了嵌入的问题。如果多级嵌入就变成多级扩展，例如loc.x.level2，loc.x.level2.level3等等。
数组处理：
虽然同样的关系型数据库不支持数组，但是mongodrdl对于数组的拆分略有不同。下面就一个例子来说明一下是如何处理的，下图中有一个文档foo.foo，其中towns字段是一个数组，那么用mongodrdl进行转换后会发觉实际上产生了两个关系型数据库表，一个是不含foo表，但是不含towns信息。另一个是foo_towns，把数组解开同时含了数组的位置索引信息和foo表的其他信息。这样通过$unwind操作符进行的聚合操作轻松解决了数组分解的问题。
进化
事实上，MongoDB之前就有过一个BI Connector 1.x的版本，如今进化到互联互通2.0，到底有何不同呢？
简单来说，主要优化在于以下几个方面：
1. 用户认证部分可以直接利用MongoDB的现有认证方式，而不需要另外建立认证数据库。
2. 双向支持SSL。
3. 对于Pushdown操作和Aggregation操作进行了优化。
例如，新版本支持部分Pushdown，假设select中用了reverse函数，而显然MongoDB不支持reverse函数，这部分就不会Pushdown到MongoDB，而是把其他部分Pushdown到MongoDB，而这部分reverse操作会在BI Connector拿到MongoDB服务器返回的数据后在内存中进行操作加工完成reverse动作。
又例如，转换中用到了$unwind，也用到了$match，考虑到聚合效率，会将$match先处理，然后再进行$unwind操作，这样可以提升一部分性能。
部分细节内容有兴趣的可以等正式发布后继续去尝试一下。新事物发展总是有一个过程的，或有部分不如意的也希望多多反馈。MongoDB发展之迅速是有目共睹的，希望大家一起参与进来协力发展，虽然短期赶上Redhat是有些痴人说梦，但是作为一个“潜力股”应该是个不争的事实。
记得前几天看了一篇新闻稿“世界唯一年盈超10亿美元的开源公司，看看它是怎么赚钱的”，其中提到那么一句“Whitehurst(Redhat CEO)并不是对所有的初创开源公司的发展都怀有悲观态度。比如MongoDB，Whitehurst就很赞同它的商业模式。”
无妨到MongoDB官网尝试一下企业版及其配套管理工具，BI Connector就在其中！（注：截止发文，2.0尚未发布，官网目前下载版本为1.1.3）
最后，祝各位周末愉快!顺便提个醒：
-
10/26日 20:00-21:00，免费原厂讲座 内容：MongoDB索引原理与优化（中文），请大家有空捧场，应该是会有些收获的
-
本人稍稍把微信菜单改版，今后文章会逐步纳入到往期精彩菜单中的各个分类子菜单，方便需要者浏览。
奕名小惊
2016/10/15
转自：
http://mp.weixin.qq.com/s?__biz=MzAxNTQyMzA4NA==&mid=2650723429&idx=1&sn=3a8b3ab1f14838fc05fa9fd15f6e2526&chksm=838e3766b4f9be7066262715ead0cd89f4e90b0bb458742648bd6ffef7b3f7716159fccc92c9&mpshare=1&scene=23&srcid=0314ZacaB0VJep8ycGbJ70AJ#rd