精华内容
下载资源
问答
  • 数据中台,什么是数据中台

    千次阅读 多人点赞 2019-12-05 11:53:07
    数据中台被誉为大数据的下一站,由阿里兴起,核心思想是数据共享,并在 2018 年因为“腾讯数据中台论”再度成为了人们谈论的焦点。在 3 月 15 日 ThoughtWorks 技术雷达峰会上,关于数据中台的话题也获得了众多参会...

    导读:

    数据中台被誉为大数据的下一站,由阿里兴起,核心思想是数据共享,并在 2018 年因为“腾讯数据中台论”再度成为了人们谈论的焦点。在 3 月 15 日 ThoughtWorks 技术雷达峰会上,关于数据中台的话题也获得了众多参会者的热烈关注。如今似乎人人都在提数据中台,但却不是所有人都清楚数据中台到底意味着什么。数据中台是只有大厂才需要考虑的高大上的概念吗?普通企业该不该做数据中台?数据中台的出现会给现有数据从业者们带来颠覆式的挑战吗?

    数据中台不是大数据平台!

    首先它不是一个平台,也不是一个系统,如果有厂商说他们有个数据中台卖给你,对不起,它是个骗子。

    要回答数据中台是什么,首先要探讨一下中台到底是什么。虽然没有明确的定义,但是作为理工直男,我们可以先把中台看作是一种中间层。既然是一种中间层,那么中台确实是一种十足技术用语,我们可以完全从技术角度来探讨了。

    我们可以应用 Gartner 的 Pace Layer 来理解为什么要有中间层,这样可以更好地理解中台的定位和价值。Pace Layer 里提到,可以按照事物变化的速度来分层,这样可以逐层分析并设计合理的边界与服务。

    在数据开发中,核心数据模型的变化是相对缓慢的,同时,对数据进行维护的工作量也非常大;但业务创新的速度、对数据提出的需求的变化,是非常快速的。

    数据中台的出现,就是为了弥补数据开发和应用开发之间,由于开发速度不匹配,出现的响应力跟不上的问题。

    数据中台解决的问题可以总结为如下三点:

    1. 效率问题:为什么应用开发增加一个报表,就要十几天时间?为什么不能实时获得用户推荐清单?当业务人员对数据产生一点疑问的时候,需要花费很长的时间,结果发现是数据源的数据变了,最终影响上线时间。

    2. 协作问题:当业务应用开发的时候,虽然和别的项目需求大致差不多,但因为是别的项目组维护的,所以数据还是要自己再开发一遍。

    3. 能力问题:数据的处理和维护是一个相对独立的技术,需要相当专业的人来完成,但是很多时候,我们有一大把的应用开发人员,而数据开发人员很少。

    这三类问题都会导致应用开发团队变慢。这就是中台的关键——让前台开发团队的开发速度不受后台数据开发的影响。

    史凯总结说,“数据中台是聚合和治理跨域数据,将数据抽象封装成服务,提供给前台以业务价值的逻辑概念”。

    如下图所示:

    DData API 是数据中台的核心,它是连接前台和后台的桥梁,通过 API 的方式提供数据服务,而不是直接把数据库给前台、让前台开发自行使用数据。至于产生 DataAPI 的过程,怎么样让 DataAPI 产生得更快,怎么样让 DATA API 更加清晰,怎么样让 DATA API 的数据质量更好,这些是要围绕数据中台去构建的能力。

    数据中台和数据仓库、数据平台的关键区别

    这是现在数据行业大家经常讨论的问题,到底数据仓库、数据平台和数据中台的区别是什么。

    概括地说,三者的关键区别有以下几方面:

    1. 数据中台是企业级的逻辑概念,体现企业 D2V(Data to Value)的能力,为业务提供服务的主要方式是数据 API;

    2. 数据仓库是一个相对具体的功能概念,是存储和管理一个或多个主题数据的集合,为业务提供服务的方式主要是分析报表;

    3. 数据平台是在大数据基础上出现的融合了结构化和非结构化数据的数据基础平台,为业务提供服务的方式主要是直接提供数据集;

    4. 数据中台距离业务更近,为业务提供速度更快的服务;

    5. 数据仓库是为了支持管理决策分析,而数据中台则是将数据服务化之后提供给业务系统,不仅限于分析型场景,也适用于交易型场景;

    6. 数据中台可以建立在数据仓库和数据平台之上,是加速企业从数据到业务价值的过程的中间层。

    数据仓库具有历史性,其中存储的数据大多是结构化数据,这些数据并非企业全量数据,而是根据需求针对性抽取的,因此数据仓库对于业务的价值是各种各样的报表,但这些报表又无法实时产生。数据仓库报表虽然能够提供部分业务价值,但不能直接影响业务。

    数据平台的出现是为了解决数据仓库不能处理非结构化数据和报表开发周期长的问题,所以先撇开业务需求、把企业所有的数据都抽取出来放到一起,成为一个大的数据集,其中有结构化数据、非结构化数据等。当业务方有需求的时候,再把他们需要的若干个小数据集单独提取出来,以数据集的形式提供给数据应用。

    而数据中台是在数据仓库和数据平台的基础上,将数据生产为为一个个数据 API 服务,以更高效的方式提供给业务。

    数据中台应该具备什么能力?

    大数据和人工智能大火之后这几年,很多人一直在提一个说法,那就是“数据是新的石油”。但史凯的观点却有些不同,在他看来,数据不等于数据资产,如果没有从业务的角度对数据进行规划,再多的数据也无法产生价值。

    史凯认为数据中台最核心的一个关键组件是数据资产目录。“我们认为,一个企业的数据要能够充分发挥价值,很重要的一个前提条件就是这个企业的数据结构和数据资产目录是对整个企业开放的。所有人都能够通过这个资产目录了解公司有哪些类别的数据、包含什么属性、源数据由谁管理,这样就可以快速搞清楚这些数据是不是自己需要的。但数据本身可以不开放,因为数据是有隐私信息和安全级别的。”

    大企业内部业务众多,不同业务可能存在很多重复数据。所谓的数据资产目录就是把数据的模型去重、归一、梳理,变成一个树状结构,这个树状结构不直接对应数据库中的字段。以航空货运为例,其数据资产可能包括货机、客运机的辅舱,一架货机就是一个数据资产目录的节点,而货机的各种属性(如货机型号、空间大小、年份等)就是这个节点下面的数据模型。数据资产目录做的事情就是从业务层面出发制定数据标准,将企业业务相关的数据资产模型抽取出来,这跟后面用什么数据库去存储、用什么结构去存储、存成结构化还是非结构化都没有关系。它相当于把企业的业务从数据层面做了一个梳理,用数据的语言把企业的业务模型还原出来。数据资产目录做好之后,后面才是用什么技术手段、从哪里提取数据来映射到这个数据资产目录。

    除了开放,数据资产目录还应该具有标签描述、可检索,这样才能最大程度地方便真正使用数据的人,以最快的速度找到他们需要的东西。

    在 ThoughtWorks 提出的精益数据创新体系中将企业所需要具备的数据能力概括为以下六种,具备了这六种能力,企业才具备成为数据驱动的智能企业的基础,而这些能力的承载平台,就是数据中台:

    1. 数据资产的规划和治理

    做中台之前,首先需要知道业务价值是什么,从业务角度去思考企业的数据资产是什么。数据资产不等同于数据,数据资产是唯一的,能为业务产生价值的数据。 对于同一堆数据,不同业务部门所关注的数据指标可能完全不同,怎么让各个跨域的业务变成统一的标准,就需要规划企业的数据全景图,将所有有可能用上的、所有对企业有可能有价值的数据都规划出来,最终梳理出企业的数据资产目录。在这个时候不需要考虑有没有系统、有没有数据,只需要关注哪些数据是对企业业务有价值的。这一层不建议做得太细,太细就难以形成标准,不能适用于多个场景了。数据治理是数据中台很重要的一个领域,ThoughtWorks 认为在现在业务边界消失、需求快速变化的情况下,企业需要具备精益数据治理的能力——Lean Data Governance。传统的中心化、事前控制式的数据治理方式,要改变为去中心化、事后服务式的治理方式。

    1. 数据资产的获取和存储

    数据中台要为企业提供强大的数据资产的获取和存储的能力。

     3. 数据的共享和协作

    企业的数据中台一定是跨域的,需要让所有的人都知道数据资产目录在哪里。不能因为数据安全,就不让大家知道企业有什么数据。没有共享和开放,数据没有办法流动起来,没有流动的话数据的价值产生的速度就会非常慢。所以在数据安全的基础上,企业的数据资产目录要对利益相关者、价值创造者开放,要让业务人员能够做到“Self-Service”。

      4. 业务价值的探索和分析

    数据中台不仅要建立到源数据的通路,还需要提供分析数据的工具和能力,帮助业务人员去探索和发现数据的业务价值。一个好的数据中台解决方案中需要针对不同业务岗位的用户提供个性化的数据探索和分析的工具,并且在此基础上一键生成数据 API,以多样化的方式提供给前台系统。

    1. 数据服务的构建和治理

    数据中台需要保证数据服务的性能和稳定性,以及数据质量和准确性,还需要具备强大的服务治理能力。数据中台是一个生态平台,在数据中台上面会不断生长各种数据服务,所以从一开始就构建好数据服务的治理结构是非常重要的,数据服务需要可以被记录、可被跟踪、可被审计、可被监控。

       6. 数据服务的度量和运营

    如果数据中台最终只是做到把数据给到业务人员,那它就只是一个搬运工的角色。数据中台还需要具备度量和运营数据服务的能力,能够对中台上提供的数据服务及相关行为持续跟踪和记录,包括哪些数据服务被哪个部门用了多少次等,通过这些去度量每一个数据服务的业务价值。

    史凯认为,数据中台是一个需要用互联网思维去经营的利润中心平台,数据中台的经营分析人员需要分析业务,了解为什么今天上午这个财务部门的人用了数据中台、调用了十次,下午他不用了,原因是什么,调用了这些数据服务的人通常还会调用哪些其他的数据服务。这些都需要相应地做记录、做日志、做分析,要把数据当做像电商平台一样去经营,然后实时地根据这些业务行为数据去提醒数据服务提供方,调整、改变、优化数据服务,这才是可经营的数据中台,也只有这样业务部门才能得到最快的支持和响应。

    为什么人人都需要数据中台?

    数据中台并非只有大公司才需要的高大上的玩意。

    ThoughtWorks 从 2017 年到现在,已经帮助多家大型国内外企业建设数据中台,其中有体量巨大的企业级数据中台,也有部门级的小数据中台。

    “未来所有的企业核心都会变成加工数据的企业,而数据中台是数据价值化的加工厂,所以所有的企业都需要数据中台的能力,数据中台一定是未来每个企业的标准配置。”

    在史凯看来,数据中台并不意味着“大而全”的数据平台。根据企业的规模和业务的不同,数据中台可大可小,规模、复杂度可能都不相同,但它对业务产生的价值是一样的。

    当企业评估自己是否应该建设数据中台时,应该从哪些方面来考虑?史凯认为,从战略角度来说,每个企业都需要建立自己的数据中台;从战术角度来说,当企业发现自己的数据开发利用的速度和应用开发的速度不匹配的时候,就需要考虑构建数据中台。

    原来很多企业在做应用系统的时候,什么都不考虑直接上单体架构,一上来就先做数据库,然后在上面建应用。ThoughtWorks 建议现在的企业,即使不做数据中台、不去立一个叫做“数据中台”的项目,但是在做应用的时候,最好把这个应用分成三层,业务层、数据中台层、源数据层,在一开始做应用的时候就把三个层次抽象出来。

    数据质量差所以做不了数据中台?No!

    历史遗留的数据质量问题经常让大家对数据的利用和价值产生质疑。2018 年,史凯在与不同企业沟通过程中经常听到的一句话就是,“我们现在还没有到利用数据这一步,因为(应用系统中的)数据质量太差”。

    每次听到这句话,史凯脑子里就好像听到了另外一句话,“还没到培养孩子的时候啊,孩子太小了”。

    不能因为数据质量差,就不去利用数据。恰恰是因为没有去做后面的事情,所以数据质量才差。而且也不能因为数据质量差就抛开业务场景、试图全面解决数据质量的问题,这样得不到业务部门的支持,也无法从数据工作中产生业务价值。所以 ThoughtWorks 建议的恰恰是利用做应用、做业务的需求,同步解决数据质量问题。

    史凯认为,数据质量问题,根本上是在构建应用之初缺乏整体数据规划和数据思维导致的问题。原来的流程类应用构建之初,只考虑了如何让流程跑起来,缺乏对这个应用在整个企业的数据全景图(Data Landscape)中的定位的分析,没有从源头上优化数据的存储、流转,从而更好地与其他的系统中的数据去对齐口径、统一语言,将流程问题抽象成领域模型问题,再将领域模型抽象成数据模型。

    建设数据中台的挑战及应对策略

    建设数据中台最大的挑战在于前期能否从业务层面梳理清楚有业务价值的场景,以及数据全景图,而不仅在于后期的技术建设。

    数据中台建设面临的挑战包括:

    • 梳理业务场景:搞清楚数据中台如何对业务产生价值。

    • 建设数据中台的优先级策略:需求可能大而全,但我们不能直接建大而全的数据中台,应该根据业务重要性来排需求的优先级。

    数据治理问题:和业务独立开的数据治理少有成功的,大的数据标准要有(数据资产目录),通过数据资产目录将共有的纬度、共性的业务模型提炼出来,在此基础之上数据治理需要跟业务场景紧密结合。

    数据中台的建设需要两个战略耐心

    数据中台是为了加快从数据到业务价值的产生速度,但是它的生产过程依然是需要时间、有很多复杂的工作要做的,所以对于数据中台的投资方和数据中台的建设方来讲,都需要对应的战略耐心。

    • 对于投资方来讲,要充分认识到数据中台类项目的价值和局限性。在现在的组织结构和技术成熟度下,数据中台依旧是一个技术平台,对于业务价值的产生是一个加速的过程。但是业务对于数据的需求不会因为有了数据中台就减少,数据中台也不是哆啦 A 梦,不能随心所欲地变出各种业务想要的服务。这依然是一个需要统筹规划、敏捷迭代、演进建设的系统性工程,所以需要要管理好期望,有一定的战略耐心。

    对于建设方来讲,要充分认识到数据中台建设的复杂度,不要操之过急,不要期待毕其功于一役。史凯的建议是要从小中台做起,围绕具体有价值的业务场景去建设,尽量不脱离场景去搞周期长、大而全的纯工具平台建设。

    数据中台也可以小而美

      建设数据中台的关键考量包括两方面。

    首先数据中台一定要与业务价值对齐。构建数据中台,最重要的不是技术,也不是数据质量好不好,而是数据思维和数据文化。数据思维就是要建立起从数据的视角去思考问题的方式;数据文化就是要把数据和业务当成一体去看,而不是只将数据当作一个支持工具。想清楚业务对于数据的诉求是构建数据中台的第一步,哪怕暂时不能想的太细,也要去想,想不清楚就先不要做。

    不要在业务场景还没有明确、优先级还不清晰、价值度量体系尚未建立起来的时候,就建立大而全的数据平台,并且把所有的数据都存起来。企业都是追求投入产出比的,大而全的数据平台往往会面临尴尬的局面,一堆功能看上去很有用,应该都能用上,但是缺乏应用场景,真的有了场景,发现也不能开箱即用,还需要众多的定制化。

    其次,数据中台应该从小数据、小场景做起。

    数据中台是面向场景而非面向技术的,这种与客户的业务、企业的结构和信息化发展阶段有着紧密的相关性的业务基础架构,是很难买一个大而全的产品来一劳永逸解决的。

    可以通过下面这个图来解释构建中台的原则:

    一开始的时候需要顶层设计,面向业务愿景制定中台的整体规划,全面的梳理数据创新全景蓝图,这就是上图左边的黑色框架部分,通过业务愿景驱动出所有的业务场景探索,从而推导出数据中台的全景架构、技术支撑。

    但是在实施的时候,要从具体的业务场景出发。从高价值数据集场景做起,然后顺着这个场景竖切,找到数据全景图中的一个或多个数据集合,从小数据场景落地,这样才能快速验证价值。大处思考,全局拉通,避免后续的数据孤岛,但是从小数据集切入,从可实现性高的场景启动。然后一个个的场景做起来,业务价值和中台能力也就同步建立起来了。

    总的来讲就是,“设计阶段横着走,落地阶段竖着切。”

    数据中台团队和技术选型

    数据中台团队通常需要包含以下角色:

    • 业务专家团队:了解业务、梳理业务场景,确定数据资产与业务场景的一一对应关系,确定业务场景的优先级,为数据中台的建设提供依据。

    • 数据工程团队:建设和维护数据中台,包括 ETL、数据采集,以及数据中台性能和稳定性保证,利用中台的工具采集、存储、加工、处理数据。

    • 数据分析团队:分析数据价值、探索场景,生产更多的数据服务。

    • 数据治理团队:梳理数据标准、构件数据安全和隐私规范,利用开源去中心化的数据治理工具(比如 atlas、wherehows)来围绕业务场景解决数据质量和安全问题。

    • 智能算法团队:为数据分析、业务探索提供智能和算法工具。

    而这样的一个团队的工作就构成了一个数据生产线,一个从数据到业务服务的数据服务工厂,这个工厂有生产车间(Data Pipeline)、研发中心(数据实验室)、管理办公室(数据治理),还有产品展示中心(数据服务商店)。

    数据工厂是一个逻辑概念,不是一个大而全的产品,ThoughtWorks 结合过去几年的实践给出了一个数据工厂组件选型的参考架构,这些推荐的架构和组件,很多都体现在过去 ThoughtWorks 推出的技术雷达中并进行了详细解释,如下:

    数据中台的出现对于现有数据团队的挑战

    前面已经提到,数据中台是企业的 Data API 工厂,用更高效、更协同的方式加快从数据到业务的价值,能够给业务提供更高的响应力。所以数据中台距离业务更近,这对于传统企业的数据业务来讲,是一个重大的变化,同时给原来的数据团队也会带来巨大的挑战。

     1. 对数据分析人员的业务要求提高了

    企业传统的数据工作和业务工作分工明确、界限清晰,业务人员负责业务需求,提出业务问题,并将业务问题拆解成一个个清晰的数据问题,然后数据工程师和数据分析师在这个清晰的问题下解题。

    但是,在数据中台出现后,数据中台是一个赋能平台,它会沉淀、提供很多数据分析工具和数据服务,能够让不具备专业数据能力的业务人员也可以进行一些简单的数据分析,产生业务的洞察。这就意味着在数据中台的支持下,相对简单清晰的业务问题会更多的由业务人员自己解决掉,那么传递到专业数据人员的问题,都会是更加复杂的问题。这对于数据人员的业务理解能力就加强了,他 / 她们必须具备快速理解业务的能力,才能够体现出专业性和优势。

     2. 对于数据人员的工程能力要求提高了

    原来的数据分析工作属于个体工作方式,每一个数据科学家、数据分析师就是一个独立的工作单元,业务部门给出业务问题,他们通过自己擅长熟悉的工具和方法给出结果。但是在数据中台出现后,他们一方面获得了更多数据分析的武器和工具,能够站在前人的基础上工作,提高了效率和准确度,另外一方面,他们也需要掌握更多的平台化的数据分析工具,比如 Jupyter Notebook,同时也被要求能够把自己分析的结果转化成数据服务,沉淀到中台。

     3. 数据团队需要具备更多的业务视角

    原来的数据分析团队是一个功能型团队,更多以数据智囊团的身份存在。大部分情况下,距离业务比较远,更不要提对业务的结果负责。而在数据中台出现后,数据中台距离业务会越来越近,甚至直接影响和参与业务的运行,数据团队将慢慢脱离数据智囊团的身份,逐渐从后台走向前台,直接负责一个个数据服务,而这些数据服务是会直接参与到业务当中、产生业务价值的。这样的定位变化,要求数据团队具备更多的业务视角,要更关注业务价值,直接对齐企业的业务目标去工作。

    所以,数据中台的出现,不仅是一个技术平台,它对于企业而言是一个系统化的工作,企业数据相关的流程、职责、分工都要有对应的调整,才能达成整体的目标。

    数据中台 VS 数据隐私

    对于数据中台来说,数据隐私和安全性也是非常重要的问题。可能很多人还记得前些日子马化腾针对“腾讯数据中台论”的回应。去年腾讯组织架构调整进程中实现了技术打通,而对数据打通保持谨慎态度。马化腾在 18 年 11 月的世界互联网大会上回应“数据中台论”:“腾讯不能套用很多其他公司的做法,把数据直接去任意打通。因为在我们的平台里面,大量全部都是人和人之间的通信、社交行为数据,如果说数据可以任意打通,给公司业务部门或者给外部的客户用,那是会带来灾难性的后果。这方面我们要更加谨慎,我们要从用户的角度来考虑,把个人信息和数据保护放在优先地位。”很多人将这解读为腾讯不做数据中台,史凯却不这么认为。

    在他看来,腾讯的回应并不是说他们不做数据中台,而是强调要在数据隐私上做更多的工作。其实所有的数据安全和隐私的保护都需要从场景出发。史凯认为,“不能从纯数据层面来看数据隐私,数据隐私是不能脱离场景的”。如果纯粹从数据层面,而不从业务场景层面去管理数据隐私,就会带来两方面的问题,要么数据被管理的非常死,阻碍了业务价值的产生;要么数据隐私管理就会有漏洞。

    史凯举了一个例子,比如我们讲的用户交易数据,如果不关联用户基本信息,交易数据本身对于用户来说是不具备隐私风险的,因为它不关联到任何一个用户个体。所以,是可以对脱敏后的用户交易数据进行分析和利用的。

    另一方面,如果脱离场景谈数据隐私,也可能会导致忽略了潜在的安全问题。有时候如果不把场景关联起来,可能两个数据看上去没有安全问题,但其实外人把这两个数据关联起来就产生价值了。这也是为什么在一开始的时候就要把所有的场景,尽可能地全部分析出来。

    另外,设置权限、数据分级审核、库级数据脱敏等都是可以提升数据安全的手段。现代数据中台必须具备数据调用行为的监控和记录机制,反过来也能增强对数据安全和隐私的保护。

    数据中台的下一步

    当前国内外已经有不少公司开始投资建设数据中台,大家比较熟悉的包括阿里、华为、联想、海航、上汽、壳牌等。

    在史凯看来,数据中台当前处于上升发展期。虽然未来数据中台未必还叫做数据中台,但它一定会成为企业必备的基础组件。

    世界正在从信息化向数字化发展。信息化是指大部分的工作都在物理世界里完成,然后用信电脑的数字化世界解决一小部分问题。数字化则是把人从物理世界搬到数字化世界。从这个角度来讲,数据中台将会变成物理世界的业务在数字化世界的一个还原。

    数据中台设计的初衷是将计算与存储分离,从狭义上来说,真正最核心的数据中台可以是没有存储的。但就当前的情况来看,广义的数据中台在未来一段时间内仍会涵盖数据仓库、数据湖等存储组件,“数据工厂”这个概念可能更适用于现在的阶段。但随着数据中台的发展,未来很有可能不再需要数据湖了。

    最后,史凯也提到了阿里中台战略中的另一个中台——“业务中台”。他表示“当前业务中台更偏实时交易,是从上往下沉淀业务;数据中台目前更偏分析、决策和洞察,为业务提供 T+N 和 T+0 的数据服务,但是再往前走,数据中台跟交易会慢慢结合得更为紧密。随着计算能力越来越强,以及微服务架构的进一步发展,未来业务中台和数据中台可能会融为一体。”

     

    采访嘉宾

    史凯,ThoughtWorks 数据和智能总监,精益数据创新体系的提出者,2019 年被评选为 DataIQ100 的数据赋能者,有近 20 年年的企业信息化、数字化转型架构和实施经验,为众多大型客户提供数字化转型战略略规划和咨询实施服务。

    技术雷达是 ThoughtWorks 推出的公益的、不限行业的技术选型趋势报告,至今已坚持十年,旨在以雷达的表现形式,通过清晰的解读,给技术人员提供高质量、落地性强的技术平台、工具框架方面的选型指导,助力企业数字化转型。

    展开全文
  • 最近在读阿里数据中台的书,因为要在组内做分享,就多度了几遍。与阿里大数据实践之路配合,基本可以看到阿里建设数据中台的过程,和一些技术细节。做一件有价值的事情就是把自己觉得好的东西分享出来,那么开始内容...

    最近在读阿里数据中台的书,因为要在组内做分享,就多度了几遍。与阿里大数据实践之路配合,基本可以看到阿里建设数据中台的过程,和一些技术细节。做一件有价值的事情就是把自己觉得好的东西分享出来,那么开始内容

    (1)大数据的发展历程和价值探索

    大数据的发展

    文章开篇是一段作者建设数据中台过程的心路历程,下来就是老套路,介绍了国内外大数据发展的历程与大数据的价值探索,这里做简单的介绍。
    大数据编年史
    两个重要的节点需要说一下

    1. 2003年谷歌公开了内部对于海量文件的处理技术、GFS分布式文件系统、并行计算处理框架MapReduce、高效数据存储模型BigTable,这些促成了分布式系统基础架构—hadoop。为各个大数据组件的诞生打下基础。
    2. 2012年全球大数据从TB上升到PB,也是阿里大数据之路开端的一年。

    大数据的价值

    大数据的价值书中主要从四个方面介绍,在下面的四个方面都深刻的解析了大数据的实际应用和真是含义。

    1. 语义层面:‘数据’即所有信息的记录,例如用户访问网站的信息的转化过程的行为属性;大是巨量的意思,可以隐身为数量、形式、含义的丰富,保障实现被高保真的记录与回放
    2. 实现层面:大数据是一套数据处理技术活方法体系,实现具体以上特征的数据的存储、计算、共享、备份和容灾、保密等,保证数据处理的时效性和拓展性
    3. 服务层面:大数据的数据技术变革引发的新型信息服务模式,例如从数据探索出发,系统主动推送信息给用户做决策、给及其优化参数、基于数据的量变完成数据的质变
    4. 应用层面:大数据是数据服务组合生成的新场景、新体验、日益增长的数据量非但不会使信息获取效率降低、质量下降,反而会让每个人都能得到快速的迭代,个性化的互联网服务。

    ##(2)阿里的大数据主张
    在数据提供服务的基础上,阿里对数据的要求是准、快、全、统、通,简单的解释是标准统一
    融会贯通、资产化、服务化、闭环自优,这是阿里数据中台实现目标的核心。
    数据中台赋能业务运行图
    要实现上面的目标,如何做呢?
    图片展示了数据中台运行的过程,主要抽象成三个部分
    第一部分:OneData致力于实现数据的标准与统一
    第二部分:OneEntity致力于实现实体的统一,让数据融通而非以孤岛存在,为精准的用户画像提供基础
    第三部分:OneService致力于实现数据服务统一,让数据复用而非复制

    从两一个维度看一下数据中台赋能业务的全景图
    数据中台赋能业务全景图

    • 数据后台:计算数据后台同时具有离线计算、实时计算计算能力和在线分析能力从而可以让用户今早的看见昨天及以前汇总及萃取的数据,准确无误的看到上一秒产生的数据、在线分析,查看海量的数据
    • 数据中台:云上数据中台、通过智能数据能力实现全局数据仓库规划、数据规范定义、数据建模研发、数据连接萃取、数据运维监控,拥有多样的数据的分层数据中心。
    • 数据前台:数据前台的核心是通过数据的复用,为多个业务线提供数据高效的数据服务。

    ——————————————————————————————————————
    今天就介绍到这里,下次介绍阿里巴巴的大数据建设过程,主要以时间为主线介绍。

    展开全文
  • 数据中台(七) 数据中台架构

    千次阅读 多人点赞 2020-09-23 12:59:15
    数据汇聚是把数据资源通过实时、批量的方式存储到数据中台。基本是按照数据的原始状态堆砌在一起的,是企业对过往所有IT信息化建设积累的成果的融合。 数据开发 数据开发是数据资产内容建设的主战场,是数据价值...

    总体架构图

    数据存储

    计算引擎

    数据汇聚

    数据汇聚是把数据资源通过实时、批量的方式存储到数据中台。基本是按照数据的原始状态堆砌在一起的,是企业对过往所有IT信息化建设积累的成果的融合。

    数据开发

    数据开发是数据资产内容建设的主战场,是数据价值生产过程中核心环节。数据资源是原材料,数据资产是商品,数据开发就是商品生产流水线,通过这条流水线将数据资源转换成数据资产。

    为了降低开发难度,提高开发效率,需要一个可视化的开发平台,主要包括以下产品功能:

    数据体系

    数据体系是在全域数据资源的基础上,进行标准定义及分层建模,数据体系建设最终呈现的结果是一套完整、规范、标准、准确的数据体系,可以方便支撑数据应用。

    贴源数据层STG:数据资源通过批量同步和实时接入临时存储的数据层,只存储增量数据或部分全量数据。数据结构与源系统基本保持一致。仅做简单整合、非结构化数据结构化处理、增加审计列,不做深度清洗加工。

    操作数据层ODS:对贴源数据层进行处理,存储全量数据。数据结构和贴源层保持一致。

    统一数仓层DW:分为明细数据层DWD、汇总数据层DWS和公共维度层DIM。按照维度建模的方式进行数据组织,定义一致的维度和指标,各业务板块、业务域按照统一规范独立建设,通过清洗、规范化形成统一规范的标准业务数据体系。

    明细数据层DWD:按照业务过程建立事实表,主要包括维度表的键、原子指标、少量冗余列和审计列。

    汇总数据层DWS:把DWD层按照业务域进行聚合,形成粗粒度的事实表。主要包括维度表的键、派生指标、少量冗余列和审计列。

    公共维度层DIM:按照实体对象或数据字典建立维度表,主要包括文本信息、离散数值和审计列。

    标签数据层TDM:面向对象建模,对跨业务板块、跨数据域的特定对象数据进行整合,通过ID-Mapping把各个业务板块、各个业务过程中的同一对象的数据打通,形成对象的全域标签体系,方便深度分析、挖掘、应用。主要包括标签类目、标签和标签值。

    数据应用层ADS:按照业务的需要从统一数仓层和标签数据层抽取数据,并面向业务的特殊需要加工业务特定数据,以满足业务及性能需求,向特定应用组装应用数据。

    资产管理体系

    数据资产是指由企业拥有或者控制的,能够为企业带来未来经济利益的,以物理或电子的方式记录的数据资源,如文件资料、电子数据等。在企业中,并非所有的数据都构成数据资产,数据资产是能够为企业产生价值的数据资源。 

    数据资产管理是指规划、控制和提供数据及信息资产的一组业务职能,包括开发、执行和监督有关数据的计划、政策、方案、项目、流程、方法和程序,从而控制、保护、交付和提高数据资产的价值。数据资产管理需要充分融合业务、技术和管理,以确保数据资产保值增值。

    数据标准管理

    数据标准是指保障数据的内外部使用和交换的一致性和准确性的规范性约束。数据标准分为基础类数据标准和指标类数据标准。基础类数据标准是指业务流程中直接产生的,未经过加工和处理的基础业务信息。指标类数据标准是指具备统计意义的基础类数据,通常由一个或以上的基础数据根据一定的统计规则计算而得到。

    数据标准包括三个要素:标准类别、数据元、数据属性。

    数据标准管理是指数据标准的制定和实施的一系列活动。数据标准管理的目标是通过统一的数据标准制定和发布,结合制度约束、系统控制等手段,实现数据的完整性、有效性、一致性、规范性、开放性和共享性管理,为数据资产管理活动提供规范依据。

    数据模型管理

    数据模型是现实世界数据特征的抽象,用于描述一组数据的概念和定义。数据模型从抽象层次上描述了数据的静态特征、动态行为和约束条件。

    数据模型管理是指在信息系统设计时,参考业务模型,使用标准化用语、单词等数据要素来设计企业数据模型,并在信息系统建设和运行维护过程中,严格按照数据模型管理制度,审核和管理新建数据模型,数据模型的标准化管理和统一管控,有利于指导企业数据整合,提高信息系统数据质量。

    数据模型是数据资产管理的基础,一个完整、可扩展、稳定的数据模型对于数据资产管理的成功起着重要的作用。通过数据模型管理可以清楚地表达企业内部各种业务主体之间的数据相关性,使不同部门的业务人员、应用开发人员和系统管理人员获得关于企业内部业务数据的统一完整视图。

    数据质量管理

    数据质量管理是通过计划、实施和控制活动,运用质量管理技术度量、评估、改进和保证数据的恰当使用。

    元数据管理

    元数据是有关一个企业所使用的物理数据、技术和业务流程、数据规则和约束以及数据的物理与逻辑结构的信息。

    元数据管理是数据资产管理的重要基础,是为获得高质量的、整合的元数据而进行的规划、实施与控制行为。

    数据安全管理

    数据安全管理是指对数据设定安全等级,按照相应国家/组织相关法案及监督要求,通过评估数据安全风险、制定数据安全管理制度规范、进行数据安全分级分类,完善数据安全管理相关技术规范,保证数据被合法合规、安全地采集、传输、存储和使用。企业通过数据安全管理,规划、开发和执行安全政策与措施,提供适当的身份以确认、授权、访问与审计等功能。

    数据安全管理的目标是建立完善的体系化的安全策略措施,全方位进行安全管控,通过多种手段确保数据资产在“存、管、用”等各个环节中的安全,做到“事前可管、事中可控、事后可查”。

    数据的安全治理应贯穿于数据的整个生命周期

    数据共享管理

    数据共享管理主要是指开展数据共享和交换,实现数据内外部价值的一系列活动。

    数据内部共享的关键步骤是打通企业内部各部门间的数据共享瓶颈,建立统一规范的数据标准与数据共享制度,数据外部流通和对外开放可以通过数据直接交易与提供数据分析信息的两种方式实现,将数据中符合共享开放层级的信息作为应用商品,以合规安全的形式完成共享交换或开放发布。

    数据服务体系

    数据服务作为数据中台实现资产服务化的核心能力,是连接前台业务和数据的桥梁,通过服务接口的方式对数据进行封装和开放,快速、灵活地满足上层应用的需求。

    数据运营体系

    数据运营体系是让数据中台得以健康、持续运转和产生持续价值的体系。数据中台是个复杂工程,数据的汇聚、开发、管理、服务都是要持续进行的工作,如果没有运营体系的保障,可能会导致后期的参与者无从下手,随着时间的推移,数据的质量、服务的效率业务持续下降,进而导致中台无法使用。

    产品选择

    确定中台架构后,进入产品选择阶段,数据中台主要包括以下产品:

    展开全文
  • 引言——首先来聊聊现代企业数据架构及痛点: 数据孤岛:低效率和利用困难的根源 应用瓶颈:传统方案数据仓库、数据湖的不足   单讲这两个问题你可能会疑惑——为什么会出现这样的问题?   所以下面来讲讲两个...

    引言——首先来聊聊现代企业数据架构及痛点:

    1. 数据孤岛:低效率和利用困难的根源
    2. 应用瓶颈:传统方案数据仓库、数据湖的不足

      单讲这两个问题你可能会疑惑——为什么会出现这样的问题?

    所以下面来讲讲两个实际的例子来细讲一下这两个问题:

    第一部分——两个实际的场景例子引入

    1.以航空公司的场景为例:

      航空公司的市场部计划推出一个新产品或者是一个客户活动,会希望了解哪一种渠道是某类客户最常用的?当想到这个问题的时候,发现航空公司的客户触点太多了。

      PSDP行程订单,投诉、行李系统,常旅客系统,手机App系统等等。这些系统都是航空公司在不同阶段,不同的业务部门建立的应用。这些应用在部署时只会以本业务为目标,而不会考虑到企业其他业务能够很好的对接。如果这些应用中的数据没有做到统一的话,那要花费数天或者数周才能得到结果,甚至都不知道哪里能够拿到数据。有时就算知道,还要协调其他业务部门来正确地给到。

    在这里插入图片描述

    2.以保单贷小程序的场景为例:

      当客户通过这个保单贷小程序申请现金贷的时候,如果客户在保险公司中已购买过重疾险、人寿险或财产险,系统可以根据客户的保单额,在一分钟内判断出提供给客户适合类型的现金贷。

      在上线的时候发现,这个保单贷小程序很快开发好了,但是数据在人寿、重疾、财险等不同的系统里面,有些还需要推荐系统和标签系统。所以要花很多的时间来做数据的对接,这个时间是数周、甚至数月。因为其中不只是数据问题,还涉及到权限等问题。

    在这里插入图片描述

    以上的情形都是企业中常见的数据孤岛的问题,而且随时 IT 建设的发展,这个问题会原来越常见。

    在这里插入图片描述

    综合分析:

    1. 有关于第一个问题——数据孤岛:
      数据孤岛成因:
        是由于事业部门在建设 IT 服务的时候,分别以各自业务建设为核心,而不是以数据建设为目标而形成的。

    2. 有关于第二个问题——应用瓶颈:
        其次,常用的数据库如Oracle, SQLServer, DB2, Sybase,这些关系型数据库一直以来存在性能扩展的瓶颈。导致在上大的系统,或者客户量增加时,需要采用分库分表的方式。因为单个库没有办法支撑到太多的业务量。这也形成了大量数据孤岛。

    3. 上述两个问题形成大量的数据孤岛,所带来的的对应的问题主要有(数据孤岛带来的影响严重阻碍了新业务对已有数据的重复利用):
      ①需要大量时间对接和同步;
      ②用户体验下降,数据不完整不实时;
      ③重复建设,复用率低等。

    第二部分——各种解决方案的分析

    在这里插入图片描述

    为了解决数据孤岛的问题, 目前的解决方案:

      有应用层面 ESB 企业总线、MQ等;从存储角度来说,有数仓Teradata,Greenplum,以及数据湖。这些方案都可以在一定层面上解决问题,但是存在局限性:

      首先,这些方案都是面向分析场景,对于数据抽取不及时,多数是 T+1 方式,也就是说业务获取的数据,是系统昨天生产出来的。这些数据在数仓及数据湖中处理形成了大量报表及结果数据,通过下载、导出等方式进行交付,形式粗放。所有目前市面上的大数据平台,大部分的场景是偏重于分析,主要用于做BI,做报表、Dashboard,来对企业的运营和客户有所洞察。

    在这里插入图片描述

      而对于企业运营来说,关键的、核心的能力不是后端的分析,而是在前端与客户交互,与业务交互,与流程交互。

    基于上述情况,数据中台应运而生。

    第三部分——优胜劣汰留下唯一解决方案->数据中台

    以打通部门或数据孤岛的统一数据平台为基础,构建统一数据资产体系,并以API服务方式为全渠道业务(分析 + 应用)提供即时交付能力的企业级数据架构。

    在这里插入图片描述

    • 首先,统一数据平台。
      数据中台也是一个数据统一的平台,它不会取代原来的系统,而是把原来组织中分散在各系统中的数据实时地汇聚到统一平台之中。

    • 其次,数据资产体系建立。
      与数仓及其它大数据平台不同的是,汇聚统一之后,做数据资产体系规划。对数据打标签,组织目录和结构,便于发现和使用。

    • 最后,提供数据服务。
      以API的标准接口方式向前端的业务场景,或分析场景提供服务。而不是通过传统的SQL,或者是dump的方式来导出数据。我们称之为DaaS(Data as a Service),数据即服务。

      构建企业数据中台,所支撑的场景不仅仅是分析(如可视化分析,数据发现,数据报表等等),也包括满足各种前端业务应用对数据的需求,如CRM、BPM、SCM、MES等。所以这里提供的数据服务是全渠道业务,而不是传统数仓做的BI类似的工作。更多前端业务应用如掌上商城、手机银行、保单管理、客户360、统一订单、销售大屏等。汇聚在中台的数据可以直接推到手机、App等各类前端,并且是实时的,交互的数据。

    这些都是传统数仓这样的平台所无法比拟的。

    以下是金融企业的数据中台架构参考(银行业):

    • 最低下蓝色是EDW、Hadoop、DB2、Oracle等是已有的各类系统的数据源。

    • 通过CDC、批量导入、API集成等方式把数据汇聚到中台。

    • 在中台里面进行资料的建模和分类,比如按照客户、账户、交易等纬度。

    • 然后以API方式交付到他们的各个业务中心。

    • 最后做成各种业务开发,如金融商城,手机App,社交系统等。

    在这里插入图片描述

    在没有数据中台的时候。实现这些前端场景需要各个业务中心找每一个需要用到的数据中心去协商,前端业务直接连到后台的核心系统。因此而产生两个问题:

    1. 当数据量上来时,如做促销活动,核心系统DB2,Oracle等跟不上。

    2. 当有业务中心有新的需求产生,对数据模型要改变的时候,核心系统很难支撑。

    当企业有了可以灵活组织新的业务模型的数据中台,才可能真正快速地响应前端的业务需要。

    在上图的右上角,可以看到数据中台依旧可以支持一些分析的场景。

    当然,这样的数据中台必须具备数据的治理能力,如质量,编目,建模等等。

    所以数据中台的主要价值在于,数据的协同效率、复用效率和交付速度。原各个系统中的数据不再各自为政,而协同到一起效率提高很多。同样,一份数据可以给多个业务场景使用,而不再需要 ETL 到不同的系统,还要去维护它们的一致性,去掉重复,或防止遗失。最大的价值更在于,加快数据的交付速度。

    (1)技术需求:

    我们讲完了这个中台的一个架构和它的逻辑模型,如果我们要来考虑实施数据中台有哪些技术模块要考量。还回到刚才那张图,首先中台必须是基于一个数据统一平台的,那数据统一的时候,其实刚才没有讲到的,还需要把数据同步和汇聚过来。所以有一部分的工作你是少不了的,如果你没有做过这种中台甚至统一平台的话,你必须有一个ETL平台来把你的来自各个来源的数据抽取过来,抽到你的数据统一平台上。

    数据统一平台你用什么样的解决方案?那是另外一个问题,回头我们会讨论。那进到里面了以后,我们在上面才构建我们的资产体系,这个是需要用到中台相应的一些比如数据治理的模块能力来做这个事情。那最上面层就是一套服务化能力,要把它做成API server 的方式,把这个数据快速的可以交付出去。

    基于上述对于数据中台的理解和定义,我们列出了数据中台所应该具备的技术需求。主要是分为:数据存储系统、数据同步汇聚工具、数据治理和开发、数据交换和发布、数据管理能力五大模块。

    如下表:
    在这里插入图片描述
    在这里插入图片描述

    • 我按照各每个系统大概列了一些数据中台比较核心需要的能力,当大家在采用某一种系统的时候,某一种方案的时候,可以对照一下。也不是每一个你们都会关注,但是这是从我们经验中经常用得到的。比如作为数据平台存储系统的话,你第一个肯定是要横向扩展。为什么?你做的是一个企业级的数据平台,你要把所有的原系统有可能真的做到其极致的话,可能全部把他拿过来,所以你必须得有一个横向扩展能力。不能想今天我的数据这个数据在MySQL可以放得下了,或者是一个Oracle可以放得下了,但你要考虑到明年、后年,甚至是三年、五年以后,因为这个架构放上去以后是一时半会不会动的,那灵活的数据模型,这些也是我们的经验,我们要这个是做一个数据汇聚。往往你的一套同一个客户系统,同一个客户模型会来自于多个不同的系统。这个时候,你有一种灵活的模型和相对的一种比较死板模型的话,你会发现这种灵活模型会比较容易的把数据整合进来,能够接受不同的一些字段的变化,也可以方便的把它合并到一个模式里面。

    • 高并发低延迟就是我们这个中台最终不仅仅是支撑分析,还要支撑前面的业务,所以必须得有这种潜在的直接穿透到前端,例如我们的移动端用户,或者会有大量的这种高并发。作为这个核心数据,高可用、备份、安全都是不用说的了。这是关于存储系统数据平台的一些最基本的一些要素,所以大家考虑的时候,可以从这方面来想这个问题。

    • 其他还有涉及到就是同步工具。批量导入能否实时同步?批量导入一般都有,但是能够实时同步,比如说因为我们要做的事情真的是比如说我们在一家银行做的需要这边刷卡,刷完卡,这个数据在三秒之内直接要进到我们的中台里面,因为上面有一些业务场景会给予中台来做一些推送。所以这个时候实时同步的能力是非常关键的,然后还有一些断点续传或者是所有的数据源的支持,这个就是比较常见的这种同步工具的一些需求了。

    • 治理开发就是我们刚才讲的很多就是说怎么样之间数据体系,你必须得有一系列的能力。数据目录、原数据管理、建模、开发、质量管理等等,匹配去重都是,需要在考察的时候,看他们中台有没有这个能力来做这些事情。

    • 数据交换的发布就是我们的data API。我们说这是一个数据开发平台,我们面对的使用者,比如大数据团队也好,或者数据管理团队也好或者DBA也好,往往不会是开发人员来做这事情。这更像是一个比较中央化的数据平台团队,所以他们关注的可能是一些管理能力,无代码能力就不用让他们写很多代码,所以这个API能否很方便、很快速地按照需求来接通到为前端做服务,这是很关键的。当然,接口的多样性也是非常关键。SQL方式,大数据、流数据,这些接口都按照我们的需求考虑是否需要。

    • 最后一点就是系统管理能力,就是常见的就是这种可视化。因为这里面做很多的事情要有一些相应的任务管理、任务设计、监控、告警啊等等,权限管理,一般的系统都会有这种需求。

    (2)技术选型:

    常见搭建数据中台的技术产品!

    数据中台包括:统一数据平台,数据同步,数据治理,数据服务四大部分。

    下表列出了这四大部分中相应的技术产品,有同步汇聚工具、有数据治理、还有数据服务。

    在这里插入图片描述

    • 数据平台最常见的是以 Hadoop 大数据为基础的。在最近十年,有很多家公司投入很多来做这个事情,把数据已经收集到中央化的一个 datalake 里面,那这个就是个很好的起点。其他的还有用数仓来做的,用 Teradata 或者是 Oracle, Gleenplum,MySQL Cluster,MongoDB,国内的话,有星环或者一些大数据公司。有一些特殊的场景,有人会用一些其它产品,比如说 ElasticSearch 会用来做一些全文搜索,但往往那个只是配合,他不会整体的放在这上面。

    • 同步工具就很多,有开源的,有商用的。开源的话,比如有 Kafka、Kettle, Spark ETL 、Talend,商用的的话要有 Informatica、Golden Gate,包括我们 Tapdata 也提供这种类似的数据同步工具。

    • 治理方面比较做的比较好的可能是开源的话,有 Apache Atlas,那如果是开源商用的话 Informatica 应该是最老牌的,Erwin 这些都是比较经典的这种数据治理的公司,可以配合这些产品来把中台里面数据进行编目和治理管理,Oracle 也有相应的产品。

    • 数据服务就是涉及到API。我们见的最多的可能还是大家用 spring 来搭建一个 API 框架,或者有一些比较现成的 API 机,像 Kong 比较流行。Kafka 是提供一种流式数据的服务,可以做 streaming,Loopback也是可以用 nodejs 的方式来提供 API。Mulesoft 和 CA 都是一个非常成熟的 API 产品,当然他们的价格也不便宜。

    • 他们的优势是他会给你一套整体的 API。不仅仅是服务方案,还有管理方案,他的监控、安全、认证、鉴权,然后把你所有的不管是 data API也好,你的业务API也好,都有个统一的管理界面和一个 gateway的方式来帮他做好。

    • 这里面大家可以看到有非常非常多的选择。如果咱们已经有的话,基本上是用已有的工具,如果没有的话就可能要好好的来看一下看看哪些厂商,或者是一些共享的方案。下边我们也会分享一个方案,可以参考一下来一个快速的选型。

    (3)数据平台产品分类:

    对数据平台比较关注的来看一下数据平台产品分类。

    1. 数据平台的这种产品从90年代开始,从关系型数据库到21世纪的数仓MPP,到后来的大数据,到现在的很多的NoSQL,NewSQL,有非常多的种类。他们都有什么样的特色呢?是否合适来做数据中台的一个存储呢?

    在这里插入图片描述

    1. 数据统一平台的特点对比:
      在这里插入图片描述

    2. 数据统一平台选项参考:
      这里简单来看一下,如果是做数据统一平台选型参考的话,从它的海量数据能力,响应时间和并发能力和他支持多结构数据的能力上,我的个人见解。比如说我们说的现在的NewSQL的吧,他就是对多结构数据支持不是特别的理想。包括RDBMS、MPP也都是这样,那这个时候大家可以考虑一下用哪种方式。这取决于你的场景,MongoDB确实他有他自己的一些弱点,比如做多表关联的时候其实并不是他的优势,我们会建议尽可能避免这种多表关联的场景。但是如果你真的是避免不了的话,那他可能就不是一个很好的选择。
      在这里插入图片描述

    3. 选型建议:
      在这里插入图片描述

    这里是我的一些小小的选型建议,从我个人的出发点,按照我的自己的跟客户的一些交流的经验看了他们的一些情况,然后也是经过一些项目的实施,就是提供的一些情况,然后也是经过一些项目的构实施提供的一些建议。

    • 如果你已经有Hadoop或者数仓的统一平台,我们很多的头部企业,大型企业都是已经有的,这个时候你是不希望从头开始构建一套新的什么所谓的中台架构。你基本上可以基于这个基础之上,配合他的数据治理,把它打造成一个数据资产体系,然后加上他的Data API。对于这种情况,我们刚才看到的很多的已有的数据中台的解决商,他都是基于这种大数据的方案来做的,所以他们的一些能力。往往是已经跟你Hadoop Hive之类的或者数仓呀做比较好的结合,那些同步工具,ETL工具都是有比较不错的结合了,你就可以在这个基础上只是用它的理念来构建。

    • 如果你还没有数据统一平台,没有数仓,没有这个Hadoop之类的话,这个时候我们觉得可以考虑一下,就是我们推荐的这种MongoDB的方案,会非常理想,因为我们相对来说是比较简单一些。起步会快,假设真的不行,你也可以很快就见效,我们叫做非常 fail fast,错就错的快一点,不要花很长的时间才发现不行,那如果你还没开始构建的话,一步到位就可以拿到。因为我们刚才讲的MongoDB在数据平台上是有很大的优势的。如果是Hadoop的话,最近几家合作的海外的那几家都三家只剩下了一家Cloudera,其他两家都已经被收掉了或者被合并了,这也是因为它的本身有很大的局限性,很复杂很难用,投入很大,收效比较小。

    • 如果你的中台主要目的想支撑前端交互式应用。那MongoDB是最理想的,因为我们的特点就是高并发、低延迟、横向扩展。然后非常面向开发,非常面向JSON API,这是非常理想的。那Hadoop的话,他一开始大数据都是以分析为主的,不是为前端为主的。

    • 反过来,如果你的中台数据目前你看不到有什么前端的业务场景会来使用。最主要的还是解决这个数据统一。而且你觉得有很多复杂的表。要做很复杂关联,这个时候一下子把它合并到一个JSON里面是几个JSON里面是比较麻烦的,那可能是MongoDB的适用度就一般了。那反而是那些基于传统的数仓的,那个会比较做的会比较好一点,相对来说是功能上比较完善一点。

    • 如果你是比较喜欢有些比较快速,能够比较轻一点的,比较简单一点的。下载下来就可以安装可就可以跑起来,那我们Tapdata这种方案会比较轻便一点。

    • 如果你没有数据工程师的话,我们MongoDB的一个的优势就是比较自然,比较直接,比较容易理解数据模型,会是一个不错的选择。

    • 如果你没有明确你这个中台搭建的想做什么,我们可能不合适,因为我们可能这个事情做出来以后没有什么太大的效果的话,你就发挥不了我们的所谓的这种价值。其他的方案,我也不知道是不是合适了。

    有了这么多解决方案,我们来看一下,如果是基于一个 MongoDB 的方案会是怎么样?我们刚才只是讲的数据平台在做一些选择,但是做一个完善的数据中台的话还需要很多其他模块,所以这里面是用到了另一个产品,就是Tapdata DaaS。通过 MongoDB 和 Tapdata DaaS 这样一个组合,一起来做这个中台的解决方案。

    第四部分——tapdata DaaS 基于 MongoDB 的数据中台落地方案

    (1)落地

    MongoDB 作为中台架构的数据平台

    • 我们先来看MongoDB作为中台架构的平台优势。
      ①MongoDB 是一个多模数据库。所谓多模数据就是他一套系统里面一套分布式集群,里面可以做很多的不同的事情,有的时候你可以把它作为一个内存数据库,可以把它作为一个目录数据库,也可以把它作为一个IOT的数据模型。就是说它的多模性特性是比较有特长的,而且它的自动扩展能力也是非常适合这种中台的统一平台的需求。多模多态,对汇聚性也是非常重要,因为我们需要支撑不同结构、半结构化、非结构化、甚至一些图片文件能够来做到这一些。
      ②另外,就是MongoDB的API友好能力,采用 JSON 作为传输格式。我们知道现在都是微服务,都是通过Data API的方式交付数据中台的数据。前面业务中台往往都是用微服务,也是通过这种RESTful API,那MongoDB的这种JSON模型对新一代的这种架构式有得天独厚的优势,你会发现你花很少的时间就可以把这个API构建好。另外,MongoDB 也原生提供这种 Streaming API 帮助来做一些流处理的事情。所以MongoDB 作为一个中台的统一平台数据库,其实是有非常得天独厚的条件。
      ③当然,除了他的多表关联是可能是缺陷。
      在这里插入图片描述
      ④MongoDB另外一个优势就是它的对象模型。我们的 JSON 模型就是非常接近于我们开发的对象,Json也好,或者是Java 里边的 Object,python 里面的 Dictionary。
      在这里插入图片描述

    • 一个传统的数仓,或者是现在的数据中台的数据统一平台,要做很多的数据治理。比如要做一系列的建模的工作有概念建模、逻辑建模、物理建模。而且物理建模就是我们所谓的物理层,那就涉及到关系模型。管理一个逻辑对象,怎么样转化成五张表,十张表,20张表遵从第三方指示,这里面其实是很复杂,也会很花时间。你要设计一个很好的模型,怎么样来支撑未来的业务,这也是为什么传统数仓会花那么多的落地项目代价来做这个事情。

    • 而MongoDB的解决方案能轻松地处理这方面的事情,这就是为什么 MongoDB 会受很多开发者的喜欢:MongoDB 在建模方面是一个非常独特的形式,它的模型是基于类似于这种逻辑模型的对象模型。你可以把它理解为差不多是一对一。业务人员一般都会明白这个概念,比如建模、逻辑建模,这些模型他们心里都有数。他们就是可能不懂那种种 DBA 说出来的的 Oracle 的这种建模方式,但是对于 MongoDB 来说,其实你只需要达到逻辑建模层的话,你就可以把这事情做了。而且这个模型建完了以后,直接可以用REST API的方式交付出去。从这一点上来说,它是有一个技术上是非常独到的一个先天性的优势,尤其对我们想做这种基于API的这种服务中台来说。

    • MongoDB 的读写分离,HTAP支持全渠道业务需求。 有一些开发者会说是 HTAP (Hybrid Transaction and Analytical Process),就是说又可以做分析业务,也可以做的交易型的业务。在MongoDB里面,我们怎么样来做这种事情呢?比如说一个集群里面,一个cluster,一个复制集,我们有五个节点,四个Secondary,一个primary。左边的primary节点可以用来直接。直接跟我们的手机或者是网页端的应用进行交互收集,采集数据,用户数据。那MongDB自动同步把的数据从primary同步到secondary里面。

    • 然后我们还可以除去左边三个,作为正常的高可用集群来说,我们还可以拿出两个节点专门用来做分析,你看他这个use=analytics。就是一个标签,就比如说这两个节点是只是用来做于分析型的,那这个时候我们就可以用它来上面。加上我们的BI connector,或者是直接用我们的MongoDB charts和compass,直接可以对接MongoDB数据库做一些展示:kpi,dashboard等等。我们也可以通过一些大数据接口,比如说spark connector 来做一些大型的machine learning或者是AI都是,有很多的这种应用场景,那这些都可以最实时的,在你最新鲜的数据上通过一个读写分离的架构上来完成,你不需要再ETL。在MongoDB里面,这个ETL的需求量是非常非常少的,因为可以通过原生的这种同步来提供数据的汇聚,数据放到这个分析集群里面。

    • MongoDB 还有一个触发器的 API 也是比较实用的。就是大家如果不是太了解的话从3.6开始有个change stream,你可以用来订阅数据库的更新事件。比如从IOT设备过来,有一个灯亮了,有一个设备进入一个地理围栏里面发个报警。你都可以通过一个非常简单的订阅方式获取这些事件,然后做一些实时的,响应式的处理,不管是在dashboard上面显示个警告,或者是把它推送到一个Message Queue 、Kafka之类的都可以,直接就用MongoDB的原生的功能来完成。

    (2)Tapdata DaaS 是什么?

    Tapdata DaaS 是钛铂数据为现代企业加速数字化转型设计的数据平台,通过提供采集、存储、组织和增强等一揽子解决方案,从而得到更加方便和友好的数据服务。

    Tapdata DaaS 提供了4个主要的功能模块,数据采集和同步、数据转换和治理、元数据管理、和数据服务。
    在这里插入图片描述

    Tapdata: 为MongoDB量身定做的中台构建工具集

    Tapdata DaaS 可以看做是 MongoDB 生态上一个工具集。 要做一个数据中台,要同步、要治理、要建模、还要做API发布,这些都不是 MongoDB 做的事情,MongoDB 主要是做数据库为它的核心的主要的功能,其他的相应的功能就可以通过一些外围的工具。而 Tapdata DaaS 可以快速的来实现这些不需要用代码的方式快速把数据的同步,建模和治理,以及发布给快速的做出来,这个大概就是一个整体,Tapdata DaaS 加 MongoDB 的架构。下图中的蓝色的部分就是中台的几个其他部分,绿色的就是MongoDB 的数据平台。

    在这里插入图片描述

    1. 数据同步及处理能力:
      结合 MongoDB , Tapdata DaaS 这套方案是可以快速落地, 可以最快的时间对接上数据进行建模、同步,然后拉到中台里面并进行把它发布出来。举一些例子,比如说可以从 Oracle database 里面把它的表的数据拖到 Tapdata DaaS 的目标的中台库里面,然后对数据进行 JSON 建模,或者是一对一建模。在这个过程中,还可以是进行实时的同步,基于日志的同步。Tapdata DaaS 数据源可以支持 SQL server、Oracle、Sybase、MongoDB、DB2 、MySQL、Redis、Elasticsearch 等等,也支持文件,比如 excel、CSV。

    2. 数据建模能力:
      基于这种内嵌的模型Embedded的模型,把一对一,一对多的关系,甚至多对一的关系就直接就合并到里面去。这个会对客户数据合并、产品数据合并、订单数据合并有非常好的效率的提升。Tapdata DaaS 提供一个可视化的建模见面,就可以很容易完成这种合并工作。

    3. 数据治理能力:
      数据进到库里面,进到中台里面。有来自于不同的数据库,几十套,上百套都有可能,每一套库里面有几百张表在里面必须有一个非常好的分类,非常好的组织能力。按照不同的目的、不同的角色、不同的规则或者数据体系给它分门别类建好在这里面,把这数据打好标签,这样的话可以快速的让大家高效的来使用到这些数据。

    4. 数据API发布能力:
      可以通过RESTful API快速的交付出去。提供图形化低代码开发工具,只需要几分钟的时间就可以简单的发布数据给其他使用方调用。兼容Open API,也可以支持行级列级的过滤。同时也会有一些API文档的测试能力,权限管控等等,这个是中台必不可少的能力之一。

    展开全文
  • 将企业的核心能力随着业务不断发展以数字化形式沉淀到平台,形成以服务为中心,由业务台和数据中台构建起数据闭环运转的运营体系,供企业更高效地进行业务探索和创新,实现以数字化资产的形态构建企业核心差异化...
  • 中台概念着实火了一把,继去年购买了“数据中台”的百度搜索指数后,昨天我又购买了“业务中台”的百度指数,可能是由于刚刚购买,全量数据还没有统计汇总出来,所以当我们在百度指数,搜索业务中台的时候,目前...
  • 当前阶段 数据应用到各个角落,除了之前可以支撑的决策分析以外,大数据与线上事务系统(OLTP...数据中台的集中化建设也更好地支撑起创新业务,比如通过大数据+分析建立起商业化数据变现产品,进行数据售卖,把数据...
  • 前言 2010年左右,还是在上学的时候,学过一门...如今,十年风云际会,大数据早已成了行业绕不开的话题,这其中我们或多或少会接触到很多新兴的概念,例如数据湖、数据中台等,通过一些碎片化的学习,也是大概知...
  • 数据中台被誉为大数据的下一站,由阿里兴起,核心思想是数据共享,2015年阿里提出“大中,小前台”的策略。2018 年因为“腾讯数据中台论”,中台再度成为了人们谈论的焦点。 2019年,似乎人人都在提数据中台,但...
  • 数据中台最早是阿里提出的,但真正火起来是 2018 年,我们能感受到行业文章谈论数据中台的越来越多。大量的互联网、非互联网公司都开始建设数据中台。 为什么很多公司开始建设数据中台?尽管数据中台的文章很多,...
  • 关于数据中台的概念定义,业内有各种各样的版本,尤其是涉及数据中台数据仓库、数据平台等相关概念的差异一直争议不断,可谓一百个人眼中,就有一百个数据中台,千百万人眼中,就有千百万个数据中台。关于概念之...
  • 数据中台可以说是当下非常火热的话题,在BATJ等互联网大厂大肆推广中台建设成果的当下,各个行业的企业似乎都想做数字化转型,建设业务中台,但是中台到底是啥,需要我们提前了解和学习,本文是我学习张旭老师《数据...
  • 2019年是数据中台元年,中国整个IT行业在这一年掀起一股新的浪潮,数据中台这股潮流正席卷IT界的各个角落,并通过各种自媒体发酵渗透到各行各业。数据中台在大数据时代的背景下格外引人注目,一些有前瞻性的企业都在...
  • 数据仓库、数据湖、数据集市、和数据中台的故事

    千次阅读 多人点赞 2020-04-24 11:05:33
    数据仓库、数据湖、数据集市、和数据中台的故事 如今,随着诸如互联网以及物联网等技术的不断发展,越来越多的数据被生产出来-据统计,每天大约有超过2.5亿亿字节的各种各样数据产生。这些数据需要被存储起来并且...
  • 到底什么是数据中台

    万次阅读 多人点赞 2019-07-22 21:00:00
    最近可能大家听到“数据中台”这个词越来越频繁了,有时候我跟一些朋友聊起来,也是都在说这个,但是一直不知道这到底是个什么。最近就看到这篇文章,觉得说的还挺好的,分享给大家看...
  • 什么是数据中台?全面解读数据中台

    千次阅读 多人点赞 2019-06-04 16:49:54
    伴随着云计算、大数据、人工智能等IT技术迅速发展及与传统行业实现快速融合,一场由数字化和智能化转型带来的产业变革正在孕育。 随着企业规模不断扩大、业务多元化——中台服务架构的应运而生。...数据中...
  • 八问数据中台:关于数据中台你想知道的都在这里! 原创: 筱愚她爸 凯哥讲故事系列 1周前 数据中台最近特别火,各个企业都在关注如何构建自己的数据中台,利用数据中台打造数据驱动的经营能力。数据中台的概念漫天...
  • 浅谈数据中台数据仓库的异同

    千次阅读 多人点赞 2019-10-26 18:30:40
    一、数据仓库 数据仓库的概念大家并不陌生,关于数据仓库的理论和应用已经非常成熟,持续不断地帮助高层决策者和业务人员做分析和决策。简单来说,数据仓库是一个面向主题的、集成的、非易失性的,随时间变化的用来...
  • 数据库, 数据仓库, 数据集市,数据湖,数据中台

    千次阅读 多人点赞 2019-02-22 16:21:47
    数据仓库和数据集市的区别 作者:修鹏李 出处:CSDN 大数据:数据仓库和数据库的区别 作者:南宫蓉 出处:简书 第一篇:数据仓库概述 第二篇:数据库关系建模 作者:穆晨 出处:CNBLOS 摘要 本文简要介绍...
  • 用户画像,数据中台.....你想了解我对于这些的看法吗?
  • 袋鼠云大数据解决方案专家。专注于云计算、大数据、企业级技术架构(EA)等领域,在互联网、零售、工业等行业有深入的理解和丰富的从业经验,曾带领项目团队完成中金易云、货币网、固德威等企业级大数据项目交付,...
  • 数据中台你想知道的都在这里!

    千次阅读 2019-06-30 11:38:38
    数据中台是什么? 数据中台和数据仓库,数据平台的关系是什么? 数据中台和业务中台的区别是什么? 数据中台建设的最大挑战是什么? 数据中台数据质量应该如何保障? 数据中台的典型...
  • 数据中台:让数据用起来》读书笔记引言思维导图数据中台总体架构图 本文转载自 http://www.softeng.cn/?p=255 引言 最近三周主要读了两本书,一本是《大数据架构详解:从数据获取到深度学习》,目前只读了三分之一...
  • 个人理解数据中台与大数据平台区别
  • 阿里云产品之数据中台架构

    千次阅读 2020-07-22 17:53:32
    客户打包买了很多阿里云的产品,但是阿里云不负责实施,基于阿里云产品与客户需求,拟采用的数据中台架构,有类似需求的,可以参考下,拿走不谢! 2. 解决方案 阿里产品数据中台架构图: 从下到上,简要介绍下各个...
  • 阿里数据中台演进四个阶段

    万次阅读 2020-10-21 10:50:23
    数据中台」已经从一个技术词汇,慢慢转变成为企业界的共识:如果想要在信息商业拥有一席之地,就必须要借助云计算和数据的力量,完成企业的数字化转型。 只是,数据到底在转型扮演什么样的角色,要如何利用好...
  • 一文读懂数据中台技术架构

    千次阅读 2020-11-02 22:11:52
    一文读懂数据中台技术架构 https://www.toutiao.com/i6836923386560512516/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1&timestamp=1603853943&app=news_article&utm_source=...
  • 数据中台的设计

    千次阅读 2019-12-18 10:30:49
    数据中台是涵盖了数据资产、数据治理、数据模型、垂直数据中心、全域数据中心、萃取数据中心、数据服务等多个层次的体系化建设方法。 1.1数据中台建设的方法论 1.2数据中台建设的内容 全域的数据的采集和引入,以...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,136,914
精华内容 854,765
关键字:

数据中台