01先看龙，再说脉。应用系统越来越多，但为业务决策获取准确的决策信息却越来越困难。据说有一个笑话发生在2000年前后，甲骨文总裁拉里想知道甲骨文在世界上有多少人。但当时没人知道，因为Oracle的全球业务系统分布在各个大洲/国家，每个地区都有自己的应用系统，却没有全球统一的中央系统，所以发生了这么有趣的事情。这也促使甲骨文花费大量的人力物力，将分布在不同国家和地区的系统汇集成一个全球系统。基于全球统一数据的决策分析进入了甲骨文高速发展的20年。事实上，很多企业会发现，在IT系统大规模建设之后，获取有效决策信息的难度越来越大，数据分散在多个业务系统中，演变成了一个尴尬的局面：数据量大，但缺乏有效信息。一般来说，有以下几种情况：?决策信息分散在多个业务系统中；?数据不一致性突出，多个信息提供者对信息没有严格的定义，不同的业务系统对同一个信息没有严格的定义对数据的理解和定义不同，甚至很多同名数据指代不同商业信息;缺乏历史数据；业务系统的数据模型是为事务处理而设计的，不适合分析；在系统上进行信息查询会影响现有系统的运行；?数据太多，信息太少。为了走出重重困境，数据仓库自然成为了创业者关注的焦点。经过各个行业的商业实践，虽然有很多变体，但大体上都是这样的结构。02数据仓库给企业带来发展机遇和挑战。进入中国市场后，数据仓库经历了十年的快速发展。十年来，众多IT领域的有志之士在这条赛道上奋斗，有很多成功的经验，也有很多失败的案例。这里有一个简短的故事与大家分享。首先，中国移动的业务分析系统经过10多年的发展，已经成为支撑企业绩效评价和市场运作的重要工具。在我个人看来，中国移动能够后来居上，力压其他两家，与业务分析的强大支撑有着千丝万缕的联系。2015年以后，中国移动基本没有推出大规模的业务分析建设规范，但直到现在，中国移动一级业务分析系统采集省级数据，仍然是省级公司考核的重要指标。随着智能手机和各种智能终端的快速发展，中国移动也推出了各种新业务、新模式。这时，如何更好地了解客户，了解他们的行为习惯和消费模式，从而有针对性地开展新业务，自然是市场部的重要诉求。手机用户在手机上交友、浏览、购物、娱乐时，会产生大量的日志数据。再加上手机基本上是和人一一绑定的，手机的定位系统自然可以了解用户的出行情况。然而，这些数据对于现有的数据仓库来说太大了，需要大量的资源来收集和处理好它们。例如，手机开关会每隔15分钟吐出当前用户的位置信息，交给后台处理。这个数据基本是拍字节级别的。此外，还有用户浏览日志，包括网站信息，这些都是非结构化信息，很难融入到现在的仓库模型中，所以必须使用大数据技术。说到大数据技术，肯定是Hadoop，但是如何更好的使用Hadoop技术，这时候有一些分歧：有人认为Hadoop是一种全新的技术，可以完全替代传统数据库进行数据分析。传统数据库已经过时。?另一部分人认为Hadoop还不够成熟和流行，不可能指望每个分析师都能够编写数据仓库的adhoc查询和分析代码。相反，我们应该利用Hadoop的大数据并行处理的优势，对数据进行预处理后，将结果导入数据仓库。经过一段时间的沉淀和磨合，现在大家基本上更认可第二种方法。处理完的海量数据如何处理？这是一个两难选择，因为存储需要成本。如果存储数据的收益不能覆盖存储成本，那么存储数据就不划算。但是如果你觉得数据还是很有价值的，可能还有一些价值至今没有被挖掘出来，等以后有其他分析角度和分析需要的时候，那就只能存起来了。这个时候就是数据湖（Datalake）。03湖仓融合的主要目标是打破壁垒，实现数据湖与湖仓联动的主要定位。它是一种可以不断扩展的海量数据存储，容量更大，单位成本更低。主要用于对这些海量数据进行深度挖掘，并保存起来以备后用。这时候，就有些问题了。第一个需求是用户行为分析，因为用户行为分析与用户属性高度相关。但是，所有用户属性都在CRM系统中进行管理和存储。每当用户的属性发生变化时，如何快速将其传输到数据湖中，避免数据挖掘系统使用后出现不准确的数据和不准确的结果。第二个需求，比如在数据湖中进行数据挖掘之后，对于已有的数据进行分类、标注等操作，但是对于用户流失风险评估、用户近期偏好等这些特征，最好使用一个统一的用户界面与用户交互。那么自然要尽快将这些数据湖中的挖掘结果同步到电子渠道系统中，从而通过各种渠道媒体与客户进行互动，避免短信轰炸。第三个需求是SQLonhadoop，这是很自然的需求。因为无论如何，懂SQL的人总是比Spark或者Flink多。而且，目前绝大部分业务系统都使用SQL作为主要的数据处理语言。那么，如何将数据湖中的数据标准化，并提供SQL接口，让业务系统可以直接使用SQL访问数据湖中的数据，就成为了顺理成章的需求。所以大家说的湖仓一体化，归根结底其实是针对数据的价值，通过技术手段实现各个层级之间的联动：将高价值、高频次的数据放在关系型数据库，有条件的话可以使用全闪存或者数据库一体机，加快用户分析效率。对于中等价值的数据，可以考虑多种存储方式，或者传统的关系型，或者使用MPP。更重要的是，考虑到目前市场上的分布式数据库，可以达到成本效益的平衡。当然，建议海量数据存储在Hadoop中，甚至是云空间中的对象存储。因为BigSQL的很多扩展已经可以扩展到S3等对象存储。这样可以将历史数据的存储成本降低到一个较低的水平。04流批融合的目标是进一步提升数据驱动能力。传统数据仓库一般采用T+1数据采集模式。一般来说，需要在前一天关闭数据，以便为后台提供更准确的财务数据。后来随着CDC技术的发展，现在可以将业务系统的数据变化实时录入到数据仓库中。但是，我们需要知道，数据准实时同步并不一定意味着分析数据准实时，因为多个系统之间的同步周期可能不一样。另外，数据进入数据仓库，还有一个清晰和聚合的过程。如果数据仓库随时对海量数据进行汇总计算，计算量就会过大，得不偿失。对于大多数企业而言，细化到前一天的数据粒度就足够了。但总有例外。对于一些实时营销需求，前一天的数据粒度可能不够。通常，像LBS（LocationBasedServices）信息的分析需求，你需要知道你现在在哪里？比如你现在在高速公路上开车，你需要知道前方道路的信息，事故或者堵车，那么这些分析结果就需要用流处理的方式进行实时处理。在流处理中，比较常用的技术是事件驱动（EventDrive），通过对一些预设的事件进行预定义的相关操作。当数据流快速通过时，捕获事件模式，并在有模式匹配时触发一些预定义的动作。但是流处理的缺点是需要提前配置事件，如果不配置相关事件，数据自然会被忽略。流批合一的常见模式是，数据进来后，通过两种方式进行处理。一种方式是传统数据仓库的ETL。数据会及时回复。例如，在滴滴打车的运营过程中，需要结合流处理和批处理数据，对运营过程中发生的安全事件进行预测、分析和主动干预。05实时数仓的重点是实时对于一些时效性强的行业，传统数仓可以解决财务分析问题，但无法实时监控整个过程。例如，外卖平台需要准确知道当前订单到达的时间是哪一步？整个旅程目前的瓶颈在哪里？比如出租车行业需要知道周围有没有出租车，预定的出租车什么时候到？到达目的地需要多长时间？这些需求只有在获取当前实时信息后，再通过AI算法进行预测，才能得到准确的回答。因此，这些行业是实时数仓的主要目标客户群。从整个数据处理过程来看，实时数仓主要涉及几个环节，实时数据采集、实时数据计算、实时报表输出。下面来看看几个环节的使用场景和相关技术：实时数据采集主要是通过一些变化数据捕获机制来获取各个渠道的实时数据变化。对于关系型数据库，有GoldenGate或者直接Binlog解析的方式直接获取变更数据。另外，Kafka队列也用于直接下发前端系统变化的数据。实时数据计算就是将最新的数据加入计算引擎进行分析处理。例如，几乎所有的旅游行业都需要分析判断用户在旅游过程中的状态和安全状况，以便及时提供主动的安全干预。需要考虑的是实时数据操作的规模和粒度，太大或太小都无法达到最佳效果。需要根据实际场景确定。实时数据报表，这个对于很多营销活动来说非常重要，比如春晚发红包，那么就需要随时在大屏上展示当前营销活动各个环节的状态，所以及时调整策略。此外，在一些大规模的调度业务场景中，还需要对海量数据进行分析后，快速输出分析图表进行大屏展示。06结论IT行业瞬息万变。各种新技术、新词汇让人无所适从。以上，我对目前流行的几个专业术语进行了简要的分析和举例。每个行业的使用场景不同，要求自然不同，采用的技术路线也会各有千秋。一千个人心中有一千个哈姆雷特。如果你对这些场景有什么不同的看法，欢迎大家一起交流。
