大数据“网红”阿里云数据中台简介
数据中台的定义
阿里巴巴数据中台是阿里云上实现数据智能的最佳实践，它是由数据中台方法论+组织+工具所组成，数据中台方法论采用实现企业数据的全局规划设计，通过前期的设计形成统一的数据标准、计算口径，统一保障数据质量，面向数据分析场景构建数据模型，让通用计算和数据能沉淀并能复用，提升计算效能。
数据中台的建设实施必须有能与之配合的组织，不仅仅相应岗位的人员要配备齐全，而且组织架构建设也需要对应，有一个数据技术部门统筹企业的数字化转型，数据赋能业务中形成业务模式，在推进数字化转型中实现价值；数据中台由一系列的工具和产品组成，阿里云数据中台以智能数据构建与管理Dataphin产品、商业智能QuickBI工具和企业参谋产品为主体等一系列工具组成。
阿里云在过去几年中经过数十个实际项目沉淀形成实施标准化流程和方法论。阿里云OneData数据中台解决方案基于大数据存储和计算平台为载体，以OneModel统一数据构建及管理方法论为主干，OneID核心商业要素资产化为核心，实现全域链接、标签萃取、立体画像，以数据资产管理为皮，数据应用服务为枝叶的松耦性整体解决方案。其数据服务理念根植于心，强调业务模式，在推进数字化转型中实现价值。
数据中台的概念来自于阿里巴巴“大中台，小前台”业务战略下的数据化实践，它是关于“数据价值化和数据资产化”的一整套解决方案，内容包括数据中台方法论，组织，数据产品三个方面。
数据中台建设成果主要体现在两方面：一个是数据的技术能力，另一个是数据的资产。今天阿里的各个业务都在共享同一套数据技术和资产。阿里内部为这个统一化的数据体系命名为“OneData”。
Onedata体系包括OneModel，OneID，OneService3个方面，在OneData体系之下，不断扩大的业务版图内的各种业务数据，都将按统一的方式接入中台系统，之后通过统一化的数据服务反哺业务。
数据中台顶层设计
数据中台定位于计算后台和业务前台之间，其关键职能与核心价值是大数据以业务视角而非纯技术视角出发，智能化构建数据、管理数据资产与提供数据调用、数据监控、数据分析与数据展现等多种服务。
承技术启业务，是建设智能数据和催生数据智能的引擎；而以数据中台内核价值为中段的数据中台业务模式不是纯数据、不是纯技术、也不是纯业务，它同时关注着与大数据能力相关的上下游，以大数据为中轴线，基于技术而又深入业务，它以数据产品+数据技术+方法论+场景实现的综合性输出，同时为智能化数据、技术极致提升和数据智能化业务负责。
一方面专注于从业务视角，建设标准统一、融会贯通、资产化、服务化、闭环自优化的数据中台智能数据体系，同时极致化追求技术上的降本提效。另一方面，致力于智能数据与业务场景深度融合的业务数据化与数据业务化中的各类智能化价值创新。
数据中台与传统数据仓库差异
传统的数据仓库具有以下几个特点：
1. 业务主题性：传统的数仓要求解决服务问题，比如对一个生产型企业来说公司的主题域是产品、订单、销售商、材料等，要解决应用问题可能是库存、销售、销售商等。其有业务是面向主题的。
2. 系统集成性：在传统数据仓库中，集成是最重要的，由于计算和存储的成本原因，其数据需要从不同的数据源抽取过来并集中，其数据的冗余度需要尽可能的降低，因此数据进入数据仓库中需要进行转化、格式化、重新排列和汇总等操作，其所有数据具有单一物理特性，都是结构化方式存在。
在系统架构方面，也是以集中式存储和计算方式存在，新一代的数仓采用分布式计算，但软件产品采用集中部署方式存在。
3. 非易失性：数仓系统会记录所有记录，与业务系统相比，它不会对记录进行变化操作（update和delete），它会保留所有记录的变化，但受限于成本和计算能力考虑，数仓不会记录全量明细数据，特别是日志数据，因此大部分数仓平台的数据容量在TB级别。
4. 时间变化性：数据仓库中每个数据单元只是在某一时间是准确的，因此数据单元的准确性与时间相关，数据仓库中的数据时间范围5-10年。
5. 系统一体化: 传统数仓以系统整体设计为特性，软件平台围绕着数据库或计算平台以整套服务为主，结合度缜密，对外服务也较单一。传统的数仓采用集中式数据库作为数据和计算平台，近10年来，新兴企业采用分布式数据库和大数据技术实现OLAP类数仓建设，但其本质还是基于一个整体来考虑的。
在系统和服务上数据中台与传数仓有很多明显的区别，首先表现在服务对象方面，传统的数仓只是满足领导数据决策的需要，因此更多的体现在报表输出，使用者以小部分的业务人员和决策层为主，新需求的开发周期以月甚至到年为计。
而数据中台由于起家于互联网企业，其使用对象扩大到一线服务人员和商家企业，其业务需求更繁杂，很难用一套报表系统满足需求，因此催生出一个生态的数据服务。
其次是体系架构上，数据中台是由多系统组成，除了计算平台外，其方案由多个分布式服务系统提供，满足不同业务需求和高并发和系统自动扩容需求，除了大数据存储和计算平台外，还包含数仓建设、工作台开发IDE、任务调度、数据同步服务、对外统一数据服务、资产管理系统、实时流计算平台和开发平台、oneID计算和查询模块，敏捷BI报表开发等多个组件，通过多个维度组件组成一整套方案。
再则，在服务表现形式上数据中台体现的更多样化，数据中台不仅能提供报表基础服务功能，而且为了满足各个业务部门不同需求，会提供领导决策系统、行业分析、业务洞察、业务重塑，自助查询等多个功能，满足从领导层、PD、业务人员、开发人员等各个层级的需求。
在继承性方面，数据中台采用传统的数仓Kimball维度建模法，按照事实表，维表来构建数据中台的数据模型。
数据仓库与数据中台的区别到底是什么？
我们先来看看什么是数据仓库。
数据仓库从技术上讲主要会涉及到数据抽取，建模，清洗，存储等技术过程，用户方面以IT人员为主，功能方面会专注于数据的整合，通过整合内部数据源、打破数据孤岛，提供统一、唯一、标准、规范的原始数据，因此各个业务线都可以从这个数据仓库获取数据，并根据各自的业务需要做自助探索式分析，得出不同的结果，比如同一份会员数据，不同业务部门在加工后标签内容和定义上可能会不尽相同。
不足主要体现在数据应用上缺乏话语权，往往是以业务需求为导向，但不同业务团队的需求很难一样，所以IT响应的需求大多是个性定制化的，不具备复用性，导致企业使用的成本很高。
再来看看什么是数据中台。
首先引用下Kyligence联合创始人兼CTO李杨对数据中台的解释：在中台前台的概念中，前台指的是业务线，而中台是指对业务线的支撑，代表数据赋能业务的意思。
从这个简单的定义中不难看出，数据中台不仅仅只有数据，还有支撑前线业务的运用场景，可以将数据转变为信息，从而指导业务决策支持，它包含了“数据为核心、平台为支撑、驱动前线商务变革“三层意思，成功地在业务和技术之间建立了一个沟通的桥梁。
数据中台旨在通过复用数据资产来驱动前线业务的高速创新和改造，说白了就是专门有一个中台部门，来为各前线业务提供统一数据服务的解决方案，比如用户画像场景，同一份会员数据，由中台人员根据业务情况进行统一建模，统一定义标签后提供统一对外的输出。
数据中台的主体涉及到建模，清洗和应用，主要专注于数据的应用，主要提供统一的应用标准解决方案，成员不仅仅有IT人员，还要有非常理解公司业务的业务专家，在数据应用上依赖业务模型搭建，响应的一般都是比较通用的业务场景，如用户画像，然后基于用户画像提供不同服务如个性化营销，精准推广，行为洞察等。
如果非要加以区分，数据仓库是一个实体，承载着企业的数据中心，提供标准统一的数据来源；数据中台更像是一个概念，承载着企业的业务中心，提供标准统一的业务场景输出。
所以数据中台不仅提供统一口径，规范的数据，且还有中台这个”部门”将这些数据转变成了业务所需要的具体应用，业务用户能直接拿来使用。而数据仓库则仅仅是提供了一份标准，统一口径的数据来源，至于是谁在用这份数据，怎么用，数据仓库就不管了(数据仓库层面)。如果把数据仓库比作数据的"技术语言"，那么业务中台则更加偏向于数据的"业务语言"。
数据中台与数据湖区别
数据湖是数据的聚集、加工为目的数据资源池，但是数据湖只是解决了聚集问题，在数据加工方面由于不可控制的需求变得异常繁重，由于数据的繁杂和混乱引入数据治理让数据的加工更是举步维艰。
传统上数据湖中的数据会存储原始数据，量大并且非结构化和半结构化的数据较多，需要有一个低成本分布式存储和计算架构来承载这些数据，属于ODS层，缺乏数据主题和加工能力，因此近期对数据湖上的数据治理项目和应用越来越多。
数据湖汇集了原始ODS数据，解决了传统数仓基础数据缺乏的问题，作为企业数仓平台的补充，有其重要的意义，但数据湖的作用在于汇集企业的各个数据源，有一个存放和分析之地，在规划中没有一个整体的数据资产规划和管理职能，这会导致其功能薄弱性，不能承担整体的数据处理和管理之重。
实际在一些大型企业，使用数据湖其数据陷阱就会马上出现，业务人员的需求需要DBA或IT人员经过繁杂的处理步骤才能实现达到业务人员的数据分析目的，其会耗费开发人员的时间耗以周计，原因之一是数据湖没有一个数据构建和管理平台去管理和计算这些数据，因此不讲治理的杂乱无章的数据看似能提升数据获取，数据分析的效率，实际上并不能承担企业智能化的使命。
企业数据智能需要解决企业数据智能所面临的诸多问题，企业数据智能需要解决数据的快速计算和结果产出；需要对企业数据资产有整体规划和掌控；需要有一个好的方法论处理业务逻辑繁杂的统计；需要有一个好的构建和管理平台面向业务使用方和开发使用方...这些都是数据湖所不能解决的问题。
数据中台是由阿里巴巴在2015年在内部技术演进和组织优化中提出中台战略中提到的，数据湖本身的缺陷正是数据中台强项，二者可以起到方案补充的作用，在现有技术框架中数据中台可以基于Hadoop数据湖平台作为数据存储和计算载体，实现数据的加工和处理。
数据中台更多实现数据的管理，强调利用数据的能力，强调数据开发和高效的使用，数据中台的数据资产管理可以对数据湖中的数据按照数据域方式进行管理并结合业务的逻辑实现整个数据模型的加工和开发。
数据中台与数据域相比，数据中台强调方法论，组织和工具的建设。非常强调数据赋能业务，衍生出很多的数据业务产品。比如在阿里面向商家的生意参谋，面向人物属性的标签服务、面向行业小二的行业洞察…这些都极大的扩展了数据价值，其次数据中台按分析的原子指标和派生指标方式做计算并存储在Maxcompute平台上，如有及时查询要求会同步分析结果数据给MPP或其他DB。这块在数据顶层设计，全域资产、统一技术、产品业务上与Datalke及EDW是不同的。
最后说到底都是企业提供数据计算、存储和应用的平台，最终各种平台的目的都是要更好地服务于业务。
《硅谷的“中台论”与中国的“中台论”》笔记
提要：
数据中台指的是企业抽象，共享，和复用数据能力的平台，核心是数据能力的共享和复用，并且提倡“去中心化的数据能力的复用和共享”
什么是数据中台？
数据中台指的是企业抽象，共享，和复用数据能力的平台，其目的是实现去中心化的商品洞察能力和产品迭代能力，使得企业能够持续进行不断演进的数字化运营，适应产品市场和人员组织的快速变化。
有了数据中台，公司所有人不用再重复开发相关数据组件，就可以共享数据能力。产品经理不用再去各个部门找数据，而是在平台上看有哪些数据、API 可以用……；某部门需要用户画像功能时，直接调用 API 就可以；反欺诈部门把“甄别用户是不是机器人或者是恶意账号”的能力输出，其它部门想用的时候也可以直接调用 API。
数据中台的核心是数据能力的共享和复用，并且这种共享和复用要在一个可管理的系统中进行，目的是通过数据驱动公司业务。在大数据领域主要体现在两个方面，一个是 BI（商业洞见），一个是 AI（数字驱动的产品），对应美国常用的两个指标，一是 time to reliable insight，老板如何快速及时的获取可靠商业洞见决策；二是 time to market。
数据中台不只是一个理念，它还需要一系列的工具来支撑。“什么是去中心化的数据能力的复用和共享？因为如果共享是强制的，那么大部分业务部门是不愿意花时间在大数据上的，因为这跟业务没关系。那么我们怎么做呢？首先，要让业务部门尝到甜头，其次，工具要足够好用，第三，要保证系统无论如何不会崩坏。如果你有一系列在安全可控环境下的工具来共享业务部门的数据能力，并且能够量化这些能力带来的价值，业务部门才会愿意共享数据能力。”
数据中台与技术中台还不一样，因为数据是跟着业务走的，而技术的共性会比较多。让数据中台部门天天跟着业务去学习数据显然是不可能的，所以数据中台部门必须提供足够好用的工具，赋能业务部门共享数据能力。中国有另一种模式，即：把某个能力抽取出来，由专门的组来负责。这两种方式都可行，因此，要视公司的具体情况而定。
数据中台的建设是从 0 到 1？还是是从 0 到 0.1？我们认为是后者——数据中台要很快见效，不断迭代，分阶段逐渐体现出数据中台的价值，这样各个部门才有动力继续配合建设数据中台。
做中台，一定要动组织架构吗？
技术中台的建设一定要动组织架构！ 但数据中台的建设不一定要动组织架构！
数据中台建设有一个关键的问题，数据能力由谁来提供？一种方式是由数据中台部门来推动，将数据能力抽取到数据中台；另一种方式是所有数据共享能力都由业务部门来提供，数据中台部门提供工具。在后一种情况下，组织架构不需要变，开发流程会改变，以前各组件都是自己负责自己的数据，但是现在各组件的数据都必须符合公司规范。
虽然建设中台是否动组织架构不太确定，但确定的是中台战略会涉及到多方利益，因此中台建设一定是个“一把手”工程。
数据中台的分层体系及数据流转
一个完整的数据平台至少应该包含三层，即大数据计算平台、数据中台、数据应用前台。除此之外，还应该包括四层。未来的程序一定是云原生的。因此数据平台的底层一定是个私有云平台，中间一层是大数据基础组件层，包括 Hadoop、Kafka、Spark、认证安全、共享存储等等，再上一层是大数据运营管理层，即如何把组件以一种最方便、最安全可靠的方式实现数据的共享和复用，最上面的一层是业务部门输出的数据能力层，在大数据运营管理层之下，各部门能够输出和复用数据能力。
公共模块的整合、提炼是数据中台建设的重点，比较重要的公共模块有数据采集、数据转换、数据治理、数据和应用资产管理、数据分析、数据服务和数据展示，除此之外，还有一些必要的工具，例如数据安全、审计、多租户、资源隔离、监控等等。
当数据进入到数据中台之后，它的流转路径是怎样的呢？首先，原始数据会先导入到数据湖，接着转换到数据仓库，再转换到数据集市，数据集市中会有数据服务的发布工具，自动发布到平台，并与具体的业务系统进行对接。当然，工具不仅有自动发布工具，还有包括数据应用的调度管理、数据服务的生产、算法平台的执行以及数据格式化等等。
原文见：AI前线 公众号。
《数据中台：让数据用起来！》笔记
各行业数据中台需求特征
数据中台能解决什么问题？
整合孤岛数据，沉淀数据资产，快速形成数据服务能力，为企业经营决策、精细化运营提供支撑，这套机制就是数据中台。中台也是一套快速可靠的数据资产体系和数据服务能力（数据资产化和资产服务化）。这样当出现新的市场变化，需要构建新的前台应用时，数据中台可以迅速供给数据服务（服务业务化）。
数据中台能解决什么问题？
中台需要具备 数据汇聚整合、提纯加工、服务可视化、价值变现４个核心能力，让企业员工、客户、伙伴能够方便地应用数据。
a.汇聚整合：能够接入、转换、写入或缓存企业内外部多种来源的数据，打破各业务系统塑造的孤岛。
b.提纯加工（即数据资产化）：通过统一的数据标准和质量体系，建设提纯加工后的标准数据资产体系。光数据多还不行，还需要标准化，按应用需求梳理整合。
c.服务可视化：为了尽快让数据用起来，数据中台必须提供便捷、快速的数据服务能力，让相关人员能够迅速开发数据应用，比如实时流数据分析、预测分析、机器学习...
d.价值变现（资产服务化）：提供以前单个部门或者单个业务单元无法提供的数据服务能力，以实现数据的更大价值变现。即1+1>2
数据中台４个核心能力
数据中台工具技术组件包括数据汇聚、数据开发、数据资产管理、数据服务管控等。
入手步骤和建议：
第一步，把企业现有哪些业务线，每个业务线有哪些数据，分别以什么形式存储以及数据的应用情况调研清楚；第二步，可以对照这本《数据中台》里提到的数据资产成熟度评估模型，对集团的数据应用成熟度做一个评估。
企业数据应用成熟度有4个阶段：统计分析阶段->决策支持阶段->数据驱动阶段->运营优化阶段。
适合企业当前发展阶段的才是最好的，数据中台也不是银弹。 随着数据获取越来越容易，运用信息化系统让企业经营、内部管理的过程越来越数字化，加上未来大概率进入稳定中速发展阶段，存量博弈将会加剧，如何增效，提高生产率是内部管理的永恒话题。
不同行业的不同企业在不同阶段，数澜科技拿出了自家的数据中台体系与方法论供大家学习，期待更多的最佳实践案例。
让企业更好的把数据用起来，科技让人们更容易洞见本源。
参考书目
Ralph Kimball和Margy Ross的《数据仓库工具集》或阿里巴巴的《大数据之路》等书
中国信通院联合多家企业于2019年6月发布了《数据资产管理实践白皮书4.0》
相关书目待读：中台战略、企业数字化、企业IT架构转型之道、数字政府2.0、为数据而生、赋能数字经济。
《阿里的数据中台正在背离初心》
相比数据中台的强管控，敏捷的数据分析、智能的数据发现乃至更新的增强分析和增强数据管理等方法，探索的是一种越来越自助、敏捷、智能的道路，让处于中心位置的数据工程团队越来越精简甚至不需要。这是一种平台的思路。平台的思路就是把技术做的门槛越来越低，越来越智能，不强行追求整齐划一，而是容忍数据的不完美，风格和需求的多变，降低对中心化组织的需要，让沟通链路更短。这才是一种更创新，以赋能前台为出发点的模式。
中台往往是一个方法论和组织驱动的概念，所以强调中台，也会导致组织的固化。中台组织要是变成倚老卖老、尾大不掉，那就不是好事了。
坚持赋能而非管控为出发点，用什么方法能够更好的将数据转化为生产力，就用什么方式，以企业级数据仓库为核心的数据中台方法只是一种，我更认可能够支持敏捷、自助、自组织的方式。虽然我们也实践了很多数据中台技术，但对于业务多元化的我们来说，会从更广的视角来看。
from:冷技术热思考公众号
数字化企业的基础是业务数据实时、统一、在线。
企业中台的技术本质是：共性和个性的分离
共性体现在中台架构层：共性业务抽象、业务逻辑解耦、业务数据隔离、分布式技术架构等特点。
个性化体现在前端应用：快速组合服务、个性业务扩展、灵活业务适应。
业务中台与数据中台相辅相成、互相支撑，一起构建起战场强大的后方炮火群和雷达阵。
业务中台将后台资源进行抽象包装整合，转化为前台友好的可重用共享的核心能力，实现了后端业务资源到前台易用能力的转化。
数据中台从后台及业务中台将数据流入，完成海量数据的存储、计算、产品化包装过程，构成企业的核心数据能力，为前台基于数据的定制化创新和业务中台基于数据反馈的持续演进提供了强大支撑。
企业中台就是，“将企业的核心能力随着业务不断发展以数字化形式沉淀到平台，形成以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效的进行业务探索和创新,实现以数字化资产的形态构建企业核心差异化竞争力。”
2019SACC撷英
小米自己搞了个”kafka“，还自带source和sink。
海致BDP（智能数据平台）一站式数据平台——快速打造贴合业务（灵活、易用）的一站式（完整、闭环）数据平台
《小白也能看懂的阿里数据中台分析》
数据中台不是大数据平台！它不是一个平台，也不是一个系统，如果有厂商说他们有个数据中台卖给你，对不起，它是个骗子。
在数据开发中，核心数据模型的变化是相对缓慢的，同时，对数据进行维护的工作量也非常大；但业务创新的速度、对数据提出的需求的变化，是非常快速的。
数据中台的出现，就是为了弥补数据开发和应用开发之间，由于开发速度不匹配，出现的响应力跟不上的问题。
数据中台解决的问题可以总结为如下三点：
- 效率：为什么应用开发增加一个报表，就要十几天时间？为什么不能实时获得用户推荐清单？当业务人员对数据产生一点疑问的时候，需要花费很长的时间，结果发现是数据源的数据变了，最终影响上线时间。
- 协作问题：当业务应用开发的时候，虽然和别的项目需求大致差不多，但因为是别的项目组维护的，所以数据还是要自己再开发一遍。
- 能力问题：数据的处理和维护是一个相对独立的技术，需要相当专业的人来完成，但是很多时候，我们有一大把的应用开发人员，而数据开发人员很少。
这三类问题都会导致应用开发团队变慢。这就是中台的关键——让前台开发团队的开发速度不受后台数据开发的影响。
数据中台是聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念。
DData API 是数据中台的核心，它是连接前台和后台的桥梁，通过 API 的方式提供数据服务，而不是直接把数据库给前台、让前台开发自行使用数据。至于产生 DataAPI 的过程，怎么样让 DataAPI 产生得更快，怎么样让 DATA API 更加清晰，怎么样让 DATA API 的数据质量更好，这些是要围绕数据中台去构建的能力。
阿里数据中台详解
1、阿里数据中台赋能业务全景图
2、阿里数据中台三大体系
经过多年实战，沉淀出了阿里云上数据中台内核能力框架体系：产品+技术+方法论。
历经阿里生态内各种实战历练后，云上数据中台从业务视角而非纯技术视角出发，智能化构建数据、管理数据资产，并提供数椐调用、数据监控、数据分析与数据展现等多种服务。
承技术启业务，是建设智能数据和催生数据智能的引擎。在OneData、OneEntity、OneService三大体系，特别是其方法论的指导下，云上数据中台本身的内核能力在不断积累和沉淀。
OneData致力干统一数据标准，让数据成为资产而非成本；OneEntity致力于统一实体，让数据融通而以非孤岛存在；OneService致力于统一数据服务，让数据复用而非复制。
那么，实时的数据中台怎么做？
下面是实现实时数据中台的一种逻辑架构，方便你去理解，其实最关键的是实时模型那一层。
1、实时接入：
不同类型的数据需要不同的接入方式，flume+kafka现在是标配，其他还有文件、数据库的DSG等等技术。比如运营商就有B域的订购、通话，O域的位置、上网等各类实时数据。
2、计算框架：
这里只列出一种，基于Kappa架构实现实时/离线一体化业务开发能力，相对于传统Lambda架构，开发人员只需面对一个框架，开发、测试和运维的难度都相对较小，且能充分发挥Flink流式计算框架一点执行、高吞吐、毫秒级响应、批流融合的特点。
比如将流计算组件划分实时数据切片，批处理组件提供离线数据模型（驻留内存），两类数据在处理过程中实现批流关联。
3、实时模型：
跟数据仓库模型一样，实时模型肯定首先是面向业务的，比如运营商有流量运营、服务提醒、竞争应对、放好拉新、厅店引流、语音消费、运营评估、实时关怀、实时预警、实时洞察、实时推荐等一系列的实时场景，你总是要基于你的实时业务提炼出具备共性的数据模型要素。
比如放号拉新中的外来务工实时营销，其中可能的触发场景是针对漫入到某个交通枢纽并驻留10分钟以上的用户进行营销投放，“在某个位置的驻留时长”这个公共要素可能就是一种可复用的实时模型。
实时模型纵向可以划分为DWD和DW两层，DWD模型做的其实是针对各类实时数据做命名的标准化和过滤字段的操作，方便进行数据的标准化管理，DW模型这里分成了三大类：动态模型、事件模型和时序模型，每种模型适合不同的场景，同时需要采用与之适配的存储格式。
动态模型：对实时的数据进行汇总统计，适合做实时的统计指标分析，比如实时的业务办理量，一般可存储于Kafka和Hbase。
事件模型：把实时的数据抽象成一系列业务事件，比如从位置日志轨迹中记录用户的位置变更事件，从而可以触发LBS的位置营销，以下是典型的位置事件模型设计，一般可存储于MQ和Redis：
你也可以设计滑动窗口模型，比如保存最新一小时的分钟级的滑动窗口位置信息：
时序模型：主要保存用户的在线的时空位置等信息，可以基于业务场景需要进行各种快速的计算，比如非常方便的计算驻留时长，存储于Hbase或TSDB（时序数据库）：
4、实时服务
有了实时模型还不够，数据中台还需要提供图形化、流程化、可编排的数据开发工具，才能真正的降低实时数据开发成本。但由于离线和实时数据处理的技术手段不同，导致针对这两种类型的数据开发和管理大多是在不同的平台承载的。
比如以前我们的离线数据模型是通过DACP平台管理的，但实时数据则游离在DACP平台之外，其往往属于应用本身的一部分，应用需要通过编写特定脚本去消费和处理流处理引擎中的原生数据，这种处理的门槛不仅高，而且资源浪费也挺严重，每个实时应用其实都是流数据的孤岛。
站在应用的角度看，业务其实需要的是一个统一的数据开发管理平台，离线和实时数据应作为统一的对象进行管理，比如具备混合编排，混合关联等能力，用简单的类SQL定制化输出应用所需的各类数据，从而高效的对外提供实时/离线数据服务。
5、实时应用
数据中台如果能支持实时数据的快速编排，根据我们的测算，其实时场景应用的数据开发、测试、部署周期会由0.5-1个月降低为1-2天，效益是很高的。
附：
《阿里数据中台建设实践案例》
《中台架构50篇资料精选，阿里/腾讯/京东...中台建设实践汇集》
《OneData建设探索之路：SaaS收银运营数仓建设》
务实信息量大，接地气
ADX项目Review及思考
1 Datahub数据服务：如何规划设计。
2 各个模块独立性不够，有相互依赖的地方。
建议分别打造成可单独使用的积木模块/插件。相互直接通过rest调用及队列进行通信和数据交换。
每个模块功能做扎实。
3 过于复杂。如何提高部署运维自动性？