在 2017 杭州•云栖大会 - 阿里大数据分论坛上，阿里巴巴专家发表了主题为《阿里巴巴数据服务和数据产品开发平台》、《阿里巴巴全域数据建设》的演讲，分享了阿里在大数据领域沉淀的技术能力和应用实践，大家可以到网上搜索到演讲实录。
这类技术演讲一般时间有限，因此演讲者会在很短的时间内抛售出很多的概念，让你应接不暇，诸如阿里在数据层面深耕这么多年，你可能听懂了，也可能一知半解，这都很正常。
一个演讲，如何将这些概念首先还原到事物的本源，如何与自己的既有知识框架形成映射，如何用自己的语言和理解重新还原出来，从而发现价值点，能够为我所用，对每一个人都是一个挑战，听报告还是要“取其精髓，去其糟粕”。
这里的糟粕不是真的糟粕，而是指人家好的东西并不一定适合你，每个人都应依赖自己的知识框架去权衡这么做的利弊，依据企业的实际去选择性的吸收。
就从《阿里巴巴数据服务和数据产品开发平台》这个PPT开始吧。
Part 1:-目录
演讲的内容包括数据赋能的背景、数据服务和数据产品开发平台三部分，笔者第一反应想到的是这些东西处于大数据体系的什么位置，比如一般大数据架构分为数据采集、数据处理和存储、数据服务（或开放），数据应用,数据管理等层次，显然它应该处于数据服务（或开放）这一层，数据产品开发平台其实也是数据服务的一种形式，因此不要望文生义，差别仅在于服务的方式不同，这里的数据服务不能跟通常意义上的数据服务划上等号，特别强调数据产品开发平台也许是演讲者为了突出这个主题。
Part 2:-数据赋能的背景
阿里最赚钱的是商铺位置和广告，显然，数据产品最核心的服务对象就是他们说的B类客户，生意参谋算是很成功的一个应用，被引用的也很多，现在其服务的对象扩展到了电商、物流、健康、文娱、金融，以及云计算，能否持续打造出好的数据产品和服务，挑战还是很大的。
Part3-阿里巴巴大数据体系
阿里的数据服务和数据产品开发平台构成了服务的核心，数据服务包括了基础数据服务、标签画像服务、人群透视服务、算法模型服务等，这个后面会解释，这里特别提了下最终产出是什么，PPT上面列出了四个，数据产品、数据大屏、数据报表及数据分析，其实这四者这间有着千丝万缕的联系，从逻辑的角度看，一般BI应用按照展现形式可分为报表、多维分析、即席查询三种，你可以对应到这里的数据报表、数据分析, 数据大屏实际是个数据产品，而数据产品往往是报表、多维分析、即席查询、图表及页面等的组合，记得以前的数据魔方核心就是一个多维分析，当然其实怎么分都可以，理清概念是为了看清本质。
OLTP系统里的中间件是非常核心的东西，那么对应到OLAP系统，数据服务（广义）就是某种意义上的中间件，其往下对接计算和存储层，往上要服务好业务，是业务的使能者，很多企业直接跨过这一层做终极数据产品，当然也是可以的，但一旦要做成规模，必然要往服务方向演进，这是一种平台化思维，阿里近年来极大关注中台的建设，具体可以参考阿里的一本技术中台的书，很多企业其实也有这一层，差距就在于做的厚度。
下面分别解读下数据服务和数据产品开发平台。
Part4-数据服务
阿里提到数据服务要解决四个问题， 一是数据在业务层的全域流通，从客户的角度看就是让客户能便捷的访问到跨域的所有数据，这里蕴含着跨域数据打通、数据字典、数据操作等系列能力，二是防止数据接口的重复建设，这里蕴含着数据标准化、数据发布系统约束及机制流程上的要求，三是数据获取的及时、稳定高效，蕴含着数据处理、调度、监控及数据质量管理等系列自动化能力的打造，前三者都是从数据本身说数据，从基础能力保障的角度看问题，数据能力延伸指的是价值出口。
数据服务的四种核心能力，包括基础数据获取，标签画像服务、人群透视服务及算法模型服务。
基础数据获取其实就是便捷的取数服务能力，通过配置或原始SQL能获取到所需的任意形式的数据，应该是企业内最为频繁使用的数据服务，笔者以前做自助取数的模型，感觉主要挑战在于日益灵活复杂的取数需求与人工经验设计的标准化模型及有限指标维度粒度的矛盾。
标签画像服务的基础是要打造一个客户标签库，包括身份特征、短期行为、长期偏好、位置特征、社交信息等方面内容，其通过服务形式对外提供查询接口，比如为前端提供即时客户画像，方便进行业务推荐，标签的主要挑战就是数据能力和建模能力，当然这是数据建模师的职责，但数据产品最核心的竞争力始终是数据，否则，就不用在产品面前特意提数据了。
人群透视服务笔者猜测是个多维查询服务，选择多个维度，圈定一波特定用户，这类需求非常多，但要封装成服务还是需要一定的业务积淀，多维服务另一个挑战就是性能，因为使用场景往往是在线的，要所见即所得，诸如DSP等广告服务平台最核心的就是灵活的用户删选能力和在线分析能力，比如要针对100个维度进行条件设置并删选出用户群，实时计算出用户量，方便用户决策。
算法模型服务就是把算法封装成服务，方便外界调用，算法一日千里，开源是跟上时代最好的方式，但企业内最多的应用场景可能就那么几种算法，因此从数据集成的角度讲，性价比还是不错的，阿里有自己的平台，必须为这个平台定制算法，比如解决算法的并行问题，这是很大的工程。
那么，如何实现这些数据服务呢？以下是数据服务的架构。
作为这个PPT里最有技术含量的片子，笔者也好好学习了下，自上而下这么解释：
Portal：这个是使用人员的管理界面，演讲者的原话是“能够获取到对应的数据，极大缩短用户发现数据、获取数据以及使用数据的路径”，说的很好，要操作四类数据服务肯定涉及到查询服务、配置服务啥的，肯定都是可视化操作，这是个数据的服务超市。
HSF:是阿里使用的分布式的远程服务调用框架，要了解可以去看《阿里巴巴中台战略思想与架构实战》这本书，里面有详细的阐述，阿里所有的服务调用都通过HSF，包括服务发现，注册，调用等等，这里数据服务也调用了这个能力。
DSL（Domain Specified Language）领域专用语言：说到DSL笔者想起了很多年前集团公司规范中提到的伪代码，当时考虑到各省业务口径不同，数据仓库种类不同，SQL语法也有不同，各省应用全网移植困难，考虑全网能否进行原语的统一，因此提出了这个概念，其与DSL有异曲同工之妙，都是应用驱动的产物。
DSL主要解决使用者（领域专家）和构建者的语言不通问题,阿里通过建立一套DSL，把用户获取数据的标准和规范进行了统一，也就是为调用四大服务提供了一套标准的阿里的语言，其包括四个方面，QueryEngine 实现所有跟查询相关的能力输出；PushEngine 提供实时数据推送的能力；DAG 可视化，可配置编排业务逻辑，Algorithm Engine 输出算法和人工智能的能力，就是用一种类似SQL的语法实现这些服务能力的灵活调用，由于是自己定制的，其能实现的功能远超SQL的一般语法。 大数据时代，DSL对于很多企业意义重大，因为当前很多大数据平台采用的是混搭的方案，技术百花齐放是为了解决各类业务场景对于特定数据服务的要求，但也增加了使用的难度，因此让DSL屏蔽底层差异，实现数据的透明访问，也是一种好的解决思路，笔者企业的数据管理平台也有类似的做法。
支撑这个DSL的底层技术包括Meta Management，Parser，Explain、Model Management及ML/DL。
Meta Management即元数据管理，有哪些对象，比如某张表某个字段是否有，肯定需要有个数据字典可以查吧。
Parser即语法解释器，比如查询DSL它会解析成 select 类,诸如此类。
Explain：即执行计划，如果要分析某条SQL的性能问题，通常我们要先看SQL的执行计划，看看SQL的每一步执行是否存在问题，看懂执行计划也就成了SQL优化的先决条件。
Model Management：字面意识是模型管理，具体内涵不得而知，希望有人能解释。
ML/DL即机器和深度学习，非常容易理解，用DSL调用机器学习函数。
下面给出了一个DSL的示意，笔者理解是通过右边的配置自动生成SQL，里面定义有输入输出。
Part5-数据产品开发平台
这里提到构建数据产品开发平台最核心的目的就是，让非专业的开发人员，也可以根据自己的需求，来搭建数据产品，从而实现自己使用数据的目的。大家都知道开发一个产品需要UI/UE，前后台服务，数据处理等技能，这个平台希望非专业人士能搭积木一样打造出贴合业务要求的数据产品，就像3D打印一样，我只做设计，其他全部自动化。
很多企业的数据团队最大的挑战是业务人员大量的个性化取数及报表，笔者刚进公司的时候主要负责报表取数，以前取数一个礼拜业务人员也能接受，但随着市场发展，业务人员要求越来越高，从一周到几天到一天，直到希望马上就要，永远不会满意，因为市场不等人。
其实最好的解决方案就是“授人以鱼不如授人以渔”，这是应对变化的根本大法，我们也开发过自助取数和自助报表工具，但数据组合的无限性、平台性能及产品开发能力限制使得这类工具只能解决局部的问题，比如复杂的取数多维分析就无法很好支撑，后来给市场人员开了租户，有能力的自己去取吧，才逐步缓解了这个问题，但租户这种模式不太友好，对于人员的技能要求不低，推广的范围有限。
现在很多企业开始搞大数据对内运营，建议吸取这种思路，用“搭台唱戏”的服务模式为业务赋能， IT主要工作是搭好台子，做好产品，不要疲于奔命去满足一个个需求，让业务人员自己到台子上跳舞是大数据应用百花齐放的解决之道，只有业务人员最懂自己需要什么。
随着大数据技术的进步和管理能力提升，也许自助取数，自助报表真的能满足80%甚至90%的需求，而且响应能力能达到很高的水平，那真的是数据技术驱动业务，一个简单的自助取数工具，不仅仅是解决存量需求的问题，而且会极大的激发新需求，价值是无法估量的。
阿里列出了当前支撑的四种产品类型，看数据、分析数据、非开发人员自助实现数据需求、跨端，看数据估计类似于自助报表，分析数据类似于多维分析、非开发人员自助实现需求不知道具体怎么个形式，难道是自助取数？跨端估计就是多屏适配展示。
演讲里面特别提到了产品的构建过程，涉及应用层和服务层的配合，应用层面通过样式、布局、组件和分析思路来构建，服务层按照业务逻辑做好数据的提取配置。
笔者使用过类似的产品，比如给你个设计模板，把一些排版、图表，文字，表格等对象拖到工作区域，然后设计指标和维度，这就是所谓的分析思路吧，任何一个组件如果涉及到数据对象，就从服务层里面关联，最后发布即可。
但这里有几个关键问题，是笔者以前觉得比较困难的。
一个是数据的标准化问题，要让使用人员能直接配置操作数据，诸如指标等的定义必须是清晰的，没有歧义的， 由于任意一个指标跟维度结合可以形成新的指标，指标之间往往存在错综复杂的关系，一旦叠加了多个维度，指标管理就会失控，因此必须有一套好的数据管理办法，标准化管理成本其实挺高，需要强力的组织保障，否则就是自己过家家，做不大，阿里的数据管理体系里有提到OneData、OneDefne等做法，就是需要在机制、研发流程及系统层面去约束。
另一个就是数据产品的设计体验，即使诸如自助取数、自助报表这一类相对简单的，一旦可配置的要素多了，就会变得复杂，再加上数据周期，调度，测试等一些工作也要做吧，无形中会加大产品设计的难度，因此使用的对象更适合数据分析师之类有一定数据分析或IT技能的角色，阿里仅仅提到这个平台的使用对象是非开发人员，是否包括业务人员是打了个问号的。
应该来讲，自助报表、自助取数及多维分析这类数据产品，共性要素相对多，业界也有较多实践，因此搞个IDE实现相对靠谱，但不同行业的数据产品要求其实千差万别，即使诸如位置这类应用较多的数据产品，要搞个IDE其实也有点难，阿里现在搞新零售，希望服务千万企业，线下分析也会越来越多，而产品化的是对于业务和数据深入理解基础上的抽象，因此，数据产品开发平台任重而道远。
最后PPT提到了数据产品开发平台的应用，主要包括运营、决策分析、活动营销及商业应用，前三者在一般的企业都有，大多的解决方式都是以需求的方式通过取数及报表实现，其响应速度显然跟自己DIY不可同日而语，笔者相信阿里的这类数据产品是比较强大的，可惜没看到具体案例，最后的商业应用不确定性最大，既是挑战也是机遇吧。
这个PPT提到了很多好的做法，那么，除了这些，数据服务和开发还有哪些重点问题需要关注呢？这里提四点，欢迎探讨。
一是数据与最终产品的互动问题，这是中台的核心问题，比如前端产品的数据模型谁来做，如何让前端好的模型能沉淀到中台来，如何能让中台的团队尽可能的理解前端各类业务？如何能与前端形成好的互动？举个例子，中台数据团队会跟着业务团队去拜访客户吗？这些对于做好一个产品研发平台至关重要，现实中往往会脱节。
二是数据加工能力问题，数据产品以“数”为核心，硬技术是一方面，但在解决了一些基本的技术问题后，数据才是产品差异化所在，对于这一点笔者是有深刻体会的，比如针对选址分析的一些产品，客户最关注的还是比如职业标签覆盖率如何、位置精准度如何等核心的问题，否则展示的数据就有失偏颇了，但数据建模同样存在前端和中台的衔接问题。
三是数据服务和产品效益评估问题，数据服务和产品的完善永无止境，总能做得更好，因此还是讲究投入的性价比，从对外的角度讲，收入是一个评价指标，比如数据魔方直接端到端做掉还能核算清楚，但前端团队利用数据服务或开发平台创造的间接效益就很难衡量了，从对内的角度讲，更加是一个难以量化评估的问题，难道是服务调用次数？这个问题长期困扰很多企业，BI由此受到质疑，大家都知道需要投入，但投入多少还是要有个依据。
四是数据服务和产品开发平台推广问题，酒香还是怕巷子深，企业大了，层级多了，任何技术服务的推广成本其实是很高的，比如优酷新上线了一个数据，对于分析用户偏好有用，怎么让其他前端知道和利用好它？蛮想知道阿里的运营推广方式，这在传统企业挑战很大，数据集中是初级阶段，大家能用好集中的数据才是终极目标。
由于演讲的PPT可获得的信息有限，笔者的解读肯定有以偏概全、理解不到位的地方，大家见谅，但阿里对于数据服务、数据产品开发平台的理解和做法，对于我们做数据的人，的确有很大的启示意义。
/1 
发表于 2017-10-30 11:00:51
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
转播
分享
淘帖
赞
踩
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜